저장소와 검색 [데이터 중심 애플리케이션 설계 3장]

1. 로그 구조 저장소: 쓰기에 좋은 구조
   1. LSM 트리: SS 테이블을 여러개로 구성된 인덱스 구조
      1. SS 테이블: merge sort 방식으로 순차적으로 쌓인 키를 컴팩션 시 정렬하여 저장
      2. 순차적으로 write하기 때문에 속도가 빠르다.
      3. 페이지를 사용하지 않아 오버헤드가 적어 압축률이 좋다.
      4. 컴팩션 과정이 있기 때문에 성능에 영향을 줄 수가 있다.
2. 페이지 지향 저장소: 읽기에 좋은 구조
   1. B 트리: 고정 크기의 블록이나 페이지로 나누고 한 페이지에서 다음 페이지를 참조한다.
      1. B 트리의 쓰기는 디스크 상의 페이지를 덮어쓴다.
      2. 이것은 문제 발생 시 위험한 동작으로 WAL(Write-ahead log)를 추가해서 문제 발생 이후에도 복구가 가능하도록 한다. (copy-on-write scheme 방식도 있음)
      3. WAL과 실제 트리에 2번 써야 하는 단점이 생기고, 페이지 일부가 변경되도 전체 페이지를 기록해야 한다.
3. 색인(Index) 구조
   1. 색인의 값은 실제 row거나 참조이다. 일반적으론 heap을 참조한다.
   2. clusted index는 실제 row를 저장하는 방식
   3. covering index는 index에 테이블 컬럼의 일부를 저장
   4. concatenated index는 여러 컬럼 순서쌍으로 저장
4. 인메모리
   1. 일반적으로 디스크가 아닌 메모리에 데이터를 저장하고 있기 때문에 성능이 빠르다고 한다.
      1. 메모리가 충분히 크다면 일반적인 데이터베이스도 메모리에서 동작하기 때문에 성능이 빠를 수 있고, 오히려 오버헤드도 적다.
   2. 디스크 기반 색인으로 구현하기 어려운 데이터 모델을 제공
      1. redis에선 우선순위 큐나 셋 같은 구조를 제공
   3. 인메모리 데이터베이스도 디스크를 사용하기도 한다.
      1. swap 처럼 최근 사용하지 않는 데이터를 디스크에 내린다.
      2. 비휘발성을 위해 데이터를 디스크에 저장하고 있다.
5. 트랜젝션
   1. 사실 ACID가 필수 아님
   2. OLTP: 적은 수의 레코드를 키 기반으로 가져옴
   3. OLAP: 많은 레코드를 집계함
6. 컬럼 지향 저장소: 주로 분석용에서는 많은 로우를 사용하고 많은 컬럼 중 일부만 사용하기 때문에 로우 기반이 아닌 컬럼 기반이 효율적이다.
   1. 컬럼 압축 가능 (비트맵 부호화)
   2. 컬럼 패밀리는 컬럼 압축을 사용하지 않고 로우 지향적이다.
   3. 데이터 집계: 분석용에서는 집계를 많이 사용하게 된다.
      1. 구체화 뷰(materialized view)는 이런 집계를 만드는 쿼리를 미리 실행 시켜 저장한다. (일반적인 뷰는 가상(virtual) 뷰라 실제로 값을 저장하고 있진 않는다.)
      2. 데이터 큐브: 여러 컬럼들을 다양한 차원으로 그룹화한 집계 테이블을 저장하고 있다. → 일부 값만 가져오는 집계는 커버하지 못 한다.