�ݺ�ߣ

Editor's Notes

• #5: LUDICROUS = 말도 안되는 Hekaton은 그리스어원으로 100이라는 뜻 입니다. SQL Server의 성능을 100배 이상 끌어올리겠다는 뜻에서 이렇게 지은 것이라고 합니다. 몇가지 자료에서 in-memory DB를 RDBMS와 In-Memory를 통합한 하이브리드 DB라고도 합니다. In-memory 데이터베이스는 고성능 아키텍처를 제공합니다.
• #6: 4가지 슬로건을 작성합니다. 최적화된 메모리 메모리 가격이 하락함에 따라서 최적화된 속도의 메모리 기술을 저렴한 비용에 도입 할 수 있습니다. T-SQL 머신 코드 전환 테이블(In-memory 테이블)과 SP(Netive SP)를 컴파일러화하여, 컴파일이 필요없어 뛰어난 성능을 보여줍니다. 고도의 동시성 테이블 구조의 변경에 따른 래치와 LOCK을 해소하였습니다. SQL Server와 통합 기존의 SQL Server의 아키텍처를 변경한 것이 아닌 in-memory 기술을 통합하였습니다. 하여, 따로 변경 및 마이그레이션 작업이 없이 기존의 기능을 대부분 사용 가능 합니다.
• #7: SQL Server 2014로 넘어오면서 여러가지 기능이 생겼는데, 주요 기능은 in-memory입니다. in-memory Table 메모리에 올리는 테이블로써 뛰어난 읽기 성능을 보장합니다. 옵션에 따라서 테이블을 휘발성인 일회용으로 만들거나, 비활성인 지속성으로 만들거나 할 수 있습니다. Natively Compiled Procedure 이 프로시저는 컴파일러화하여 컴파일이 필요 없이 사용 가능한 메모리 테이블에 최적화된 프로시저 입니다. 네이티브 컴파일러 프로시저는 다음 아키텍처 부분에서도 추가적으로 설명합니다. Hash Index 해시 인덱스는 In-memory OLTP에서 생긴 신개념 인덱스입니다. 이 인덱스는 기존의 인덱스들과 다르게 B-tree 구조가 아닙니다. 이 구조는 기존의 인덱스 아키텍처와 다르므로, 처음 접하는 사용자에게는 이해하기 힘들 수 있습니다. Nonclustered hash index 일반 해시인덱스는 범위 검색을 하지 못합니다. 하여, 인메모리 테이블의 범위검색을 위해서 만들어진 인덱스 입니다. 기존의 nonclustered index와 비슷한 아키텍처를 가지고 있습니다.
• #8: DBCC PINTABLE이라는 기능이 2005버전까지 있었는데, 그 기능과를 다릅니다. 이것은 메모리에 테이블을 올리는 것은 같지만, 아키텍처가 다릅니다. IN MEMORY기술에서는 행을 페이지단위로 저장하지 않기 때문에 이것은 엄연히 다른 것 입니다. 또한 이러한 구조때문에 lock/latch가 발생합니다. SQL Server를 재시작 하여도, SCHEMA_AND_DATA 옵션을 선택하면, 데이터가 보존됩니다. 이 옵션은 테이블을 생성 할 때 줘야합니다. Filestream을 이용하여, 메모리상의 데이터를 디스크에 기록합니다. 또한 DML의 경우에는 디스크 테이블과 동일하게 트랜잭션 로그파일에 기록하기 때문에 서버를 재부팅해도 데이터가 손실되지 않습니다. Hash Index가 무조건 해답은 아닙니다. = 검색에만 성능을 보장하며, 제약 또한 많습니다. 무조건 모든 솔루션이라고 하기엔 무리가 있습니다.
• #10: In-memory OLPT 아키텍처가 추가되면서 새롭게 노란색 부분이 추가되었습니다. 하지만 기존의 아키텍처에서 변경된 부분은 없으며, 새롭게 추가만 되었습니다. 이렇게 함으로써 기존의 쿼리를 대부분 그대로 사용 가능하며, 크게 변경하지 않아도 됩니다. 여기서 보면, 인메모리 테이블 또한 트랜잭션 로그파일을 기록한다고 알려져 있는데, 보면 따로 인메모리용 트랜잭션 로그파일을 저장하는 곳이 없습니다. 즉, 트랜잭션 로그파일은 Disk 테이블과 같은 곳에 저장 합니다. 이점은 래치,LOCK을 테이블 구조를 변경하면서 제거하였으나, 디스크의 성능에 따라서 트랜잭션 로그를 저장시 성능이 좋지 못할 수 있음을 의미 합니다. 여기서 다른 점은 다음과 같은 부분이 있습니다. 메모리 테이블을 엑세스 하는 방법은 총 3가지 입니다. ad-hoc Ad-hoc으로 in-memory 테이블을 access 하는 방법은 기존과 크게 다르지 않습니다. 하여, 기존의 T-SQL문을 대부분 사용 가능 합니다. 일반 SP 일반 SP 또한 ad-hoc과 마찬가지로 큰 제약이 없으며, 기존의 T-SQL을 그대로 사용 가능 합니다. 위의 2가지 방법을 이용하여, access 하는 것을 Query Interop이라고 합니다. 이것은 해석하여 상호운용(?)이라고 합니다. 아마도 기존의 프로세스를 이용해 인메모리 테이블을 access하여 그렇게 부르는 것으로 보입니다. 3. 네이티브 프로시저 마지막으로 위의 2가지와 다르게 NSP를 타는 것 입니다. NSP는 오직 Memory테이블만 엑세스 가능 합니다. 또한 이 프로시저는 기존의 프로시저가 실행 시 컴파일 하였다면, 이 것은 생성 즉시 네이티브 코드로 컴파일 합니다. 다만 이것은 제약사항이 매우 많으므로, 사용시 유의해야 합니다.
• #11: 우선 데이터 구조를 보면 row 해더와 페이로드 부분으로 나뉩니다. 기존의 Disk 테이블의 구조가 8kb짜리 페이지 단위였고, 기존의 경우 8kb 페이지에 행이 차곡차곡 쌓이도록 하는 구조였습니다. 이것들이 즉, 행->페이지->익스텐트였습니다. 페이지에 데이터가 모두 차면, 다음 페이지에 저장하고, 계속해서 늘려가는 방식이였습니다. 하지만 메모리 테이블은 페이지나 익스텐트가 존재하지 않습니다. 메모리 테이블에서 행은 독립적(?)으로 메모리에 떠다니고 있습니다. 행과 행사이를 연결하여, 이것이 연관되었다고 알 수 있는 방법은 인덱스가 있습니다. 다시 해더 부분을 자세히 보면, 타임스템프가 있습니다. 이것은 타임이라는 말이 들어가서 모두 시간에 따른 표시값으로 착각하는데, 이는 단순히 자동증가 값입니다. 또한 타임스탬프 옆에 Statement ID를 저장하는 공간과 인덱스의 개수를 저장하는 2byte짜리 공간이 존재합니다. 또한 옆으로 8byte짜리 인덱스 개수만큼 증가하는 값이 보이는데 이는 인덱수의 개수만큼 증가합니다. 인덱스가 3개라면 그 값은 8*3 = 24bytes 입니다.
• #12: 다음으로 인메모리 테이블의 데이터 서치 과정입니다. 처음에 SELECT 쿼리를 실행 인덱스를 토대로 해쉬 펑션을 이용하여, 버킷에서 key를 가져와서 다음으로 넘어감 해당 키값이 버킷에 있는지 체크 값이 N이면, row는 없으므로, 값이 없다고 표시합니다. 값이 Y이면, row의 다음을 찾기위해 넘어갑니다. Row키가 ‘주형권’이면서 end time stamp가 무한으로 표시된 것이 있는지 찾습니다. 값이 Y이면, row는 마지막 row이므로, 값을 표시합니다. 값이 N이면, 무한표시가 나올때까지 찾습니다. 마지막으로 테이블의 또다른 row가 포인터에 존재하는지 찾아내며, 이값에 따라 반복이냐 아니면 결과 없음을 표시하느냐가 달라집니다.
• #13: 앞에서 본 구조를 실제 행이 있다고 가정하여, 나타내면 다음처럼 됩니다. 이 구조는 해시 인덱스가 걸려있는 테이블을 나타낸 것 입니다. 보시면 포인터를 이용하여, 각 행은 연결되어 있는 것을 볼 수 있습니다. 하여, 인메모리 테이블은 체인구조의 테이블이라고 할 수 있습니다. 또한 데이터를 검색 시 앞서 보셨던 인덱스 키를 이용하여, 해시함수를 불러 해시버킷이라는 포인터 Array와 비교하여, 값을 찾습니다. 해시 버킷은 행을 찾아가기 위한 시작점이라고 생각 할 수 있습니다. 여기서도 알 수 있듯이 인메모리 테이블에서 인덱스가 없이 생성이 불가능 한 이유가 여기에 있습니다. 만약에 인덱스 없이 테이블을 생성한다면, 그 처음 시작값을 찾지 못하여, 데이터의 시작을 찾지 못할 것 입니다.
• #14: 만약 행을 인서트 할 경우 다음과 같은 과정을 거칩니다. 여기서 먼저 Name에는 해시 인덱스가 걸려 있다고 가정 합니다. 데이터 인서트 명령어 입력 해시 함수에 이름을 넣음 해시 함수는 해시버킷에서 번호를 반환 만약 버킷이 비어있으면, insert 되는 행의 주소를 해당 버킷에 넣습니다. 여기서 주의 할 것은 버킷이 전부 찾을 경우인데, 이것은 hash collision이라고 하며, 뒷 부분에서 설명 합니다.
• #15: Delete의 경우 붉은색 점선 네모 박스에 있듯이 end time stamp에 무한표시를 지우고, 타임스탬프를 찍습니다.
• #16: Update의 경우 메커니즘이 Disk 테이블과 다릅니다. 기본적으로 인메모리 테이블은 update라는 개념이 없습니다. 그렇다면 업데이트를 어떻게 진행 할까요? 업데이트는 삭제를 한 뒤에 값을 삽입하여 그것을 포인터로 연결합니다. 앞의 서치 과정에서 보았듯이 인메모리 옵티마이저는 행을 찾을때 무한대 표시가 나올때까지 포인터를 타고 갑니다. 이것은 update가 일어난 것에 대한 행을 서치하기 위해서 입니다.
• #17: 앞서 insert에서 말한 것 처럼 만약 해시 버킷이 모두 찬다면, 매칭 시킬 버킷이 남지 않습니다. 하여, 인메모리 테이블은 차선책으로 기존에 연결하였던 버킷값에 다음값을 포인터로 연결합니다. 키가 다름에도, 연결함으로 성능에 지대한 영향을 미칩니다. 그래서, MSDN에서는 버킷 카운터를 잘 잡으라고 강요하며, 일반적으로 예상값의 2~3배를 지정하라고 강조합니다. 여기서 버킷카운터가 너무 작아서 해시함수가 같은 값은 반환하게 되는 것을 hash collision이라고 합니다. 이것이 너무 많아지면 불필요한 행을 거쳐서 포인터를 찾아서 계속 찾아야 하므로, 성능에 저하가 발생 합니다.
• #18: Garbage Collection은 기존의 update 하였거나 delete 데이터를 정리하는 작업입니다. 앞서 보았던 update는 행을 수정하는 것이 아닌 지우고 재생성을 하는 과정을 하는 것 입니다. 하여, 체인이 길게 연결되어 있으므로, 이는 불필요하게 포인터를 많이 거쳐서 가져함을 의미합니다. 이러한 과정을 최대한 줄이기 위해서 Garbage Collection이라는 작업을 통해 불필요한 행을 완전히 지우는 작업을 합니다.
• #20: Check point - Data File (Insert 기록)과 Delta (Delete 기록)으로 구성됩니다. - 타임스탬프 기준으로 파일에 저장합니다. - Data 파일의 사이즈는 서버의 메모리가 16GB초과면 128MB 단위로 생성되며, 16GB 이하면 16MB단위로 생성됩니다. Transaction Log File - 트랜잭션 로그에 Insert/Update/Delete 내용이 기록됩니다. - 로그는 Commit 될 때 기록되기 때문에 , rollback 데이터가 기록되지 않습니다. - 실시간으로 disk에 기록하기에 memory 성능을 따라가기 위해서는 I/O가 기본적으로 좋은 SSD를 사용하길 권장 합니다. - 기존에 Lock 이나 Latch등의 병목이 없지만, 트랜잭션 로그 파일에 쓰는 과정에서 발생 할 수 있습니다.
• #21: Data 파일과 Delta 파일은 한 세트이며, Offline CheckPoint라는 백그라운드 쓰레드에 의해서 채워집니다. Offline checkpoint 는 filestream을 사용해서 지속적으로 수행되는 백그라운드 작업입니다.
• #22: Merge 작업은 delete 작업이 많이 일어났을 경우 불필요하게 저장 공간을 차지하는 것을 해소하기 위해 존재하는 작업 입니다. 일정 수준 이상의 delete 가 발생하여, Delta 파일의 공간이 매우 많아지면, 이 작업을 수행해야 합니다. Merge 작업은 Online 백그라운드 작업입니다. 이 작업은 스토리지 공간이 확보되면서 복원 속도의 향상을 기대 할 수 있습니다. Merge 작업의 단계 1. Delete가 많이 연결된 Checkpoint 파일 확인 2. 새로운 Checkpount 파일을 생성 후 delete 된 내용을 제외한 Dataa파일들의 내용을 새로운 체크포인트 파일로 복사 3. 기존의 체크포인트 파일은 삭제