Introduction

데이터베이스 선정 시 고려할 사항
- 사용하고자하는 쿼리를 지원하는가
- 저장하고자하는 데이터의 양을 DB가 감당할 수 있는가
- 단일 DB node에서 처리할 수 있는 읽기/쓰기 처리량
- 시스템에서 필요한 DB node의 수
- DB 확장을 어떻게 하는가
- 유지보수 프로세스
YCSB(Yahoo! Cloud Serving Benchmark)
- 시중에 다양한 데이터베이스가 존재
  - 비슷한 유형의 데이터베이스 사이에서 어떤걸 선택해야하는지 ....
YCSB project is to develop a framework and common set of workloads for evaluating the performance of different "key-value" and "cloud" serving stores
구성
- YCSB client: Workload generator
- Core workloads: Generator에 의해 실행될 workload scenario

Chapter 1.

Row oriented
- block 단위로 데이터를 조회
- query에서 조회하고자 하는 데이터가 block 내부에 존재하는 경우 유용
- 특정 컬럼만 조회하는 경우 효율적이지 않음
Column oriented
- 동일 컬럼을 조회하는 쿼리에 유용
- 컬럼별 효율적인 압축 알고리즘을 사용할 수 있다는 장점
- CPU 효율도 상승함(vectorized instruction)

Data file
- Data를 저장
- 구현 방식
- IOT(Index organized table)
  - 데이터를 인덱스와 함께 저장하는 방식
- Heap organized table
  - 쓰기 순서대로 데이터가 저장됨
  - 데이터가 저장된 위치를 가리키는 별도의 자료구조가 필요
- Hash organized table
  - key의 해시값을 기준으로 value가 담길 bucket을 결정
Index file
- secondary kek
- primary key와 함꼐 저장되거나(MySQL)
- heap file/IOT에서 해당되는 데이터의 offset을 가리킬 수 있음(PostgreSQL)
- MySQL과 PostgreSQL의 index 구성 차이

Binary tree(X) -> Balanced tree(? 불분명한 어원)
Disk based 자료구조로 일반 binary tree를 사용한다면
- low fanout, tree height가 높기 때문에 disk 탐색 비용이 큼
- rebalancing이 자주 발생
- 관련성이 높을 수 있는 인접한 노드가 디스크 상에서 멀리 위치할 수 있음 -> 지역성이 떨어짐

HDD
- random read 취약
- sector 단위로 읽기/쓰기
SSD
- memory cell -> string -> array -> page -> block -> plane -> die
- cell: 한개 또는 다수의 bit
- page:
  - 2 ~ 16kb
  - SSD의 최소 쓰기 단위
  - empty memory cell에만 쓰기작업이 필요 -> memory cell이 차있으면 삭제 작업 필요
- block:
  - 64 ~ 512 page
  - 최소 삭제 단위
- HDD에 비해 random read 성능이 덜 나쁘긴 하지만... 여전히 random read는 SSD의 성능에도 악영향
  - prefetching
  - reading contiguous page
  - internal parallelism
OS에서 disk의 읽고 쓰는 작업을 추상화
- block device abstraction
- 디스크에서 작은 데이터를 읽더라도 block 통째로 읽어야 함