TIL

03장 저장소와 검색

• 기본적으로 데이터베이스는 두 가지 작업을 수행한다.
  • 데이터를 저장
  • 후에 그 데이터를 요청 시 데이터 제공
• 데이터베이스의 저장과 검색 내부 메커니즘을 개발자가 주의해야 하는 이유
  • 여러 저장소 엔진 중 애플리케이션에 적합한 엔진을 선택해야 하기 때문
  • 특정 작업부하 유형에서 좋은 성능을 내게끔 엔진을 조정해야 하는 경우가 있음

데이터베이스를 강력하게 만드는 데이터 구조

• 가장 간단한 데이터베이스를 생각해보면 다음 두 가지 기능을 제공할 것이다.
  • db_set : 데이터 저장
  • db_get : 데이터 조회
• key-value 저장소라고 한다면 db_set 함수는 좋은 성능을 보여준다.
  • 실제로 많은 데이터베이스는 내부적으로 append-only 데이터 파일인 로그(log)를 사용하는데 매우 유용하다.
  • 데이터베이스에서 ‘로그’는 일반적인 의미로 연속된 추가 전용 레코드로서의 의미를 갖는다.
• 반면 db_get 함수는 데이터베이스에 많은 레코드가 있다면 성능이 좋지 않다.
  • 풀 스캔을 해야하기 때문에 검색 비용이 O(n)이다.
• 색인 : 데이터베이스에서 특정 키를 효율적으로 찾기 위해 사용하는 데이터 구조
  • 색인의 일반적인 개념은 어떤 부가적인 메타데이터를 유지하는 것
  • 색인을 잘 선택했다면 읽기 속도가 향상된다.
  • 하지만 모든 색인은 쓰기 속도를 떨어뜨린다.
• 개발자나 DBA는 애플리케이션의 패턴을 잘 이해하고 수동으로 색인을 선택해야 한다.
  • 애플리케이션에 가장 큰 이득을 주는 색인을 선택해 오버헤드를 최소화해야 함

해시 색인

• 인메모리 해시맵 색인
  • 키-값 데이터 구조를 가장 간단하게 색인하는 방법
  • 키를 데이터 파일의 바이트 오프셋에 매핑해 인메모리 해시 맵을 유지하는 전략
  • 값을 조회하려면 해시 맵을 사용해 데이터 파일에서 오프셋을 찾아 값을 읽는다.
• 해시 맵을 모두 메모리에 유지한다면 고성능 읽기, 쓰기를 보장할 수 있다.
  • 단 모든 키가 메모리에 저장된다는 전제가 필요하다.
  • 값은 한 번의 디스크 탐색으로 디스크에 적재할 수 있기에 메모리보다 더 많은 공간을 사용할 수 있다.
  • 각 키 값이 자주 갱신되면서 고유 키가 많지 않은 경우에 유용
• 파일에 데이터가 추가되며 디스크 공간이 부족해지면 세그먼트로 로그를 나누는 방식으로 해결한다.
  • 특정 크기에 도달하면 세그먼트 파일을 닫고 새로운 세그먼트 파일에 쓰기를 계속 수행
  • 세그먼트 파일들에 대해 컴팩션을 수행 가능 (컴팩션은 로그에서 중복된 키를 버리고 각 키의 최신 갱신 값만 유지하는 것을 의미)
    • 세그먼트는 쓰여진 후 변경할 수 없기에 병합할 세그먼트는 새 파일로 만든다.
• 각 세그먼트는 키를 파일 오프셋에 매핑한 자체 인메모리 해시 테이블을 갖는다.
  • 키의 값을 찾으려면 최신 세그먼트를 먼저 확인 후 차례로 세그먼트들을 확인해간다.
  • 병합 과정을 통해 세그먼트 수를 적게 유지하기에 많은 해시 맵을 확인하지 않아도 된다.
• 위 사항을 실제 구현하려면 많은 세부 사항을 고려해야 한다.
  • 파일 형식 - 바이너리 형식을 사용하는 편이 더 빠르고 간단 (CSV 보다는)
  • 레코드 삭제 - 삭제 시 데이터 파일에 특수한 삭제 레코드를 추가하고 세그먼트 병합 시 삭제된 키의 이전 값을 무시하게 한다.
  • 고장 복구
    • 인메모리 해시맵 복구를 위해 세그먼트 전체를 읽는 것은 오버헤드가 크다.
    • 비트캐스크는 각 세그먼트 해시맵의 스냅숏을 디스크에 저장해 복구 속도를 높인다.
  • 부분적 레코드 쓰기
    • 데이터베이스는 로그에 레코드를 추가하는 도중에 죽을 수 있기에 체크섬으로 로그의 손상된 부분을 탐지해 무시한다.
  • 동시성 제어 - 데이터 파일 세그먼트는 추가 전용이거나 불변이므로 다중 스레드로 동시 읽기를 할 수 있다.
• 추가 전용(append only) 설계는 여러 측면에서 좋은 설계다.
  • 추가와 세그먼트 병합은 순차 쓰기 작업이기에 무작위 쓰기보다 훨씬 빠르다.
  • 동시성과 고장 복구가 훨씬 간단하다.
  • 오래된 세그먼트 병합은 시간이 지남에 따라 조각화되는 데이터 파일 문제를 피할 수 있다.
• 해시 테이블 색인의 제약 사항
  • 해시 테이블이 메모리에 저장되므로 키가 너무 많으면 문제가 된다.
  • 범위 질의에 효율적이지 않다.

SS테이블

• 기존 해시 색인은 다음 특징이 있었다.
  • 로그 구조화 저장소인 세그먼트에 키-값 쌍 연속이 쓰여진 순서대로 존재
  • 같은 키를 갖는 값 중 나중 값이 이전 값보다 우선
• SS 테이블 : 정렬된 문자열 테이블 (Sorted String Table)
  • 일련의 키-값 쌍을 키로 정렬
  • 각 키는 세그먼트 파일 내 한 번만 나타나야 하고 이는 컴팩션 과정에서 보장한다.
• 기존 해시 색인과 다른 SS 테이블의 장점
  • 세그먼트 병합은 파일이 사용 가능한 메모리보다 크더라도 간단하고 효율적이다. (병합정렬 알고리즘과 유사)
  • 특정 키를 파일에서 찾기 위해 메모리에 모든 키 색인을 유지할 필요가 없다.
    • 키가 정렬되어 있기에 메모리에 있는 키를 보고 어떤 오프셋 범위에 있는지 찾을 수가 있다.
    • 수 킬로바이트 정도의 스캔은 매우 빠르기에 메모리 내 색인은 수 킬로바이트당 하나로 충분하게 되는 것
  • 디스크 공간이 절약되고 I/O 대역폭 사용을 줄일 수 있다.
    • 읽기 요청 시 인메모리 색인을 보고 요청 범위를 특정 가능하기에 해당 범위 레코드들을 블록으로 그룹화하고 디스크에 쓰기 전 압축한다.
    • 인메모리 색인의 각 항목은 압축된 블록의 시작을 가리키게 된다.

SS 테이블 생성과 유지

• 쓰기 요청이 들어오면 멤테이블(memtable) 데이터 구조에 추가한다.
  • 멤테이블: 인메모리에 유지되는 레드 블랙 트리 같은 균형 트리 (blanced tree)
• 멤테이블이 임계값보다 커지면 SS테이블 파일로 디스크에 기록 (가장 최신 세그먼트가 된다.)
• 읽기 요청이 발생하면 먼저 멤테이블에서 찾고 그 다음엔 최신 세그먼트에서부터 찾기 시작한다.
• 가끔 세그먼트 컴펙션 과정을 백그라운드에서 수행한다.
• 장애 시 멤테이블의 가장 최신 쓰기가 손실될 수 있기에 복구할 때 사용할 분리된 로그를 디스크 상에 유지해야 한다.

SS 테이블에서 LSM 트리 만들기

• LSM (Log-Structured Merge-Tree) 저장소 엔진
  • 정렬된 파일 병합과 컴팩션 원리를 기반으로 하는 저장소 엔진
  • 즉 SS테이블을 기반으로 하는 저장소 엔진이라 볼 수 있다.
• LSM이 사용되는 라이브러리 또는 DB
  • 레벨 DB와 록스 DB 또는 내장 키-값 저장소 엔진 라이브러리에서 사용
  • 카산드라와 HBase에서도 유사한 저장소 엔진을 사용
  • 엘라스틱서치나 솔라에서 사용하는 전문 검색 색인 엔진인 루씬(Lucene)에서도 용어 사전(term dictionary)를 저장할 때 유사한 방법을 사용

성능 최적화

• 블룸 필터 (Bloom filter)
  • LSM 트리 알고리즘은 존재하지 않는 키 검색은 멤테이블 → 전체 세그먼트를 탐색하기에 느리다.
  • 없는 키에 접근하는 경우를 최적화하기 위해 키가 없음을 알려주는 블룸 필터를 사용한다.
• SS 테이블을 압축하고 병합하는 순서와 시기를 결정하는 다양한 전략이 존재
  • 크기 계층(size-tiered) 컴팩션 : 상대적으로 더 작은 SS테이블을 더 큰 SS테이블에 연이어 병합
  • 레벨 컴팩션 (leveled compaction) : 키 범위를 더 작은 SS 테이블로 나누고 오래된 데이터는 개별 “레벨”로 이동시켜 컴팩션을 점진적으로 진행해 디스크 공간을 덜 사용한다.
• LSM 트리의 기본 개념은 백그라운드에서 연쇄적으로 SS테이블을 지속적으로 병합하는 것
  • 데이터셋이 가능한 메모리보다 훨씬 크더라도 효과적인 방법
  • 데이터가 정렬되어 있어 질의를 효율적으로 실행 가능
  • 디스크 쓰기가 순차적이기에 높은 쓰기 처리량 보장 가능

B 트리

• B 트리 (B-tree) 색인 구조는 가장 널리 사용되는 색인 구조다.
• B 트리는 SS테이블처럼 키로 정렬된 키-값 쌍을 유지한다.
• B 트리는 4KB 크기의 고정 크기 블록이나 페이지로 나누고 한 번에 한 페이지에 읽기 또는 쓰기를 한다.
  • 가변 크기의 세그먼트를 가지는 LSM과는 다르다.각 페이지는 주소나 위치로 식별할 수 있고 이 방식으로 다른 페이지를 참조할 수 있다.
• 한 페이지는 B 트리의 루트(root)로 지정된다.
  • 한 페이지는 B 트리의 루트로 지정되어 키를 찾으려면 루트에서 시작해야 한다.
  • 최종적으로는 개별 키를 포함하는 리프 페이지에 도달한다. (leaf page)
  • 리프 페이지는 각 키 값을 포함하거나 값을 찾을 수 있는 페이지의 참조를 포함한다.
• 분기 계수 (branching factor)
  • B 트리 한 페이지에서 하위 페이지를 참조하는 수
  • 보통 수백 개에 달한다.
• B 트리는 계속 균형을 유지하는 것을 보장한다.
  • n개 키를 가진 B 트리는 깊이가 항상 O(log n)이다.

신뢰할 수 있는 B 트리 만들기

• B 트리는 기본적으로 새로운 데이터를 디스크 상의 페이지에 덮어쓴다.
  • 페이지 위치를 변경하지 않기에 모든 참조가 온전히 남는다.
  • 파일을 추가하기만 하는 LSM 트리와 대조적
• B 트리는 데이터베이스 장애 시 복구를 위해 쓰기 전 로그(write-ahead log, WAL)(redo log) 데이터 구조를 추가해 구현한다.
• 동일 페이지에 동시에 접근하려는 경우 보통 래치(latch) 잠금으로 트리의 데이터 구조를 보호한다.
  • 유입 질의 간섭 없이 백그라운드에서 모든 병합을 수행
  • 이따금 원자적으로 새로운 세그먼트를 이전 세그먼트로 바꾸기 때문

B 트리 최적화

• 고장 복구를 위한 WAL 유지 대신 일부 데이터베이스는 쓰기 시 복사 방식(copy-on-write scheme)를 사용한다.
  • 변경된 페이지를 다른 위치에 기록하고 트리 상위 페이지에 새 버전을 만들어 새로운 위치를 가리키게 한다.
• 페이지에 키를 축약해 쓰면 공간을 절약할 수 있다.
  • 트리 내부 페이지에서 키가 키 범위 사이의 경계 역할을 하는 데 충분한 정보만 제공
  • 페이지 하나에 키를 더 많이 채우면 트리는 높은 분기 계수를 얻어 트리 깊이를 낮출 수 있다.
• 많은 B 트리 구현에서 리프 페이지를 디스크 상에 연속된 순서가 되게끔 배치하려 시도한다.
  • 질의가 정렬된 순서로 키 범위의 상당 부분을 스캔해야 하는 경우 효율적
• 트리에 포인터 추가
  • ex) 각 리프 페이지가 양쪽 페이지에 대한 참조를 가지면 상위 페이지로 이동하지 않아도 순서대로 키를 스캔 가능

B 트리와 LSM 트리 비교

• 경험적으로 LSM 트리는 보통 쓰기에 더 빠르고 B 트리는 읽기에서 더 빠르다.
  • LSM 트리는 각 컴팩션 단계에 있는 여러 데이터 구조와 SS 테이블을 확인해야 하기에 읽기가 느리다.
  • B 트리는 데이터를 최소 두 번 기록해야 해서(WAL 한 번, 트리 페이지에 한 번) 쓰기가 느리다.
• 쓰기 중폭 (write amplification)
  • 데이터베이스에 쓰기 한 번이 데이터베이스 수명 동안 디스크에 여러 번의 쓰기를 야기하는 효과
• LSM 트리 장점
  • LSM 트리가 상대적으로 쓰기 증폭이 낮고 여러 페이지를 덮어쓰는 것이 아닌 순차적으로 컴팩션된 SS 테이블에 파일을 쓰기 때문에 B 트리보다 쓰기 처리량이 높다.
  • 압축률이 좋아 B 트리보다 디스크에 더 적은 파일을 생성한다.
• LSM 트리 단점
  • 컴팩션 과정이 때로는 읽기와 쓰기 성능에 영향을 준다.
    • 디스크의 쓰기 대역폭은 유한한데 초기 쓰기(로깅), 멤테이블을 디스크로 플러시, 백그라운드에서 컴팩션 등의 작업이 이 대역폭을 공유해야 한다.
  • 쓰기 처리량이 높지만 컴팩션 설정에 주의하지 않으면 컴팩션이 유입 쓰기 속도를 따라갈 수 없다.
• B 트리 장점
  • 각 키가 색인의 한 곳에만 정확하게 존재한다는 점이다. (LSM에선 같은 키의 다중 복사본이 존재 가능)
  • 때문에 강력한 트랜잭션 시맨틱을 제공하는 데이터베이스에선 B 트리가 더 매력적이다.

기타 색인 구조

• 키-값 색인의 대표적인 예는 관계형 모델의 기본키(primary key) 색인이다.
  • 관계형 테이블에선 하나의 Row를 식별
  • 문서 데이터베이스에선 하나의 문서를 식별
  • 그래프 데이터베이스에선 하나의 정점을 식별
• 보조 색인(secondary index)
  • 관계형 데이터베이스에선 CREATE INDEX 명령으로 보조 색인을 생성한다.
  • 효율적인 조인 수행에 결정적인 역할을 한다.
  • 기본키 색인과 차이점은 키가 고유하지 않다는 점

색인 안에 값 저장하기

• 색인에서 값은 다음 두 가지 중 하나에 해당한다.
  • 키의 실제 로우(문서 or 정점)
  • 다른 곳에 저장된 로우를 가리키는 참조
• 후자의 경우 로우가 저장된 곳을 힙 파일(heap file)이라 한다.
  • 순서 없이 데이터를 저장
  • 각 색인은 힙 파일에서 위치만 참조하고 실제 데이터는 일정한 곳에 유지한다.
• 힙 파일 접근 방식은 키 변경 없이 값을 갱신할 때 효율적이다.
  • 새 값이 이전 값보다 용량이 작다면 레코드를 덮어쓸 수 있다.
  • 새 값이 용량이 더 크다면 힙에서 새로운 곳으로 위치를 이동해야 한다.
    • 모든 색인이 새로운 힙 위치를 가리키도록 갱신하거나 이전 힙 위치에 전방향 포인터를 남겨둬야 한다.
• 클러스터드 색인 (clustered index)
  • 색인에서 힙 파일로의 이동은 비효율적이기에 색인 안에 바로 색인된 로우를 저장하는 방식
  • MySQL의 InnoDB 저장소 엔진에선 테이블 기본키가 클러스터드 색인이고 보조 색인은 기본키를 참조한다.
• 커버링 색인 (covering index)
  • 클러스터드 색인과 비클러스터드 색인 사이의 절충안
  • 색인 안에 테이블 칼럼 일부를 저장하여 일부 질의에 바로 응답 가능하도록 한 방식
• 색인의 단점
  • 추가적인 저장소가 필요
  • 쓰기 과정에 오버헤드 발생

다중 칼럼 색인

• 결합 색인 (concatenated index)
  • 다중 칼럼 색인의 가장 일반적인 유형
  • 하나의 키에 여러 필드를 단순히 결합한다.
  • ex) (성, 이름)을 키로, 전화번호를 값으로
• 다차원 색인
  • 한 번에 여러 칼럼에 질의하는 일반적인 방법
  • 특히 지리 공간 데이터에서 중요하게 사용된다.
  • 표준 B 트리나 LSM 트리 색인은 다차원 범위 질의에 효율적이지 못하다.
  • ex) 아래는 특정 지리 공간에 있는 레스토랑을 찾는 SQL

SELECT * FROM restarants WHERE latitude > 51.4936 AND latitude < 51.5079 
				AND logitude > -0.1162 AND longitude < -0.1004;

• 다차원 질의를 효육적으로 하는 방법
  • 이차원 위치를 공간 채움 곡선을 이용해 단일 숫자로 변환한 다음 B 트리 색인 사용
  • R 트리 같은 전문 공간 색인(specialized spatial index) 사용

전문 검색과 퍼지 색인

• 유사한 키에 대한 검색과 애매모호한 질의에 대해 전문 검색과 퍼지 색인을 활용할 수 있다.
• 전문 검색 엔진
  • 단어의 문법적 활용을 무시하고 동일 문서에서 인접해 나타난 단어를 검색
  • 언어학적으로 텍스트를 분석하는 기법을 사용하기도 함
  • ex) 루씬은 특정 편집 거리(편집 거리 1은 한 글자가 추가 혹은 삭제 혹은 교체) 내 단어를 검색 가능
• 그 밖의 퍼지 검색 기술은 문서 분류 및 머신러닝의 방향으로 진행되고 있다.

모든 것을 메모리에 보관

• 인메모리 데이터베이스
  • 데이터 전체를 디스크가 아닌 메모리에 보관하는 데이터베이스
  • 램이 점점 저렴해지고 여러 장비 간 분산 보관도 가능하기에 등장하게 되었다.
• 인메모리 데이터베이스는 지속성을 목표로 한다.
  • 배터리 전원 공급 RAM과 같은 특수 하드웨어를 사용하는 방법을 사용하거나
  • 디스크에 변경 사항 로그 또는 스냅숏을 주기적으로 기록하여 인메모리 상태를 복제하는 방법을 사용한다.
• 인메모리 데이터베이스의 성능 장점
  • 데이터를 디스크에서 읽지 않아도 된다.
    • 디스크 기반 저장소도 많은 데이터를 메모리에 캐시하기에 그렇게 큰 장점은 아닐 수 있다.
  • 인메모리 데이터 구조를 디스크에 기록하기 위한 형태로 부호화하는 오버헤드를 피할 수 있다.
  • 디스크 기반 색인으로 구현하기 어려운 우선순위 큐와 셋(set) 같은 데이터 구조를 제공한다.

트랜잭션 처리나 분석?

• 온라인 트랜잭션 처리 (online transaction processing, OLTP)
  • 사용자 대면 애플리케이션에서 주로 사용되는 패턴
  • 질의당 적은 수의 레코드를 키 기준으로 조회
  • 사용자 입력을 낮은 지연 시간으로 기록
  • 데이터의 최신 상태를 표현
  • 기가바이트에서 테라바이트
• 온라인 분석 처리 (online analytic processing, OLAP)
  • 데이터 분석가가 사용하는 패턴으로 복잡한 질의를 수행
  • 많은 레코드의 대한 집계를 주로 질의
  • 시간이 지나며 일어난 이벤트의 이력을 주로 표현
  • 테라바이트에사 페타바이트
• OLTP 시스템은 대개 사업 운영이 대단히 중요하기에 높은 가용성과 낮은 지연의 트랜잭션 처리를 기대한다.
  • 분석 질의를 수행할 때 OLTP에 직접 질의하는 것을 지양해야 한다.

데이터 웨어하우징

• 데이터 웨어하우스
  • OLTP 작업에 영향을 주지 않고 분석 질의를 마음껏 수행 가능한 개별 데이터베이스
  • 회사 내 다양한 OLTP 시스템에 있는 데이터의 읽기 전용 복사본
  • 분석 질의는 SQL에 적합하기에 웨어하우스의 데이터 모델은 관계형 모델을 사용한다.
• 개별 데이터 웨어하우스 사용의 장점
  • 분석 접근 패턴에 맞춰 데이터베이스를 최적화할 수 있다.
  • 웨어하우스와 OLTP 데이터베이스는 각각 매우 다른 질의 패턴에 맞게 최적화되었다.

분석용 스키마: 별 모양 스키마와 눈꽃송이 모양 스키마

• 스타 스키마 (star schema)
  • 차원 모델링(demensional modeling)로도 알려짐
  • 중앙의 사실 테이블(fact table)과 이를 둘러싼 여러 개의 차원 테이블(demension table)로 구성
  • 사실 테이블
    • 비즈니스 측정값(매출, 수량 등)을 포함
    • 특정 시각에 발생한 이벤트를 각 로우로 가짐
    • 각 차원 테이블의 외래 키를 포함
    • 일반적으로 차원 테이블보다 큰 크기를 가짐
  • 차원 테이블
    • 이벤트의 속성인 누가, 언제, 어디서, 무엇을, 어떻게, 왜를 나타낸다.
    • 비정규화된 형태로 데이터 저장
    • 서로 간에 직접적인 조인이 없음
    • 분석에 필요한 속성들을 저장(시간, 제품, 고객, 지역 등)
• 스노우플레이크 스키마 (snowflake schema)
  • 스타 스키마 템플릿의 변형으로 차원이 하위 차원으로 더 세분화된다.

칼럼 지향 저장소

• 대부분의 OLTP 데이터베이스는 로우 지향 방식으로 데이터를 배치한다.
  • 한 로우의 모든 값은 인접하게 저장됨
  • 한 로우에서 특정 값만 필요하더라도 질의를 처리하기 위해선 디스크에서 로우들을 메모리에 적재한 다음 필터링할 필요가 있는 것
• 칼럼 지향 저장소
  • 모든 값을 한 로우에 저장하지 않고 각 칼럼별로 모든 값을 함께 저장한다.
  • 덕분에 질의에 사용되는 칼럼만 읽고 분석할 수 있다.
  • 각 칼럼 파일에 포함된 로우가 모두 같은 순서이기에 로우의 전체 값을 모으려면 개별 칼럼 파일의 같은 순서번째 항목을 가져와 합치면 된다.

칼럼 압축

• 칼럼 지향 저장소는 압축에 적합하다.
• 비트맵 부호화 (bitmap encoding)
  • 데이터를 0과 1의 비트 시퀀스로 표현하는 방식
  • 각 고유값에 대해 별도의 비트맵을 생성하여 데이터의 존재 여부를 표시
  • 고유값 하나가 하나의 비트맵이고 각 로우는 한 비트를 가지는데 해당 값을 가지면 비트는 1, 아니면 0
  • 카디널리티가 낮은 데이터에 적합
• 메모리 대역폭과 백터화 처리
  • 칼럼 저장소 배치는 CPU 주기를 효율적으로 사용하기 적합하다.
  • 칼럼 압축을 통해 같은 양의 CPU의 L1 캐시에 칼럼의 더 많은 로우를 저장할 수 있다. (백터화 처리 기법)
  • 덕분에 메인 메모리에서 CPU로 가는 대역폭을 효율ㅈ거으로 사용할 수 있다.

칼럼 저장소의 순서 정렬

• 데이터는 특정 칼럼을 기준으로 정렬되어 저장할 수 있다.
  • 순서 정렬은 데이터 압축과 쿼리 성능을 최적화하는 중요한 기술
  • 순서를 도입하여 색인 메커니즘으로 활용 가능
• 정렬 제약
  • 각 칼럼을 독립적으로 정렬할 수는 없음
  • 데이터는 전체 로우 단위로 정렬되어야 함
• 정렬된 순서의 장점
  • 고유 값을 많이 포함하지 않는 데이터셋의 경우 정렬 후 같은 값이 연속해서 반복되게 되는데 수십억 개 로우라도 런 렝스 부호화로 수 킬로바이트로 압축할 수 있다.
  • 이러한 압축 효과는 첫 번째 정렬 키에서 가장 강력하다.
• 다양한 순서 정렬
  • 여러 복제 데이터를 서로 다른 방식으로 정렬하는 방식이 있다.
  • 질의를 처리할 때 가장 적합한 버전을 사용할 수 있다.
  • 로우 지향 저장소의 2차 색인과 비슷하지만 포인터만 포함한다는 점에서는 큰 차이가 있다.

칼럼 지향 저장소에 쓰기

• 칼럼지향 저장소는 질의는 빠르지만 쓰기가 어렵다는 단점이 있다.
  • B 트리에서 쓰이는 제자리 갱신 접근 방식은 압축된 칼럼에서는 불가능하다.
  • 정렬된 테이블의 중간에 로우 삽입을 원한다면 모든 칼럼 파일을 재작성해야 한다.
• LSM 트리라는 좋은 해결책이 이미 존재한다.
  • 모든 쓰기는 먼저 인메모리 저장소로 이동해 정렬된 구조에 추가
  • 충분한 쓰기를 모으면 디스크 칼럼 파일에 병합

집계: 데이터 큐브와 구체화 뷰

• 구체화 집계 (materialized aggregate)
  • 데이터 웨어하우스 질의는 보통 SQL의 SUM 같은 집계 함수를 포함한다.
  • 질의가 자주 사용하는 일부 집계 질의 결과를 캐시
• 구체화 뷰 (materialized view)
  • 데이터 큐브 또는 OLAP 큐브라고도 알려짐
  • 집계 질의를 캐시하는 한 가지 방법으로 쿼리 결과를 미리 계산하여 물리적으로 저장해둔 데이터베이스 객체
  • 복사된 비정규화 데이터이기에 원본이 변경되면 갱신해야 한다.
  • 이러한 갱신은 비싸기에 OLTP는 구체화 뷰를 자주 사용하진 않지만 웨어하우스에선 합리적이다. (읽기 비중이 많음)
• 단점은 원시 데이터에 질의하는 것보다 유연성이 떨어진다.
  • 특정 질의에 대한 성능 향상에만 사용한다.