[Data-Intensive] Ch3. 저장소와 검색 - OLTP/OLAP/DW

저장소와 검색

‘데이터 중심 애플리케이션 설계’를 읽고 정리하고자함

정리

• 저장소 엔진은 트랙잭션 처리 최적화(OLTP)와 분석 최적화(OLAP)로 큰 두가지 범주로 나눔
• OLTP

  • 사용자 대면이기 때문에 대량의 요청을 받을 수 있음
  • 부하를 처리하기 위해 보통 애플리케이션이 각 질의마다 작은 수의 레코드만 다룸
  • 애플리케이션은 키의 일부만 사용하는 레코드를 요청하고 저장소 엔진은 요청한 키의 데이터를 찾기 위해 색인을 사용함
  • 대개 디스크 탐색이 병목 포인트임

• OLAP

  • 데이터 웨어하우스와 유사한 분석 시스템
  • 최종 사용자가 아닌 비지느스 분석가가 주로 사용함
  • OLTP 시스템보다 훨씬 적은 수의 질의를 다루지만, 각 질의는 대개 다루기 어렵고 짧은 시간에 수백만 개의 레코드를 스캔 해야함
  • 디스크 대역폭, 디스크 탐색이 아닌 부분이 병목 포인트
  • 컬럼 지향 저장소는 이런 종류의 작업부하를 처리할 때 사용 가능한 솔루션

• OLTP 측면에서 두가지 주요한 관점
  1. 로그 구조화 관점에서 파일에 추가와 오래된 파일의 삭제만 허용하고, 한번 쓰여진 파일은 절대 갱신하지 않음

     • 비트캐스크, SS테이블, LSM트리, 레벨DB, 카산드라, HBase, 루씬 등이 속함

  2. 제자리 갱신 관점에서 덮어쓰기 할 수 있는 고정 크기 페이지의 셋으로 디스크를 다룸

     • B트리로, 모든 주요 관계형 데이터베이스와 많은 비정형 데이터베이스서 사용함

• 로그 구조화 저장소의 핵심 아이디어는 ‘임의 접근 쓰기를 체계적으로 디스크에 순차 쓰기로 바꾼 것’

  • 그 결과, 하드/SSD의 성능 특성에 맞춰 쓰기 처리량을 높이는 것이 가능해짐

• 데이터 웨어하우스의 고수준 아키텍처로 저장소 엔진의 내부 설명

  • 왜 분석 작업부하가 OLTP와 많이 다른지 설명함
  • 질의가 디스크에서 읽는 데이터 양을 최소화하기 위해 데이터를 작게 부호화하는 것이 중요해졌음
  • 칼럼 지향 저장소가 이 목표를 달성하는데 도움을 줌

트랙잭션 처리(OLTP)나 분석(OLAP)?

• 트랙잭션이란 단어를 사용하는 이유

  • 초창기 비즈니스 데이터 처리는 데이터베이스 쓰기가 보통 판패,공급 업체에 발주, 직원 급여 지불등과 같은 커머설 트랙잭션(commercial transaction)에 해당되었음
  • 금전 거래가 아닌 영역으로 데이터베이스가 확장됐어도 트랙잭션 용어는 변하지 않고 논리 단위 행태로서 읽기와 쓰기 그룹을 나타냄’

• 트랙잭션의 ACID

  • 트랙잭션이 반드시 ACID(원자성(atomicity),일관성(consistency),격리성(isolation),지속성(durability)) 속성을 가질 필요없음
  • 클라이언트가 지연시간이 낮은 읽기와 쓰기를 가능하게 한다는 의미임

온라인 트랜잭션 처리(online transaction processing, OLTP)

• 보통 애플리케이션은 색인을 사용해 일부 키에 대한 적은 수의 레코드를 찾음

온라인 분석 처리(online analytic processing, OLAP)

• 분석은 트랜잭션과 접근 패턴이 다름
• 분석은 원시 데이터를 반환하는 것이 아닌 많은 수의 레코드를 스캔해 집계 같은 통계 계산하는 경우가 많음
• 이런 데이터베이스 사용 패턴을 트랙잭션 처리와 구별하기 위해 OLAP로 부름

데이터 웨어하우징 (Data Warehousing)

• 분석가들이 OLTP 작업에 영향을 주지 않고 마음껏 질의할 수 있는 개별 데이터베이스
• 다양한 OLTP 시스템에 있는 데이터의 읽기 전용 복사본
• OLTP 데이터베이스에서 주기적인 데이터 덤프나 지속적인 갱신 스트림을 사용해 데이터 웨어하우스에 적재함

  • 이 작업을 ETL(Extract - Transformation - Load)라고 함

• 개별 데이터웨어하우스는 ‘분석 접근 패턴’에 맞게 최적화할 수 있는 장점이 있음
• 그러면 왜 OTLP 작업에 영향을 주지않게 데이터 웨어하우징을 할까

  • OTLP 시스템은 사업 운영에 매우 중요해, 일반적으로 높은 가용성과 낮은 지연시간의 트랜잭션 처리를 함
  • 그래서 비즈니스 분석가가 OLTP 시스템에 ad hoc analytic query하는 것을 꺼려하고, 분석 질의가 데이터셋의 많은 부분을 스캔하면서
  • 동시에 실행되는 트랜잭션 성능을 저하시킬 수 도 있기 때문

• OTLP 데이터베이스와 데이터 웨어하우스 둘다 SQL 질의 인터페이스를 지원함
• 하지만, 각각 매우 다른 질의 패턴에 맞게 최적화됐기 때문에 시스템 내부는 다르고
• 대다수의 데이터베이스 벤더는 트랜잭션 처리와 분석 작업부하 양쪽 모두 지원하기보다는 둘 중 하나를 지원하는데 중점을 둠

컬럼 지향 저장소

• OLTP 데이터베이스

  • 로우 지향 방식을 데이터를 배치
  • 테이블에서 한 로우의 모든 값은 서로 인접하게 저장됌

• 컬럼 지향 저장소

  • 모든 값을 하나의 로우에 함께 저장하지 않는 대신 각 칼럼별로 모든 값을 함께 저장
  • 각 칼럼을 개별 파일에 저장하면 질의에 사용되는 칼럼만 읽고 분석할 수 있음 -> 작업량이 줄어듬

• 칼럼 압축

  • 질의에 필요한 칼럼을 디스크에서 읽거 적재하는 작업 외에도 데이터를 압축하면 디스크 처리량을 더 줄일 수 있음
  • 칼럼 지향 데이터베이스는 압축에 적합함
  • 칼럼의 데이터에 따라 압축 기법을 사용할 수 있지만, 데이터 웨어하우스에서는 비트맵 부호화 (bitmap encoding)이 효과적
  • 보통 고유한 컬럼의 수는 고유한 로우 수보다 적기 때문에 비트맵으로 색인하는 방법이 좋음
  • 칼럼값의 고유값으로 0,1로 변환하고, 0값이 많은 sparse한 상황에서는 run-length encoding으로 효율을 높일 수 있음

• 컬럼 지향 저장소에 쓰기

  • B트리 사용과 같은 제자리 갱신(update-in-place) 접근 방식은 압축된 컬럼에서는 불가능함

    • 정렬된 테이블의 중간에 로우를 삽임하려면 모든 칼럼 파일을 재작성해야하고
    • 로우는 칼럼 안의 위치에 따라 식별되므로 모든 칼럼을 일관되게 갱신되어야함

  • 그래서 B트리 말고, LSM 트리로 해결할 수 있음

    • 모든 쓰기는 먼저 인메모리에 저장소에 이동해 정렬된 구조에 추가하고 디스크에 쓸 준비를 함
    • 충분한 쓰기가 모으면 디스크의 컬럼 파일에 병합하고 대량으로 새로운 파일에 기록