데이터 중심 애플리케이션 설계 3장 정리

 

데이터베이스

• 데이터를 저장
• 나중에 데이터를 요청하면 다시 데이터를 제공

 

로그

• 연속된 추가 전용 레코드

 

색인

데이터베이스에서 특정 키의 값을 효율적으로 찾기 위해서는 데이터베이스 파일을 처음부터 끝까지 스캔하는 것 외에, 색인이 필요

• 색인은 질의 성능에 영향을 줌. 어떤 종류의 색인이라도 대개 쓰기 속도를 느리게 만들음. 
• 그래서 애플리케이션 개발자나 데이터베이스 관리자가 애플리케이션의 질의 패턴을 활용해 수동적으로 색인을 선택 
  • 필요 이상으로 오버헤드를 발생시키지 않으면서 애플리케이션에 가장 큰 이익을 안겨주는 색인을 선택할 수 있음

키-값 저장소는 해시 맵(해시 테이블)로 구현

 

Sorted String Table(SS Table)

• 키-값 쌍을 키로 정렬한 형식
• 병합 정렬 알고리즘에서 사용하는 방식과 유사한 세그먼트 병합 방식 사용

 

Log-Structured Merge-Tree (LSM Tree)

• 정렬된 파일 병합과 컴팩션* 원리를 기반으로 하는 저장소 엔진
  • 컴팩션 : 로그에서 중복된 키를 버리고 각 키의 최신 갱신 값만 유지하는 것
• 데이터베이스에 존재하지 않는 키를 찾는 경우 느릴 수 있음
  • 키가 데이터베이스에 존재하지 않음을 알려주는 Bloom filter를 추가적으로 사용해 불필요한 디스크 읽기를 절약 

 

로그 구조 계열 저장소 엔진(B-트리)

• 가장 널리 사용되는 색인 구조로, 대부분의 관계형 데이터베이스에서 표준 색인 구현으로 B-트리를 사용
• 4KB나 그 이상의 고정 크기 블록이나 페이지로 나누고 한 번에 하나의 페이지에 읽기 또는 쓰기를 함
• 디스크가 고정 크기 블록으로 배열됨
• 기본적으로 새로운 데이터를 디스크 상의 페이지에 덮어쓰는데, 페이지를 가리키는 모든 참조는 온전하게 남음

 

LSM 트리	B-트리
쓰기에서 더 빠름, 쓰기 처리량 높게 유지	읽기에서 더 빠름
압축률이 더 좋음 - 디스크에 더 적은 파일 생성	파편화로 인해 사용하지 않는 디스크 공간 일부가 남음
컴팩션 연산이 끝날 때까지 읽기/쓰기 요청이 대기해야 하는 상황 발생	예측하기 쉬운 성능
다른 세그먼트에 같은 키의 다중 복사본이 존재할 수 있음	각 키가 색인의 한 곳에만 정확하게 존재

 

위에서 설명한 데이터 구조는 디스크 한계에 대한 해결책이었는데, 
디스크는 전원이 꺼져도 손실되지 않아 지속성에서의 장점이 있고, 램보다 기가바이트 가격이 더 저렴함.

하지만 램이 점점 저렴해지면서 메모리에 전체를 보관하는 방식 / 여러 장비간 분산해서 보관할 수 있어졌고, 
이러한 이유로 인메모리 데이터베이스가 개발됨.

• 맴캐시드 : 장비가 재시작되면 데이터 손실을 허용하는 캐시 용도로만 사용됨
• 다른 인메모리 데이터베이스는 지속성을 목표로 함
  • 배터리 전원 공급 RAM과 같은 특수 하드웨어를 사용
  • 디스크에 변경 사항의 로그 기록
  • 디스크에 추가적인 스냅숏을 기록하거나
  • 다른 장비에 인메모리 상태를 복제함

 

---

갤럭시탭으로 pdf 파일 읽는 문서 뷰어도 페이지나 목차 색인이 안 되어서 불편했는데...

그래도 책갈피 한 곳만 모아 보여주는 부분이 색인과 비슷해 보였다. 무튼 이렇게 페이지를 이동하니 좀 숨통이 트일 것 같았다!

색인의 장점이라고 해야 할지.. ㅎㅎ