책너두 (데이터 중심 애플리케이션 설계) 8일차 (~112p)

요약

• 칼럼 지향 저장소에 대한 내용을 이해하게 됨.
  • 칼럼별 값을 저장한다.
• 칼럼 압축에 대한 내용을 이해하게 됨.
  • 데이터 압축을 통해 디스크 처리량을 줄임.
  • 대표적인 압축 기법으로 비트맵 부호화가 있음.
    • 비트맵 부호화에 대한 이해가 좀 더 필요함..
  • 병목을 줄이기 위해 메모리 대역폭을 효율적으로 사용해야 함.
    • 칼럼 압축을 통해, 비트 연산이 가능해지게 되는데, 이를 벡터화 처리라고 함.
• 칼럼 저장소의 순서 정렬에 대해 이해하게 됨.
  • 색인 메커니즘으로 사용 가능
  • 칼럼 압축에도 도움이 됨.
• 칼럼 지향 저장소에 쓰기에 대한 내용을 이해하게 됨.
  • 읽기 효율을 높인만큼 쓰기 효율이 낮아짐.
  • B 트리로는 압축된 칼럼에서 쓰기에 대한 수행을 할 수 없음.
  • LSM트리로는 가능함.
• 데이터 큐브와 구체화 뷰에 대한 내용을 알게 됨.
  • 데이터 웨어하우스의 다른 측면으로 볼 수 있음.
  • 질의 집계에서 캐시를 미리 해둘 수 있음.
  • 데이터 큐브에 대한 이해가 좀 더 필요함..

메모

칼럼 지향 저장소

• 테이블에 엄청난 개수의 로우와 페타바이트 데이터가 있다면 효율적으로 저장 & 질의하기 어려움
• 사실 테이블은 칼럼이 보통 100개 이상이지만, 데이터 웨어하우스 질의는 한 번에 4~5개 칼럼만 접근함.
  • 대부분의 OLTP 데이터베이스에서는 로우 지향 방식으로 데이터를 배치함.
    • 즉, 데이터가 많을 경우, 메모리를 적재하여 구문을 해석 & 필터링해야 하는데, 메모리에 적재된 데이터가 많을 경우 작업 시간이 오래걸림.
• 칼럼 지향 저장소는 모든 값을 하나의 로우에 함께 저장하지 않고, 칼럼별로 모든 값을 함께 저장한다.
  • 각 칼럼을 개별 파일에 저장하면, 질의에 사용되는 칼럼만 읽고 구문을 분석하면 되기에 작업량이 많이 줄어든다.

칼럼 압축

• 데이터를 압축하면 디스크 처리량을 더 줄일 수 있음.
  • 칼럼 지향 저장소는 대개 압축에 적합함.
  • 칼럼 값이 중복이 많다면, 압축하기 좋음.
• 칼럼의 데이터에 따라 다양한 압축 기법을 사용할 수 있음.
  • 한 가지 기법은 데이터 웨어하우스에 특히 효과적인 비트맵 부호화(bitmap encoding) 이다.
    • 데이터 양을 최소화하기 위한 부호화 방법임.
  • 비트맵 부호화를 이용한 비트맵 색인은 데이터 웨어하우스에서 일반적으로 사용되는 질의 종류에 매우 적합함.

메모리 대역폭과 벡터화 처리

• 수백만 로우를 스캔해야 하는 데이터 웨어하우스는 디스크로부터 메모리로 데이터를 가져오는 대역폭이 큰 병목임.
  • 하지만 이 병목만 유일한 것은 아님.
  • 분석용 데이터베이스 개발자는 아래를 신경써야 함.
    • 메인 메모리 → CPU 캐시로 가는 대역폭을 효율적으로 사용해야 함.
    • CPU 에서 단일 명령 다중 데이터 명령을 사용하게끔 신경써야함.
• 디스크 적재 데이터 양 줄이기 외에도, 칼럼 저장소 배치는 CPU 주기를 효율적으로 사용하기에 적합함.
  • 압축 칼럼 데이터를 CPU의 L1 캐시에 딱 맞게 덩어리로 나누어 가져오고, 이 작업을 (함수 호출이 없는)타이트 루프에서 반복한다.
  • CPU는 함수 호출이 많이 필요한 코드, 레코드 처리를 위해 분기가 필요한 코드보다 타이트 루프를 훨씬 빠르게 실행할 수 있음.
  • 칼럼 압축을 사용하면 같은 양의 L1 캐시에 칼럼의 더 많은 로우를 저장할 수 있음.
  • 압축된 데이터 덩어리는 AND, OR 과 같은 비트 연산자로 바로 연산할 수 있게 설계 되어 있음.
    • 이 기법을 벡터화 처리(vectorized processing) 라고 함.

칼럼 저장소의 순서 정렬

• 칼럼 저장소는 로우가 저장되는 순서가 반드시 중요하지 않음.
  • 하지만 SS테이블에서 했던 것처럼 순서를 도입하여 색인 메커니즘으로 사용할 수 있음.
• 각 칼럼을 독립적으로 정렬할 수는 없음.
  • 칼럼별로 저장됐을 지라도 데이터는 한번에 전체 로우를 정렬해야 함.
  • 하나의 칼럼을 정렬하면, 질의 최적화기가 질의시, 정렬되어 있기에 해당되는 로우만 스캔 가능함.
• 첫 번째 칼럼에서 같은 값을 가진 로우 들은, 두 번째 칼럼에서 정렬 순서를 지정할 수 있음.
• 정렬된 순서는 칼럼 압축에 도움이 됨.
  • 고유 값을 많이 포함하지 않으면, 정렬 후 기본 정렬 칼럼은 연속해서 같은 값이 길게 반복됨.
    • 런 렝스 부호화가 적용된 경우, 수십억 개의 로우를 가진 테이블도 수 킬로바이트로 칼럼을 압축할 수 있음.(p101 그림 참고)

다양한 순서 정렬

• 질의가 다양할 수록, 서로 다른 정렬 순서가 도움이 됨.
  • 같은 데이터를 다양한 방식으로 정렬해서 저장한다면, 질의를 처리할 때 질의 패턴에 가장 적합합 버전을 사용할 수 있음.
  • 로우 지향 저장에서 여러 2차 색인을 갖는 것과 약간 비슷함.
    • 단, 칼럼 저장은 데이터를 가리키는 포인터가 없고, 단지 값을 포함한 칼럼만 존재함.

칼럼 지향 저장소에 쓰기

• 칼럼 지향 저장소, 압축, 정렬은 모두 읽기 질의에 더 빠르게 하지만, 쓰기를 어렵게 하는 단점이 있음.
• B 트리와 같이 제자리 갱신(update-in-place) 접근 방식은 압축된 칼럼에서 불가능함.
  • 정렬된 테이블의 중간에 있는 로우에 삽입을 해야할 경우, 모든 칼럼 파일을 재작성해야 함.
  • 여기서는 LSM 트리가 좋은 해결책임.
    • 모든 쓰기는 먼저 인메모리 저장소로 이동하여 정렬된 구조에 추가하고, 디스크에 쓸 준비를 한다.
    • 충분한 쓰기를 모으면, 디스크 칼럼 파일에 병합하고, 대량으로 새로운 파일에 기록한다.
      • 질의가 오면, 디스크 칼럼 데이터와 메모리의 최근 쓰기를 모두 조사하여, 두 가지를 결합해야 함.

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

• 모든 데이터 웨어하우스가 칼럼 저장이 필수는 아님.
  • 하지만 칼럼 저장소는 즉석 분석 질의에 상당히 빨라서 급속도로 인기를 얻고 있음.
• 데이터 웨어하우스와 다른 측면으로 구체화 집계(materialized aggregate)가 있음.
  • 동일한 집계에 대해 많은 다양한 질의에 사용하면 매번 원시 데이터를 처리할 때 발생하는 일은 낭비임.
    • 질의가 자주 사용하는 일부 카운트, 합을 캐시할 수 있다.
      • 한 가지 방법으로 구체화 뷰(materialized view) 임.
      • 관계형 데이터베이스에서는 이 캐시를 대체로 표준 (가상) 뷰로 정의함.
      • 표준 뷰는 테이블 같은 객체로 일부 질의의 결과가 내용임.
        • 구체화 뷰는 디스크에 기록된 질의 결과의 실제 복사본이지만, 가상 뷰는 질의를 작성하는 단축키가 차이점임.
      • 원본 데이터를 변경하면 구체화 뷰를 갱신해야 함.
        • 구체화 뷰는 원본 데이터와 비정규화된 복사본이기 때문임.
        • 데이터베이스는 이 작업을 자동 수행할 수 있음.
          • 대신, 이 갱신으로 인한 쓰기는 비용이 비싸므로 OLTP 데이터베이스에서는 구체화 뷰를 자주 사용하지 않음.
          • 데이터 웨어하우스는 읽기 비중이 크므로, 구체화 뷰를 사용하는 전략은 합리적임.
      • 데이터 큐브(data cube) 또는 OLAP 큐브라고 알려진 구체화 뷰는 일반화된 구체화 뷰의 특별 사례임. (p105)
        • 장점 : 특정 질의를 효과적으로 미리 계산했기 때문에 해당 질의를 수행하면 매우 빠름.
        • 단점 : 원시 데이터에 질의하는 것과 동일한 유연성이 없다는 점임.