데이터 중심 애플리케이션 설계, 마틴 클레프만 지음. OREILLY.

데이터베이스의 역할 2가지

1. 데이터를 받아서 저장하기 2. 요청 받은 데이터를 제공하기

책의 2장, 3장에서는 데이터베이스의 역할을 다룬다. 각 장에서 위의 역할을 하나씩 다루지는 않고, 서로 다른 관점에서 2가지 역할을 모두 다룬다. 2장에서는 애플리케이션 개발자 입장에서, 3장에서는 데이터베이스 입장에서 적었다.

2장: 데이터 모델과 질의 언어

프로그램 전체에 영향을 미치는 데이터 모델

데이터 모델에는 여러 종류가 있다. 오래전부터 이어져 내려와 아직도 많이 쓰이는 관계형 모델이 가장 대표적이다. 관계형 모델의 한계를 깨고자 나온 모델로는 문서 모델, 그래프 모델 등이 있다. 관계형 모델을 관리하기 위해 고안된 언어가 SQL인데, 문서 모델이나 그래프 모델은 SQL만을 사용하지 않는다는 의미로 NoSQL(Not only SQL) 데이터베이스라고도 부른다. 가장 대표적으로는 몽고DB가 있다.

데이터 모델을 결정하는 일은 중요한 일이다. 물론 프로그래밍 세계에서 안 중요한게 있겠냐마는, 데이터 모델을 정하는건 특히 더 그렇다. 주어진 문제를 어떻게 생각해야 하는지에 영향을 미치기 때문이다. MySQL에서 회원 정보, 구매 내역, 포인트 등을 저장하고 받아오는 방식과 NoSQL에서 저장하고 받아오는 방식에는 큰 차이가 있다.

데이터베이스 질의 언어

질의 언어(query language)는 크게 2가지로 구분할 수 있다.

1. 명령형(imperative) 언어 2. 선언형(declarative) 언어

명령형 언어는 절차적 언어라고도 부른다. 데이터베이스에게 쿼리를 날릴 때 원하는 데이터에 접근하기 위해 어떻게 동작해야 하는지를 알려준다. 반면 선언형 언어는 무엇을 찾아야 하는지를 알려준다. 즉, 명령형 언어는 how를, 선언형 언어는 what을 던지는 언어다.

SQL은 대표적인 선언형 질의 언어다. 프로그래머가 SELECT, JOIN, WHERE문을 쓸 때 실제로 데이터베이스가 어떤 순서로 어떤 테이블을 보고 어떻게 데이터를 가져오는지는 신경쓰지 않는다. 단지 '여기서 이런 조건에 맞는 데이터를 가져와줘. 어떻게 할지는 니가 알아서 하렴^-^' 하고 what을 던져줄 뿐이다. 어떤 명령부터 실행할지는 데이터베이스의 내부 엔진이 결정한다.

NoSQL 데이터베이스가 관계형 데이터베이스를 완전히 대체할 수 있을까

대답은 '아니오'다. 적어도 아직까지는 그렇다. 각 데이터 모델마다 장단점이 있기 때문이다. 책에서 보여준 예시에 따르면, 데이터 모델끼리 서로 흉내는 낼 수 있어도 굉장히 비효율적이고 오히려 안 하느니만 못하게 된다. 예를 들어 관계형 모델이 문서 모델을 억지로 따라할 수는 있지만 쿼리문이 굉장히 길어지게 된다.

이외 여러가지 데이터베이스 분야

테라바이트 단위의 데이터를 다루기 위해 고안된 게놈 데이터베이스, 정확한 데이터가 아닌 비슷한 데이터(예: 유사어도 검색 쿼리에 포함시키기)를 찾는 full-text search 알고리즘 등이 활발히 연구 중에 있다.

3장: 저장소와 검색

3장에서는 2장과 다르게 데이터베이스 입장, 즉 DB 내부 이야기를 다룬다.

Index 색인

색인은 데이터베이스에서 특정 키의 값을 효율적으로 찾을 수 있게 도와주는 데이터 구조다. 그러니까 DB에 원래 저장하려던 데이터를 저장하는 공간이 있고, 이와 별도로 색인이 있다. 원래 저장하려던 데이터는 primary data라고 표현한다. 이 데이터가 너무 크기 때문에 색인이라는 별도 구조를 만들어서 검색 속도를 높이는 것이다. 색인은 여러가지 기준으로 분류할 수 있다.

구조에 따른 분류

해시 색인과 세그먼트, SS 테이블과 LSM트리, B트리를 각각 책에서 다루고 있다.

색인에 저장하는 값에 따른 분류

Clustered index 클러스터드 색인

key, data를 쌍으로 저장한다. 관계형 데이터베이스를 예로 들자면 key와 함께 테이블의 row 하나에 적힌 원본 데이터를 함께 저장한다.

Non-clustered index 비클러스터드 색인

key, row data에 대한 reference를 저장한다. 같은 예시를 들자면 key와 함께, 테이블의 row 하나를 가리키는 포인터를 함께 저장한다.

Covering index 커버링 색인

'포괄열이 있는 색인 (index with included column)'이라고도 한다. key와 함께, 테이블의 컬럼 중 몇개를 함께 저장한다.

키의 구성에 따른 분류

단일 컬럼 색인과 다중 컬럼 색인이 있다. 다중 컬럼 색인에는 다차원 색인, 결합 색인 등 여러 종류가 있다.

정확도에 따른 분류

정확한 값이 아닌 비슷한 값을 대상으로 하는 fuzzy 색인이 있고 일반적인 색인이 있다.

색인이 무조건 좋지만은 않다: Trade-off

색인의 목적은 검색 속도 향상이다. 여기에만 초점을 맞춘다. 그러다보니 trade-off가 생긴다. 저장소 시스템에서의 trade-off는 색인과 쓰기 속도 사이에 생긴다. 검색을 빠르게 해주려면 새로운 데이터가 들어오거나 기존 데이터를 수정, 삭제했을 때 색인의 구조를 바꿔야 한다. 즉, 색인을 사용하면 쓰지 않을 때보다 데이터에 변동 사항을 기록할 때 시간이 더 걸린다. 색인이 없으면 색인의 구조를 바꿔줄 필요도 없으니까!

그래서 데이터베이스에서 모든 컬럼을 색인으로 만들지 않는다. 자기 마음대로 하지 않고, 개발자 마음대로 하도록 선택권을 준다. MySQL 명령어 중에서도 특정 테이블의 특정 컬럼에 대한 인덱스를 만들도록 설정하는게 따로 있다.

인메모리 DB

디스크와 메모리 접근 속도는 상당하다. 인메모리 DB는 전통적인 데이터베이스와 반대로, 디스크에 로그를 저장하고 메모리에 실제 데이터를 저장한다. 책에서 인메모리 DB의 장단점과 예시를 설명하고 있다.

OLTP / OLAP

OLTP (OnLine Transaction Processing, 트랜잭션 처리 시스템)는 전통적인 데이터베이스 사용 프로세스다. 데이터 자체를 관리하는 것에 중점을 맞춘다. 데이터베이스가 데이터에 중점을 맞추는게 당연할텐데, 이렇게 생색내듯 말하는 이유는 OLAP가 있기 때문이다.

OLAP (OnLine Analytical Processing, 분석 시스템)은 데이터 자체가 아닌 데이터로부터 인사이트를 얻어내는 데에 집중한다. 데이터 통계, 분석에 용이한 구조로 데이터를 저장하는 방법도 있다. 대용량 데이터를 저장하는 데이터 웨어하우스에서는 분석 전용 스키마를 사용한다. star schema, snowflake schema 등이 있다. 또한 bitmap encoding처럼 대규모 정보를 압축하는 칼럼 압축 기술도 점점 발전하고 있다.