데이터 모델과 질의 언어

내 언어의 한계는 내 세계의 한계를 의미한다.

- 루트비히 비트겐슈타인, 논리-철학 논고(1922)

 

요즘 개발 커뮤니티에서 "요즘 어플리케이션들이 AI Wrapper 다"라는 이야기를 심심치 않게 들을 수 있다. 이곳 저곳에 생성형 AI 관련 기능을 넣으면서 나온 이야기인듯 한데.. 결국 기존 어플리케이션도 Database Wrapper가 아니냐는 이야기로 귀결된다.

 

그만큼 현재 데이터 베이스 모델들은 각종 ORM 혹은 데이터 베이스 콘솔이나 CLI 등으로 잘 추상화가 되어 있어서 개발자들은 이들을 사용하는데 불편함을 느끼지 못한다. 데이터 모델은 다양한 유형을 갖고 있고, 각 유형마다 어떤 연산은 빠르게 어떤 연산은 매우 느리게 동작하기도 한다.

이 장에서는 다양한 데이터 모델 및 그들의 질의 언어 ( Query Language )를 비교해본다. 

 

 

관계형 모델과 문서 모델

 

오늘날 가장 잘 알려진 데이터 모델은 SQL 이다. 1970년대와 80년대부터 "트랜잭션 처리"와 "일괄 처리"에 이점을 갖고 약 25년 ~ 30년 정도 타 데이터 모델 대비 우위를 점했다. 2024년 7월 현재를 기준으로 봐도, 관계형 데이터 모델의 우위는 진행형인듯 하다. 

 

데이터베이스 순위 ( 출처: https://db-engines.com/en/ranking )

 

하드웨어의 발전에 따라 관계형 데이터베이스가 비즈니스 데이터 처리라는 본래의 영역을 넘어 폭넓은 다양한 사례에도 보편화되고 있다. 가령, 오늘날 온라인 게시물, 토론, 소셜 네트워크, 전자 상거래, 게임, SaaS 등은 관계형 데이터 베이스 모델을 통해 제공되곤 한다. 

 

NoSQL의 탄생

 

2010년대에 NoSQL은 관계형 모델의 우위를 뒤짚으려는 가장 최신 시도로 나타난다. "NoSQL"이라는 용어는 어떤 특정 기술을 참고한 것은 아니라서 적절하지는 않다. ( 기원은 트위터 내 인기 해시태그였다고 한다 ) 그래서 No SQL 로 보기보다는 Not Only SQL로 재해석되기도 한다.

 

NoSQL을 재택하는 데는 아래와 같은 원동력이 작용한다. 

 

- 대규모 데이터셋 또는 매우 높은 쓰기 처리량 달성을 관계형 데이터베이스보다 쉽게 할 수 있는 뛰어난 확장성 니즈

- 상용 데이터베이스 제품보다 무료 오픈소스 소프트웨어에 대한 선호도 확산

- 관계형 스키마의 제한에 대한 불만과 더욱 동적이고 표현력이 풍부한 데이터 모델에 대한 바람

 

결국 기술에는 Silver bullet이 없다는 전통대로 각자의 장단점을 지니게 된 셈인데. 저자는 애플리케이션의 복잡성이 늘어남에 따라 하나의 기술을 맹신하고 의존하기보다는 가까운 미래에 관계형 데이터베이스가 비관계형 데이터스토어와 함께 사용될 것이라고 말한다. ( 이미 실제로 많은 서비스들이 문서 기반의 Redis와 관계형 데이터 베이스 MySQL 또는 Postgre를 함께 사용 중이다 ) 이런 개념을 종종 다중 저장소 지속성 ( Polyglot persistence )라고 한다.

 

객체 관계형 불일치

 

오늘날 대부분의 애플리케이션은 객체지향 프로그래밍 언어로 개발한다. 이것은 SQL 모델을 사용할 때, 공통된 불편함을 야기한다. 데이터를 관계형 테이블에 저장하려면 애플리케이션 코드와 데이터 베이스 모델 객체 사이에 거추장스러운 전환 계층이 필요하다. 이런 모델 사이의 분리를 임피던스 불일치 ( Impedance mismatch ) 라고 한다. 

 

한 가지 예시로, 전통적인 방식의 SQL 사용으로 링크드인 프로필 저장 기능을 구현하는 것을 살펴보자. 

 

관계형 데이터베이스를 사용한 링크드인 프로필 구현

 

위 그림에 나와있는 것처럼, 정규화를 지키기 위해 직위, 학력, 연락처 등을 개별 테이블에 저장하고 이들의 외래 키로 users 테이블을 참조하였다. 

 

이 경우 두 가지의 불편한 점이 있다. 

 

1) 추상화된 API 요청을 서비스 내부 로직에서 데이터 모델에 맞게 맵핑해주는 역할 계층이 필요하다.

2) 유저 조회 시, 다중 JOIN 을 걸어야만 한다. 

 

결국 유저의 프로필을 저장하기 위해 매우 긴 서비스 코드가 양상될 여지가 있다. 이런 경우 JSON 모델로 저장하는 것이 용이한 측면이 있다. 

 

1:N 과 N:N 처리

위 예시를 살펴보면 JSON 형식의 문서 데이터 모델이 좋아보이지만, 문제가 하나 있다. 바로 정합성이 엄격히 지켜지기 어렵다는 점이다. 

 

가령, user 테이블에 JSON 형태로 school을 저장한다고 하면, 학교 객체의 배열 형태로 데이터가 저장될 것이다. 우선 이는 단순한 키 값 저장보다는 데이터 용량을 더 많이 차지하기도 하고, 누군가 빌게이츠의 school 정보에서 Harvard University 학교 객체 내 start와 end를 바꾼다고 하더라도 NoSQL 데이터 베이스 시스템이 이를 제한하지 않는다. 

 

물론 관계형 데이터베이스를 흉내내어 school 테이블을 따로 두고 참조를 걸어 처리할 수 있다. 그치만 이 시점에서 맵핑 테이블을 필요로 한다는 점에서 NoSQL 의 장점을 잃게 된다. 결국 이 참조도 SQL처럼 데이터 모델 자체가 엄격히 관리하는 것이 아니기에, 참조 값을 조작하는 것을 막기 어렵다는 한계도 있다.

 

관계형 데이터베이스와 오늘날의 문서 데이터베이스

관계형 데이터베이스와 문서 데이터베이스를 비교하는 경우, 내결함성과 동시성 처리를 포함해 고려해야할 차이점이 많다. 하지만 이 장에서 다루는 "데이터 모델의 차이점"에만 집중해보면, 아래와 같이 정리된다. 

 

- 문서 데이터 모델 선호 이유: 스키마 유연성, 지역성에 기인한 더 나은 성능 / 일부 애플리케이션의 경우, 애플리케이션에서 사용하는 데이터 구조와의 근접함 

- 관계형 모델 선호 이유: 조인, 다대일, 다대다 관계를 더 잘 지원함으로서 문서 데이터 모델에 대항