인메모리 DBMS 엔지니어 입장에서 대충 아키텍쳐를 분석해보는 시간이 필요하다 생각되어 일단 그림만으로 느껴지는 감상 정리.
- In-Memory Structure
1) buffer pool
2) change buffer
3) log buffer
평범한 mvcc 아키텍쳐로 보이나 Change buffer의 존재는 무엇일지 의문이다. 단순히 그림만 봐서는 Datafile flush를 위한 버퍼가 아닐 까 싶다.
그나저나 SSA와 같은 개념은 없는 것인지?
log buffer는 평범해 보이고 해시 인덱스를 주로 사용하는 듯 하다. B-Tree 인덱스도 있긴 한걸로 알긴 하는데... 주목할 점은 버퍼 풀에서의 O_DIRECT 개념? OS cache를 거치지 않고 바로 Datafile에다 쏜다는 개념인가?
- On-Disk Structures
1) System Tablespace
아까 말했던 것처럼 Change Buffer가 존재한다. 아무래도 Memory 와 Disk의 임시 버퍼로 존재하는 듯 하다. 이 부분은 자세한 설명이 매뉴얼에도 있으니 참고해봐야겠음.
2) File-Per-Table Tablespaces
Influxdb가 이런 식으로 데이터파일을 관리하던데.. 특정 테이블을 개별 데이터파일로 관리하고, 이로 인한 장점은 이 쯤 될 것 같다.
- Disk 효율성 극대화
- Log성 테이블 분리를 통한 관리 용이
- Tablespace 관리 용이( 이는 벤더별로 다를 지 모르겠으나, Tablespace를 datafile 여러개로 관리한다 하더라도 세그먼트를 사용하면 datafile을 줄일 수 없으므로 한번 늘리면 줄이기 힘든 리스크가 있는 것으로 알고 있다. 테이블 단위로 관리한다면 datafile을 줄이고 늘리기 쉽게 됨 )
단점은 이정도
- Join 등 연산 시 비효율적인 IO발생으로 인한 속도 저하
- buffer pool에 부분적으로 데이터를 올리는게 제대로 가능할지?
여러모로 log성 테이블 관리를 위한 개념이 아닌가 싶기도.
3) Doublewrite Buffer Files
이건...좀 미스테리하다. 이름으로 예상해 보기도 힘든데, Buffer pool -> doublewrite buffer -> general tablespace 이렇게 가는건지?
차후에 알 수 있겠지.
4) System tablespace, general tablespace, undo tablespace, Redo log
이 부분은 그냥 평범한 MVCC 기반의 개념으로 보인다.
Redo log와 같은 경우는 Circular 형식. 무난 그 자체..
5) Temp Tablespace
Global과 Session으로 나누는 것이 특이한 부분인데... Session Temp와 Global Temp를 나눔으로서 테이블스페이스 관리는 용이해질 수 있을 것 같다. 추측해 보건데 Session temp의 캐파를 설정할 수 있을 듯 함. 이를 설정해서 특정 세션이 temp를 다 물고 안 놔주는 그런 상황을 방지할 수 있을 것이고 이는 운영 부담을 줄이는 역할을 할 것이다.
그나저나 일반 Global temp는 무엇을 하는 것일까. In-Memory에선 Index를 temp에서 관리하기 때문에 Global temp의 존재 가치를 잘 알겠지만, mysql도 비슷한 구조가 있을지?
=============================================
일반적인 mvcc 아키텍쳐에서 큰 차이를 보이진 않지만, 아마도 Change buffer가 mysql만의 특장점이 되지 않을지?
하나씩 파 봐야겠다.
