데이터 중심 어플리케이션 설계 - 저장소와 검색

데이터저장소

• db_set(): 간단한 추가작업 O(1)
• db_get(): 추가되는 데이터 만큼 순회를 하며 데이터 조회를 해야함 O(n)
• db_set()과 마찬가지로 많은 데이터베이스는 내부적으로 추가 전용 데이터 파일인 로그를 사용한다.

#!/bin/bash

db_set() {
    echo "$1,$2" >> database # database 파일에 append하는 방식
}

db_get() {
    grep "^$1, " database | sed -e "s/^$1,//" | tail -n 1 # database 파일의 맨 마지막 row
}

db_set 42 '["{'name':'testerB','attractions':['explor']}", "{'name':'testerA','attractions':['explor']}"]'
db_set 202 '["{'name':'testerc','attractions':['explor']}"]'

db_get 42

색인

1. BTree 기반
2. LSM Tree 기반

기본데이터에서 파생되는 메타데이터

• 검색속도: O(logN)
• 장점: 색인을 통해 검색을 효율인 검색속도를 낼 수 있다.
• 단점: 색인을 사용시 쓰기 속도가 느리다. 데이터를 삽입할 때마다 색인 테이블도 갱신을 해야한다.

해시 색인

색인에서의 키를 데이터 파일의 바이트 오프셋에 매핑하여 인메모리 해시 맵(=멤테이블)을 유지하는 전략

• 각 키의 값이 자주 갱신되는 상황에 매우 적합

// 디스크상의 로그 구조화 파일이라 가정 (각글자는 1바이트)
123456,{"name":"London","attractions":["Big Ben","London Eye"]}\n
42,{"name":"San Francisco","attractions":["Golden Gate Bridge"]}\n

자릿수를 세어보면 0 ~ 63까지 하나의 row를 의미(\n포함)하고 64부터 나머지 row를 의미함

키	바이트오프셋
123456	0
42	64

SSTable (Sorted String Table)과 LSM 트리 등장

• 키-값 쌍의 연속
• 키를 기준으로 정렬된 형식

멤테이블의 buffer가 가득차 한계에 도달할 경우 해당 테이블을 파일로 flush한다.

쓰기에 최적화 되어있다.

이유는 인메모리에 허용하는 버퍼까지 갖고 있다가 해당 내용을 flush하는 방식으로 한 번에 처리(=일괄처리)하기 때문이다.

컴팩션

SSTable의 데이터 중 중복된 키를 버리고 각 키의 최신 값만 유지하는 것

B 트리

• 디스크 기반의 인덱스 구조
• 페이지 지향 구조

읽기에 최적화 되어있다.

이유는 트리기반이기 때문에 찾는 속도가 항상 O(logN)이다.

OLTP (Online Transaction Processing)

• 사용자의 입력을 기반으로 데이터가 삽입, 갱신된다.

OLAP

• 데이터 분석, 집계, 통계

결론

빅데이터로 발전하는 요즘의 시대에 맞춰 쓰기 처리율이 높아야한다면 LSM 트리를 인덱스로 기반한 데이터 저장소를 고르는 것이 현명한 선택일 것이다.

저장소의 예시로는

1. 아파치 카산드라
2. RocksDB
3. 아파치 하둡

등이 있다.