SQL/NoSQL로는 부족하다? 특수 목적 DB의 세계로!
SQL과 NoSQL은 데이터 관리의 핵심이었지만, 현대적 워크로드(Workload)에는 한계가 있음
수평적 확장성(Horizontal Scalability), 유연한 스키마(Schema)를 위해 NoSQL이 등장했지만, 여전히 일반적인 목적을 가짐
시계열(Time-Series), 벡터(Vector) 등 특수 목적 데이터베이스는 특정 문제 해결에 특화되어 성능을 극대화함
데이터 유형의 다양성(Diversity of Data Types)으로 인해 특수 목적 데이터베이스의 필요성이 증가함
SQL 데이터베이스의 한계
SQL 데이터베이스는 지난 수십 년간 데이터 관리의 중추였지만, 수평적 확장(Horizontal Scaling)에 어려움을 겪는다. 전통적인 RDBMS는 수직적 확장(Vertical Scaling)에 최적화되어 있으며, 스키마 변경(Schema Migration) 또한 대규모 데이터셋(Dataset)에서는 부담으로 작용한다. 특히, 로그(Logs)나 IoT 메트릭(Metrics)과 같이 높은 인제션(Ingestion) 워크로드(Workload)에서는 병목 현상이 발생할 수 있다.
NoSQL 데이터베이스의 등장 배경
NoSQL 데이터베이스는 수평적 확장성(Horizontal Scalability), 유연한 스키마(Flexible Schema)를 제공하며, 대규모 웹 애플리케이션(Web Application)에서 높은 쓰기 처리량(Write Throughput)을 지원하기 위해 등장했다. 하지만, 일반적인 쿼리 성능(General-purpose Query Power)의 한계, 결과적 일관성(Eventual Consistency) 문제, 특정 도메인(Domain)에 국한된 최적화(Narrow Optimization) 등의 단점을 가진다. 이러한 트레이드오프(Trade-offs)는 CAP 정리에 의해 설명된다.
특수 목적 데이터베이스의 필요성
SQL과 NoSQL 데이터베이스는 현대적인 워크로드(Workload)의 모든 요구 사항을 충족시키지 못한다. 시계열 데이터(Time-Series Data), 고차원 벡터(High-Dimensional Vector) 검색, 대규모 분석 쿼리(Analytical Queries) 등 특정 분야에서는 특수 목적 데이터베이스가 더 나은 성능을 제공한다. 이러한 데이터베이스는 각자의 문제 도메인(Problem Domain)에 맞춰 저장 형식(Storage Formats), 인덱싱 전략(Indexing Strategies), 쿼리 실행 알고리즘(Query Execution Algorithms)을 사용한다.
데이터베이스 동물원(Database Zoo) 시리즈의 목표
게시물은 특수 목적 데이터베이스(Specialized Databases)의 내부 구조, 트레이드오프(Trade-offs), 실제 사용 사례를 탐구한다. 시리즈는 시계열 데이터베이스(Time-Series Databases)를 시작으로, 벡터 데이터베이스(Vector Databases), 확률적 데이터베이스(Probabilistic Databases) 등 다양한 엔진을 다룰 예정이다. 궁극적으로, 독자들은 이러한 엔진의 존재 이유, 작동 방식, 그리고 시스템에 적합한 시점을 파악할 수 있을 것이다.
