데이터베이스 제품을 어떤 질문으로 비교할까¶
모든 제품을 외우지 않고, 현재 시스템에서 가장 비싼 작업이 무엇인지로 후보를 줄입니다.
PostgreSQL, Redis와 ClickHouse는 모두 데이터를 저장하지만 같은 문제를 싸게 해결하도록 만들어지지 않았다. 주문의 여러 변경을 함께 커밋하는 일, 세션 키 하나를 빠르게 찾는 일, 수십억 행에서 매출을 집계하는 일은 필요한 저장 구조가 다르다.
그래서 제품 이름을 비교하기 전에 두 가지를 정한다. 어떤 데이터가 서비스의 원본인지, 그리고 현재 가장 비싼 접근이 무엇인지다. 원본 저장소는 정확성과 복구 책임을 맡고, 검색 인덱스·캐시·분석 저장소는 원본에서 다시 만들 수 있는 파생본으로 두는 경우가 많다.
새 저장소를 추가하면 특정 질의는 빨라질 수 있다. 동시에 데이터 전달 지연, 불일치 복구, 별도 백업과 장애 대응이 생긴다. 현재 관계형 데이터베이스가 목표를 만족한다면 제품을 하나 더 운영하지 않는 것이 가장 값싼 선택일 수 있다.
flowchart TD
A["먼저 지켜야 할 업무 규칙을 적는다"] --> B{"현재 가장 비싼 작업은 무엇인가?"}
B -->|"짧은 트랜잭션·관계 조회"| R["관계형 데이터베이스"]
B -->|"알려진 키의 초저지연 조회"| K["키-값 저장소"]
B -->|"단어 검색·관련도 순위"| S["검색 엔진"]
B -->|"대규모 스캔·집계"| C["열 기반 분석 데이터베이스"]
B -->|"의미가 가까운 항목 검색"| V["벡터 검색 계층"]
R --> O{"원본인가, 다시 만들 수 있는 파생본인가?"}
K --> O
S --> O
C --> O
V --> O
O --> P["전달 지연·재구축·복구 책임을 기록한다"]거래 처리와 분석 처리는 조회 범위가 다르다¶
OLTP(Online Transaction Processing, 온라인 트랜잭션 처리)는 주문 생성이나 잔액 변경처럼 적은 행을 짧은 트랜잭션으로 자주 조회하고 업데이트한다. 동시 요청이 같은 데이터를 바꿀 때 규칙을 지키는 일이 중요하다. PostgreSQL, MySQL과 Oracle이 대표적인 후보가 된다.
OLAP(Online Analytical Processing, 온라인 분석 처리)는 오랜 기간 쌓인 많은 행에서 일부 열을 훑어 집계한다. 행 하나의 업데이트보다 압축, 연속 조회와 병렬 계산이 중요하다. ClickHouse 같은 열 기반 분석 제품이 이 작업을 겨냥한다.
HTAP(Hybrid Transactional/Analytical Processing, 거래·분석 통합 처리)는 최신 거래 데이터에 분석 질의를 빠르게 연결하려는 구조다. 복사 지연을 줄일 수 있지만 거래와 분석이 CPU·메모리·저장 장치 대역폭을 두고 경쟁하지 않도록 격리해야 한다. 두 작업을 한 제품이 지원한다는 사실과 한 장비에서 함께 실행해도 안전하다는 뜻은 다르다.
PostgreSQL은 조회 방식이 계속 달라질 때 강하다¶
PostgreSQL은 관계, 제약 조건과 트랜잭션을 중심에 두면서 JSON, 배열, 지리 정보, 전문 검색과 사용자 정의 확장을 함께 제공한다. 앞으로 어떤 조건과 자료형으로 조회할지 계속 달라질 가능성이 크고, 그 작업을 한 트랜잭션 안에서 처리해야 할 때 후보가 되기 쉽다.
기능이 많다고 자동으로 실행 계획이 좋아지는 것은 아니다. 통계와 실제 데이터 분포가 다르면 비싼 계획을 고를 수 있고, 업데이트가 만든 오래된 행 버전을 VACUUM이 제때 정리하지 못하면 저장 공간과 조회 비용이 커진다.
MySQL과 InnoDB는 기본 키 중심 거래에 잘 맞는다¶
MySQL은 SQL을 처리하는 서버이고 InnoDB는 행·인덱스·트랜잭션과 복구를 맡는 기본 저장 엔진이다. 정해진 기본 키와 보조 인덱스로 대부분의 요청을 처리하고, 조직에 MySQL 운영 표준이 갖춰져 있다면 실용적인 기본값이다.
InnoDB는 기본 키 B-Tree의 리프에 행 전체를 둔다. 보조 인덱스에도 기본 키가 들어가므로 길고 무작위적인 기본 키는 모든 보조 인덱스와 캐시 효율에 영향을 준다. 제품을 선택했다면 기본 키 설계도 함께 결정해야 한다.
Oracle과 SQL Server는 운영 체계까지 포함한 선택이다¶
Oracle Database와 SQL Server는 성숙한 고가용성·보안·관리 도구와 상용 지원을 제공한다. 이미 저장 프로시저, 장애 조치 절차와 조직 표준이 깊게 연결된 환경에서는 라이선스만 비교해 교체하기 어렵다. 반대로 이런 기능과 지원을 사용하지 않는 새 팀에는 비용과 제품 종속이 더 클 수 있다.
“대기업이 쓰는 제품”이라는 이유보다 어떤 장애 보장과 지원 계약을 실제로 사용할지, 기존 업무 로직을 옮길 비용이 얼마인지로 판단한다.
Redis는 원본보다 빠르게 다시 만들 수 있는 상태에 가깝다¶
Redis는 메모리 기반 키-값 저장과 만료 시간, 카운터·집합 같은 자료구조를 제공한다. 캐시, 요청률 제한, 세션과 짧은 조정 상태에 적합하다. 알려진 키로 빠르게 접근할 때 강하지만 메모리는 비싸고, 큰 값이나 핫 키 하나가 처리 경로를 포화시킬 수 있다.
원본 저장소로 사용하려면 영속화 설정, 복제와 장애 전환에서 잃을 수 있는 범위를 먼저 확인한다. 캐시라면 손실 뒤 원본에서 재구성하는 절차와 동시에 만료될 때의 부하를 설계한다.
MongoDB는 함께 바뀌는 데이터를 문서 경계에 모은다¶
MongoDB는 JSON과 비슷한 문서를 저장 단위로 삼는다. 한 화면이나 한 업무에서 함께 조회하고 업데이트하는 데이터가 문서 하나에 자연스럽게 모이고 구조가 자주 바뀔 때 편리하다.
문서 경계를 넘는 관계와 조인이 많아지거나 배열이 제한 없이 커지면 장점이 줄어든다. 분산할 때는 샤드 키가 데이터와 트래픽을 고르게 나눌 수 있는지도 확인해야 한다. “애플리케이션이 JSON을 사용한다”는 사실만으로 선택할 제품은 아니다.
Cassandra는 조회 형태를 먼저 고정한다¶
Cassandra는 데이터 분할 키로 위치를 정하고 여러 노드에 복제해 큰 쓰기 처리량과 가용성을 얻는다. 먼저 필요한 조회를 정한 뒤 그 조회가 한 분할에서 끝나도록 표를 설계하고, 같은 데이터를 여러 표에 중복할 수 있다.
자유로운 조인과 사후 탐색에는 맞지 않는다. 삭제 표식이 쌓이는 현상, 디스크 파일 병합, 노드 복구와 일관성 수준을 지속적으로 운영해야 한다. 대규모 분산이라는 장점은 이런 책임과 함께 온다.
ClickHouse는 많은 행의 일부 열을 집계한다¶
ClickHouse는 열 단위 저장, 압축과 벡터화 실행으로 이벤트·로그와 대규모 집계에 강하다. 어떤 순서 키로 데이터를 놓는지에 따라 건너뛸 범위가 달라지고, 백그라운드 파일 병합이 적재와 질의 자원을 함께 사용한다.
주문 한 건을 자주 업데이트하고 여러 행의 규칙을 트랜잭션으로 지켜야 하는 원본 OLTP를 대신하는 제품은 아니다. 관계형 원본의 변경을 전달받아 분석용 파생본으로 사용하는 구성이 흔하다.
Elasticsearch와 OpenSearch는 단어에서 문서를 찾는다¶
두 제품은 문장을 토큰으로 분석하고 단어에서 문서로 이어지는 역색인을 만든다. 부분 단어 검색, 형태 분석, 관련도 순위와 로그 탐색이 필요할 때 관계형 B-Tree보다 자연스럽다.
새 데이터가 검색에 보이기까지의 지연, 세그먼트 병합, 샤드 크기와 필드 매핑을 운영해야 한다. 원본 관계형 데이터베이스와 함께 사용한다면 누락·중복·삭제를 복구하고 검색 인덱스 전체를 다시 만드는 절차가 필요하다.
벡터 데이터베이스는 의미가 가까운 후보를 좁힌다¶
벡터 검색은 문장이나 이미지의 특징을 숫자 배열로 표현하고 가까운 항목을 찾는다. HNSW와 IVF 같은 ANN(Approximate Nearest Neighbor, 근사 최근접 이웃) 인덱스는 속도를 얻는 대신 정답 후보를 일부 놓칠 수 있다.
문서 수가 작고 메타데이터 트랜잭션이 중요하면 PostgreSQL과 pgvector처럼 기존 원본에 가까이 두는 편이 단순할 수 있다. 전용 제품은 데이터 양, 응답 지연, 필터, 업데이트 빈도와 여러 사용자 조직의 분리가 실제로 기존 확장의 한계를 넘을 때 검토한다. 제품 이름보다 후보 재현율과 최종 답변 품질을 측정해야 한다.
제품 하나를 더하기 전에 답할 질문¶
먼저 그 저장소가 원본인지 파생본인지 정한다. 파생본이라면 원본에서 변경이 전달되는 최대 지연과 전체 재구축 시간을 기록한다. 저장소가 멈췄을 때 핵심 쓰기를 계속 받을지, 기능을 축소할지도 정해야 한다.
그다음 현재 제품으로 해결할 수 없는 병목을 수치로 남긴다. 특정 질의의 p99 지연, 스캔한 행과 반환한 행의 비율, 검색 품질, 저장 비용과 복구 시간을 본다. 이 수치가 새 제품의 데이터 이동·당직·업그레이드 비용보다 클 때만 분리가 정당화된다.