데이터 모델과 질의 언어

데이터 모델은 코드를 어떻게 짜느냐뿐 아니라, 문제를 어떻게 생각하느냐까지 결정해. 렌즈를 바꾸면 세상이 달라 보이듯이, 관계형이냐 문서형이냐 그래프형이냐에 따라 같은 데이터도 완전히 다르게 보이거든.

1970년에 에드거 코드가 제안한 관계형 모델이 거의 모든 곳을 지배했는데, 2010년대에 NoSQL이 도전장을 내밀었지. 확장성, 유연한 스키마, 특수한 질의 연산 — 동기는 다양한데, 결국 관계형과 비관계형을 함께 쓰는 다중 저장소 지속성(polyglot persistence) 이 대세가 될 거야. 실제로 양쪽이 점점 닮아가고 있어 — PostgreSQL이 JSON을 지원하고, MongoDB가 조인을 추가하는 식으로.

핵심은 데이터의 관계 구조야. 이력서처럼 자기 포함적이고 문서 간 관계가 적은 데이터는 문서 모델이 딱이야. 전체가 하나의 문서로 떨어지니까 조인이 필요 없고 지역성(locality) 도 좋지. 하지만 다대다(many-to-many) 관계가 많아지면 문서 모델은 불편해져 — 조인 지원이 약하니까 애플리케이션 코드에서 흉내 내야 하고, 데이터가 상호 연결될수록 관계형이, 더 나아가면 그래프 모델이 자연스러워지지. 그래프의 강력한 점은 사람, 장소, 이벤트 같은 이종 데이터도 한 그래프 안에서 자연스럽게 연결할 수 있다는 거야.

질의 언어 선택도 중요해. SQL은 선언형 — 원하는 결과의 조건만 말하면 DB가 알아서 최적화하지. CSS로 "배경색 파란색" 하면 끝인데 JS로 하면 요소를 일일이 순회해야 하는 것과 같은 차이야. 선언형이 더 간결하고, DB 내부를 바꿔도 질의를 안 고쳐도 되고, 병렬화에도 유리해. 그래프 데이터를 사이퍼로 질의하면 간선을 따라가는 게 자연스러운데, 같은 걸 SQL로 짜면 조인이 잔뜩 필요해서 복잡해진다는 걸 보면, 데이터 구조에 맞는 모델과 질의 언어를 고르는 게 얼마나 중요한지 알 수 있어.

---

정리

2장 읽고 기억할 거:

1. 데이터 모델은 사고방식을 결정한다. 관계형, 문서형, 그래프형 — 데이터의 관계 구조에 따라 적합한 모델이 달라진다
2. 관계형과 문서형은 수렴하고 있다. 하지만 다대다 관계가 많으면 문서 모델은 여전히 불편하다
3. 선언형 질의가 명령형보다 낫다. 뭘 원하는지만 말하는 게 더 간결하고, 최적화 여지도 크고, 병렬화도 쉽다