OLTP와 OLAP

OLTP(OnLine Transaction Processing)

목적

• 일상적인 비즈니스 운영을 위한 트랜잭션 처리에 사용
  • 프로덕션 데이터베이스: MySQL, PostgreSQL, Oracle 등

특징

• 실시간으로 많은 수의 짧고 간단한 트랜잭션을 처리
  • 따라서 실시간성을 가지고, 빠른 응답속도가 중요함
• 데이터가 지속적으로 업데이트됨
  • INSERT, DELETE, UPDATE
• 정규화된 데이터 모델을 사용하여 데이터 중복을 최소화함
  • 세부 내용은 게시글 참조: 정규화
• 사용 경험상 테이블 간 참조 조건, 기본키의 고유성과 같은 제약조건 검사 등의 기능을 자동으로 수행해줌
• 주로 행기반 데이터베이스를 사용함

참고: 행기반 데이터베이스

• 데이터를 행 단위로 저장하는 데이터베이스
• 레코드 단위의 읽기/쓰기에 최적화되어 있음
• 레코드를 한 번에 읽어오는데 효율적
• 압축 효율성이 열기반 데이터베이스보다 낮음
  • 이는 행단위 데이터의 카디널리티가 열단위 데이터보다 높기 때문
    • 카디널리티: 데이터 집합에서의 유니크한 값의 갯수
• 레코드에 대한 인덱스를 통해 검색 속도를 향상시킴
  • 주로 B-Tree 인덱스를 사용
    • 높은 카디널리티에 유리
    • 잦은 데이터 변경에 유리
    • 상대적으로 많은 저장 공간을 사용

OLAP(OnLine Analytical Processing)

목적

• 복잡한 데이터 분석, 의사결정 지원, 데이터 과학에 사용
  • 데이터웨어하우스: BigQuery, Redshift, Snowflake 등

특징

• 조직 전체의 데이터를 가지고 있는 경우가 많음
  • OLTP는 OLAP 데이터의 출처 중 일부가 될 수 있음
  • 때문에 OLTP보다 더 큰 규모의 데이터를 가지고 있음
  • 따라서 실시간성보다는 배치성 작업이 메인이며, 빠른 응답속도보다 대용량 데이터를 얼마나 많이 이상없이 처리할 수 있는지가 중요
• 대량의 데이터를 대상으로 복잡한 쿼리를 실행하여 다차원 분석을 수행
• 주로 읽기 전용 작업이 수행되며, 데이터는 주기적으로 대량으로 로드됨
• 비정규화된 다차원 데이터 모델을 사용하여 분석 성능을 최적화
  • 이는 대용량 데이터가 직면하는 큰 문제인 조인을 통한 셔플링을 줄여줌
  • 세부 내용은 게시글 참조: 다차원 데이터 모델
• 사용 경험상 테이블 제약 조건을 명시할 수는 있지만, 검사를 수행하지는 않음
  • 이는 대용량 데이터들에 대해 전부 제약조건을 검사하기에는 오버헤드가 너무 크기때문
  • 따라서 제약 조건들은 개발자(데이터 엔지니어)가 잘 따르는지 확인해주는 작업이 필요
• 주로 열기반 데이터베이스를 사용함

참고: 열기반 데이터베이스

• 데이터를 열 단위로 저장하는 데이터베이스
• 대용량 데이터의 분석 및 집계 연산에 유리함
• 특정 열의 데이터만 선택적으로 읽어올 수 있어 I/O를 줄일 수 있음
• 같은 데이터 타입이 연속적으로 저장되어 압축 효율성이 행기반보다 뛰어남
• 래코드의 삽입, 수정, 삭제 작업이 상대적으로 느림
• 컬럼 자체가 인덱스 역할을 하므로 별도의 인덱스가 덜 필요함
  • Bitmap 인덱스를 사용함
    • 낮은 카디널리티에 유리
    • 데이터 변경이 적은 황경에 유리
    • B-Tree 인덱스보다 더 적은 저장 공간을 사용