메모리 최적화 테이블-실제로 유지 관리가 어려울 수 있습니까?

MS SQL 2012에서 2014로 업그레이드 할 때 얻을 수있는 이점을 조사 중입니다. SQL 2014의 가장 큰 판매 포인트 중 하나는 메모리 최적화 테이블로, 쿼리 속도가 매우 빠릅니다.

메모리 최적화 테이블에는 다음과 같은 몇 가지 제한 사항이 있습니다.

• 어떤 (max)크기의 필드 없다
• 행당 최대 ~ 1KB
• timestamp필드가 없습니다
• 계산 열이 없습니다.
• UNIQUE제약 없음

이것들은 모두 성가신 것으로 여겨지지만, 성능상의 이점을 얻기 위해 실제로 문제를 해결하고 싶다면 계획을 세울 수 있습니다.

진짜 키커는 당신이 실행할 수 있다는 사실이다 ALTER TABLE문을, 당신은 통과해야 이 당신이 너무 많이와에 필드를 추가 데데 때마다 INCLUDE인덱스의 목록입니다. 또한 라이브 DB에서 MO 테이블을 스키마로 변경하려면 시스템에서 사용자를 종료해야합니다.

Microsoft가이 기능에 너무 많은 개발 자본을 투자 할 수 있다는 사실을 실제로 믿을 수 없을 정도로,이 기능은 완전히 터무니 없으며 유지 관리가 비실용적이라고 생각합니다. 이것은 내가 지팡이의 잘못된 끝을 얻었을 것이라는 결론에 이르게한다. 메모리 최적화 테이블에 대해 잘못 이해 했으므로 실제로 유지 관리하는 것이 훨씬 어렵다고 믿었습니다.

그래서 내가 무엇을 오해 했습니까? MO 테이블을 사용해 보셨습니까? 사용 및 유지 관리에 유용한 비밀 스위치 또는 프로세스가 있습니까?

아니요, 인 메모리는 실제로 연마되지 않았습니다. 애자일에 익숙하다면 "최소 배송 가능 제품"의 개념을 알게 될 것입니다. 인 메모리는 저것입니다. 나는 MS가 SAP의 Hana와 그 ilk에 대한 응답이 필요하다는 느낌을 받았습니다. 이것이 2014 릴리스 기간 동안 디버깅 될 수있는 것입니다.

다른 메모리와 마찬가지로 인 메모리에는 관련 비용과 이점이 있습니다. 주요 이점은 달성 할 수있는 처리량입니다. 언급 한 바와 같이 비용 중 하나는 변경 관리에 대한 오버 헤드입니다. 이것은 쓸모없는 제품이 아니라 내 이익으로는 순 이익을 제공 할 경우의 수를 줄입니다. columnstore 인덱스를 이제 업데이트 할 수 있고 인덱스를 필터링 할 수있는 것처럼 메모리 내 기능이 향후 릴리스보다 향상 될 것입니다.

이제 SQL Server 2016을 사용할 수 있습니다. 내가 생각한 것처럼 In-Memory OLTP 는 여러 가지 기능이 향상되었습니다. 대부분의 변경 사항은 기존 테이블에서 오랫동안 사용했던 기능을 구현합니다. 내 생각에 향후 기능이 인 메모리 테이블과 기존 테이블 모두에 동시에 릴리스 될 것이라고 생각합니다. 임시 테이블은 적절한 사례입니다. 이 버전의 새로운 기능은 메모리 내 테이블 과 디스크 기반 테이블 모두 에서 지원됩니다 .

새로운 기술, 특히 기능이 완전하지 않은 것으로 크게 공개 된 V1 릴리스의 문제점 중 하나는 모든 사람들이 악대를 뛰어 넘고 모든 워크로드에 완벽하게 적합하다고 가정한다는 것입니다. 그렇지 않습니다. Hekaton의 장점은 256GB 미만의 OLTP 워크로드이며 2-4 소켓에서 많은 포인트를 조회합니다. 이것이 당신의 작업량과 일치합니까?

많은 제한 사항은 기본적으로 컴파일 된 프로 시저와 결합 된 메모리 내 테이블과 관련이 있습니다. 물론 인 메모리 테이블을 사용하지만 기본적으로 컴파일 된 프로 시저를 사용 하지 않거나 적어도 배타적이지 않은 방식으로 이러한 제한 중 일부를 무시할 수 있습니다 .

분명히 당신은 성능 향상이 상당한 경우 테스트 할 필요가 귀하의 환경하고 있는지, 여부 트레이드 오프는 가치가 있습니다. 인 메모리 테이블에서 성능이 크게 향상되는 경우 INCLUDE 열에 대해 얼마나 많은 유지 관리를 수행해야하는지 걱정이됩니다. 인 메모리 인덱스는 정의에 따라 정의됩니다. 이것들은 실제 비 클러스터형 인덱스의 범위 또는 전체 스캔에서 조회를 피하는 데 실제로 도움이되어야하며, 이러한 작업은 실제로 메모리 내 테이블에서 발생하지 않아야합니다 (다시 말해 작업 부하를 프로파일 링하고 어떤 작업이 개선되는지 확인해야합니다) 그리고 그것은 아닙니다-그것은 모두 윈윈이 아닙니다). 오늘 색인에서 INCLUDE 열을 얼마나 자주 사용합니까?

기본적으로 V1 형식으로 아직 가치가 없다면 사용하지 마십시오. 많은 고객 이 한계에 부응하고 기꺼이 혜택을 누리기 위해이 기능을 사용하고 있다는 점을 제외하고는 우리가 대답 할 수있는 질문이 아닙니다 .

SQL Server 2016

SQL Server 2016을 사용 하려는 경우 In-Memory OLTP의 향상된 기능과 일부 제한 사항 제거에 대해 블로그에 올렸습니다 . 가장 주목할만한 점 :

• 최대 내구성 테이블 크기 증가 : 256GB => 2TB
• LOB / MAX 열, 널 입력 가능 열의 색인, BIN2 데이터 정렬 요구 사항 제거
• 절차 변경 및 재 컴파일
• ALTER TABLE에 대한 일부 지원-오프라인 상태이지만 인덱스를 변경 및 / 또는 삭제 / 생성 할 수 있어야합니다 (현재 CTP 빌드에서는 지원되지 않는 것이므로이를 보증하지는 않습니다)
• DML 트리거, FK / 체크 제약 조건, MARS
• 또는 존재하지 않음, 존재, 존재하지 않음, UNION, 외부 참여
• 병행

당신은 할 수 풀업하는, 메모리 최적화 된 테이블을 마우스 오른쪽 단추로 클릭 디자이너 당신이 원하는대로 SQL Server 관리 Studio에서, 새로운 열을 추가 할 수 있습니다. 또한 테이블 이름을 바꾸는 수단으로 테이블 이름을 클릭 할 수 없습니다 . (필자가 작성한 SQL 2014.)

대신 테이블을 마우스 오른쪽 단추로 클릭하고 작성 명령 을 새 조회 창에 스크립팅 할 수 있습니다 . 이 create 명령은 새 열을 추가하여 수정할 수 있습니다.

따라서 테이블을 수정하기 위해 데이터 를 새 테이블, 임시 테이블 또는 테이블 변수에 저장할 수 있습니다 . 그런 다음 새 스키마를 사용하여 테이블 을 삭제하고 다시 생성 한 후 마지막으로 실제 데이터로 다시 복사 할 수 있습니다. 이 3 개의 컨테이너 쉘 게임은 대부분의 사용 사례에서 조금 덜 편리합니다.

그러나 해결하려는 성능 문제가없는 경우 메모리 최적화 테이블을 사용하지 않아도됩니다.

그런 다음 제한 사항과 해결 방법이 사용 사례에 적합한 지 판단해야합니다. 성능 문제가 있습니까? 당신은 다른 모든 것을 시도 했습니까? 성능이 10-100 배 향상됩니까? 그것을 사용하거나 사용하지 않으면 아마도 어느 쪽이든 뇌가 아닌 것 같습니다.

큰 문제없이 운영 서버에서 메모리 내 OLTP를 사용할 수 있습니다. 우리는이 기술을 은행 및 결제 회사에서 사용했습니다.

일반적으로 워크로드가 너무 높을 때 메모리 최적화 테이블을 사용할 수 있습니다. In-Memory OLTP를 사용하면 30 배 더 나은 성능에 도달 할 수 있습니다! Microsoft는 SQL Server 2016 및 2017에서이 제한 사항을 대부분 수정합니다. 메모리 최적화 테이블은 디스크 기반 테이블과 완전히 다른 아키텍처를 가지고 있습니다.

메모리 최적화 테이블은 두 가지 유형입니다. 내구성있는 테이블과 내구성이없는 테이블. 내구성이 높고 내구성이없는 테이블은 테이블 데이터가 메모리에 유지되도록합니다. 또한 내구성이 뛰어난 테이블은 복구 데이터 및 스키마를 위해 디스크에 데이터를 유지합니다. 여기에서 데이터 손실이 중요하므로 대부분의 운영 시나리오에서는 내구성있는 테이블을 사용해야합니다. ETL로드 및 캐싱과 같은 일부 시나리오에서는 내구성이없는 테이블을 사용할 수 있습니다.

이 eBook을 사용하고이 기술을 사용하는 방법을 배울 수 있습니다.

Kalen Delaney : https://www.red-gate.com/library/sql-server-internals-in-memory-oltp

드미트리 코 로케 키치 : https://www.apress.com/gp/book/9781484227718