Data Eng Wiki

What Is a Converged Database

11 min read

What Is a Converged Database? Definition, Five Tests, and AI Use Cases

Source: Oracle Developers Blog | Published: 2026

한 줄 요약

“여러 모델을 지원한다”는 것은 제품 스토리지 레이어의 속성이고, 수렴(convergence)은 보증(guarantee)의 속성이다 — 다섯 가지 테스트가 둘을 가른다.

핵심 주장/내용

  • 세 패턴 구분:
    • Converged database — 하나의 엔진이 공유된 트랜잭션·optimizer·일관성·거버넌스 보증 하에 여러 데이터 모델을 지원. RAG나 에이전트가 신선하고 거버넌스되고 운영 컨텍스트와 조인된 검색을 필요로 할 때 유용
    • Multi-model database — 하나의 제품이 여러 모델을 저장할 수 있지만 보증이 모델 경계에서 멈출 수 있다. 통합에는 유용하지만 cross-model 쿼리·롤백·접근 통제가 하나의 시스템처럼 동작해야 한다면 불충분
    • Vector database — 임베딩 유사도 검색에 최적화된 특화 시스템. 독립 유사도 서빙에는 유용하지만 답이 라이브 술어·트랜잭션·관계형 조인도 필요로 할 때는 덜 완전
    • (converged database이지 converged infrastructure가 아니다 — 후자는 컴퓨트·스토리지·네트워킹을 합치는 하드웨어 이야기고, 이건 여러 DB 엔진을 하나로 합치는 데이터 아키텍처 이야기)
  • 다섯 가지 테스트 (각각 companion 리포지토리의 실행 가능한 assert 증명으로 뒷받침):
    1. 하나의 트랜잭션 경계 — 단일 ACID 트랜잭션이 관계형 insert, 문서 write, 벡터 update, 그리고 그것들을 서빙하는 인덱스에 걸칠 수 있고, 롤백이 전부를 원자적으로 되돌린다. 대부분의 multi-model 시스템이 시도조차 하지 않는 테스트다 — Lu와 Holubová의 multi-model DB 서베이(ACM Computing Surveys 2019)가 약 20개 시스템을 조사해 데이터 모델 전반에 걸친 “특수한 트랜잭션 관리의 존재에 대한 명시적 정보를 찾지 못했다” 고 보고
    2. 하나의 optimizer — 비용 기반 플래너가 여러 모델을 건드리는 문장에 대해 단일 costed plan을 생산한다. 검증 가능한 주장이다: EXPLAIN PLAN을 그래프 패턴 + JSON 술어 + 벡터 거리 랭킹 + 관계형 조인을 결합한 문장에 돌려 하나의 plan tree가 넷 다 커버함을 assert한다. “그래프 쿼리”가 서비스 API에 대한 애플리케이션 측 루프라면 그런 plan은 없고, 조인 순서가 애플리케이션 로직에 하드코딩된 분산 시스템이 있을 뿐이다
    3. 하나의 일관성 모델 — read-your-writes가 모든 모델·모든 API에서 성립한다. 모델들 사이에 복제 파이프라인이 없기 때문이다 — sidecar 프로세스를 먹이는 change stream도, oplog 윈도우도, 재인덱싱 지연도 없다
    4. 하나의 보안·거버넌스 도메인 — 같은 grant, 같은 row-level 정책, 같은 audit 스트림이 문서 API·SQL 인터페이스·벡터 검색 경로·그래프 순회를 커버한다. 각각이 같은 row에 대한 같은 엔진의 projection이기 때문
    5. 공유 접근 표면 — SQL, MongoDB 호환 문서 API, REST가 하나의 게이트웨이 뒤의 서로 다른 엔진이 아니라 하나의 엔진의 projection으로서 같은 데이터를 다룬다
  • 첫 번째 증명이 내재화할 것: 네 개의 write(관계형 order, line item, 컬렉션으로의 JSON 문서, 벡터 임베딩 update)가 하나의 미커밋 트랜잭션 안에서. 전형적 특화 스택(DynamoDB + OpenSearch + Pinecone)에 흩어지면 각 시스템의 원자성이 자기 경계에서 멈춘다 — DynamoDB의 TransactWriteItems는 DynamoDB 안에서만 최대 100개 액션을 묶고, Pinecone은 인덱스 업데이트가 eventually consistent임을 문서화하며 쓰인 데이터가 즉시 보이지 않기 때문에 freshness 확인 메커니즘을 제공한다. 세 시스템에 걸치는 트랜잭션 API는 없고, 별개 시스템 사이에서 롤백은 애플리케이션 레벨 보상 문제가 된다
  • optimizer 증명 — plan이 보여주는 것: 문장이 referral 그래프를 순회하고 도달 가능한 고객의 지원 티켓을 벡터 유사도로 랭킹하고 관계형 컨텍스트를 조인한다. GRAPH_TABLE 연산자가 “내부적으로 동등한 SQL로 번역” 되어 그래프 패턴이 관계 대수가 되고 나머지 모든 것과 같은 optimizer로 costed된다. plan에서 그래프 quantifier {1,4}가 referral 엣지 인덱스에 대한 1~4 hop 조인의 UNION-ALL로 펼쳐져 그래프 이름의 평범한 뷰 row source로 나타나고, JSON 술어가 컬렉션 테이블에 대한 hash anti-join이 되고, 벡터 랭킹이 티켓 테이블에 대한 sort가 된다 — 하나의 tree, 하나의 cost model. federation seam도, 모델별 플래너 경계도, 통계 경계도 없다. 그것이 “하나의 optimizer”의 구체적 의미
  • 왜 RAG와 AI 에이전트에 중요한가: AI가 multi-store 일관성 문제를 만들지 않았다. 그것에 대한 관용을 없앴다
    • RAG 파이프라인, 더 첨예하게는 행동하는 에이전트는 신선하고 거버넌스되고 조인된 컨텍스트를 필요로 한다
      • 신선하게 — 임베딩이 마지막 동기화 시점이 아니라 지금 이 순간의 row를 반영해야 한다
      • 거버넌스되게 — 사용자(또는 에이전트)의 권한이 검색 내부에서 강제되어야지, 모든 접근 경로가 통과한다고 가정되는 애플리케이션 코드에서가 아니다
      • 조인되게 — “유사한 문서”는 좀처럼 프로덕션 질문이 아니다. “이 고객의, 이 지역의, 열린 티켓이 있는, 유사한 문서”가 질문이다
    • multi-store 아키텍처에서는 그 속성 각각이 파이프라인이다. 벡터 인덱스가 설계상 운영 스토어를 뒤따르고(Pinecone이 freshness 확인 메커니즘을 제공하는 이유는 업데이트가 쿼리에 즉시 보이지 않기 때문), MongoDB 문서는 검색 인덱스가 별도 프로세스로 DB에서 지속 소싱되며 eventual consistency에 read-after-write 보장이 없다고 기술한다
    • 수렴된 응답은 더 빠른 파이프라인이 아니라 파이프라인의 부재다 — 문서 API를 통한 write가 그 사이에 lag될 것이 아무것도 없기 때문에 같은 초에 SQL에 보인다

주요 수치 / 사실

  • 증명 매트릭스: 01-one-transaction-every-model.sql(assert 6개), 02-duality-roundtrip.js(4), 03-one-optimizer.sql(2), 04-read-your-writes.js(2), 05-one-plan.sql(6). 모든 스크립트가 CI에서 실행되고, 이 글의 계약은 열망이 아니라 테스트를 인용한다는 것
  • 예제 도메인은 매 글이 공유하는 작은 커머스 도메인: 고객 200명, 주문 1,000건, 임베딩이 있는 지원 티켓 300건, referral·기기 그래프, 매장 위치. 의도적으로 평범한 커머스 도메인이 모든 모델을 자연스럽게 요구한다 — 주문은 관계형, 프로필은 문서, 사기 ring은 그래프, 티켓 유사도는 벡터, 매장 근접성은 공간
  • 핵심 정리: converged database는 스토리지 지원이 아니라 cross-model 보증으로 정의된다 / 다섯 테스트는 하나의 트랜잭션 경계, 하나의 optimizer, 하나의 일관성 모델, 하나의 거버넌스 도메인, 공유 접근 표면 / multi-model 스토리지는 흔하고 cross-model 보증이 차별점

관련 위키

Source: 원문 보기

그래프 뷰

백링크