실제 구현할 때 주의해야 하는 점

• 부분적으로 레코드 쓰기 (잘 이해가 안됨..)

컴팩션과 세그먼트 병합

• 병합이 어떻게 되는지? 작성한 순서대로라면 모든 세그먼트에 쓰기작업에 시간을 표시해야하는지?

SS Table

• Devide & Conquer의 장점을 제대로 살린 자료구조

멤테이블

• 쓰기 요청이 들어오면 버퍼의 느낌으로 멤테이블에 추가 but, Threshold를 벗어나면 디스크 저장. → 그렇다면 쓰기 요청이 많은 작업에는 어떻게 활용? 멤테이블이 비워지면 파일에서 Threshold만큼 read 하는지? 멤테이블이 고장나면? 결국 쓰기 로그는 별도로 계속 남겨야함..

B-Tree

• 가장 널리 알려진 방법. 동시성 문제를 해결하기 위해 Latch (Lock) 방식을 사용.

쓰기증폭

• 한 번의 쓰기를 위해 여러번 쓰기 작업이 필요함. 1+N
• B-Tree보다 LSM 트리가 쓰기 증폭이 낮다. B-Tree는 겁나 쓴다. (WAL, 트리 페이지, 페이지 내 데이터 수정 시 전체 페이지를 다시 써야하는 오버헤드도 존재.
• SSD는 쓰기 횟수가 제한되어있기에 겁나 쓰는 B-Tree 방식은 안맞다 생각. B-Tree에는 덮어쓸 수 있는 HDD가 나음.

LSM 트리와 B-트리의 비교

• LSM 트리가 B-트리보다 쓰기 처리량이 높지만 컴팩션이 쓰기 요청 속도를 못따라갈 수 있음. 그래서 항시 쓰기 요청을 충분히 감당하는지에 대한 모니터링이 추가적으로 필요. 더불어, 세그먼트가 나뉘어져 있기 때문에 중복된 키들이 파편화 되어 있을 수 있음. B-Tree와 LSM-Tree의 장/단점은 서로 너무 명확하다!

데이터 웨어하우스

• 웨어하우스: 물류창고, 정보제공이 우선. 비즈니스 니즈에 의해 만들어진 느낌

별 모양 스키마

• 사실 테이블이 가운데 있고 차원 테이블로 둘러싸인 모양. Database의 View와 느낌이 흡사. 각 차원 테이블은 각 테이블이 표현하고자 하는 의도가 분명히 있고 View 또한 제한된 정보만을 표현하게끔 구현되어있음