SQL Server 2014 BPE 를 이용한 성능향상 시나리오
기존에 메모리가 약 10GB 이고 SATA 로 구성된 하드가 5개 달려있는데 데이터가 2TB 정도 되는 OLTP 서버가 있고 읽기가 매우 빈번한 환경이 있다고 생각해보자 ! 그런데, 우리는 SQL Server 2014 다 ! 이러면 SSD 한장 꼽으면 아무런 어플리케이션 변경없이 (5배? 디스크 최대 IOPS Vs. SSD IOPS 와 많은 메모리로 인해 데이터를 디스크와 메모리로 올리고 내리고 하는 과정을 제거할 수 있으므로)정도 성능 향상을 시킬수 있다.
기존 시나리오가 입력만 많다면 SQL Server 2014의 BPE (Buffer Pool Extention)로 효과가 없을 것이다 (쓰기가 빈번하다면 LDF 를 반드시 SSD에 두는게 유리하다. WAL(Write-Ahead Logging) 이므로 Non-volatile 디바이스에 반드시 써야 하므로). 반면, select 의 경우는 Disk 에서 한번은 느리게 읽어오겠지만 (미리 강제로 warm-up 시키는 방법도 쓸 수 있으니 뭐 별 상관없어 보인다.) 그 후는 조금 느린 메모리가 많은 시스템을 상상하면 된다. 처리 대상 대이터의 99% 가 약 100GB 정도에 존재한다면 아주 좋은 시나리오가 될것같다. 생각해보라 우리는 10GB의 물리 메모리만 있는데, 이 데이터 계속적인 페이징 아웃이 일어나면서 데이터를 읽어야 하고 이는 모두 disk i/o 가 된다. 그런데, 이것이 모두 ssd 100GB를 메모리로 인식시켜 캐시 되어주니 얼마나 이롭겠는가? 이를 가르켜 disk i/o 를 ssd로 효과적으로 오프로드 했다라고 표현한다. 그래 이것은 어떻게 하면 비용 효율적인 서버를 구성하느냐의 문제인 것이다. 모두 SSD 로 구성된 데이터베이스와 적당한 메모리를 장착한 서버가 훨씬 빠르지만! 비용을 줄이고 성능을 극대화 할 수 있는 시나리오로 보는것이 맞다.
DW의 경우 대부분이 순차읽기이고 순차쓰기가 발생하고 읽었던 데이터를 재사용하는 경우가 거의 없을 수 있다. (쿼리하는 데이터가 다르다면) 위 OLTP 시나리오와 같이 효과적이지 않을 수 있다. 그러나, 뭐 읽어야 하는 데이터가 매번 최근 데이터이고, 우리는 전체를 SSD 로 넣을 능력도 안되고, 매번 쿼리하는 데이터의 99%가 100GB 미만이다. 이러면 100GB 정도 SSD 로 BPE 기능을 써 구성하면 나는 효과가 있을 듯 하다. 물론 첫 번째는 좀 느리겠지만 뒷 쿼리들은 빨라질꺼다. 아래 링크는 똘똘한 아저씨들이 글을 잘 적어놓았으니 읽어보길 바란다. 만든이들은 DW 쿼리에 BPE를 권고하진 않는다.
하고싶은 이야기는 모두다 좋은게 없고 모두다 나쁜 경우는 없다. 적절하게 아키텍처를 이해하고 구성하면 비용 효율적으로 시스템을 구성 할 수 있다는 것이다. 뭐 계속 좋은 기능은 나오지..... 가격이........ ㅜ.ㅜ ......자꾸 비싸지니 자꾸 없어지고 결국은 어떤 서비스에서도 안쓸려고 한다. DBMS를 잘못 선택한거 아닌가 하는 생각이 자꾸드네....
https://msdn.microsoft.com/ko-kr/library/dn133176.aspx
https://msdn.microsoft.com/en-us/library/cc645993.aspx
The buffer pool extension size can be up to 32 times the value of max_server_memory for Enterprise editions, and up to 4 times for Standard edition.