Document Store 고르기

Document Store 고르기 (Choosing a Document Store)

챗봇을 만들든, RAG 시스템을 만들든, 이미지 캡셔너를 만들든, 어느 시점에서는 반드시 "입력으로 들어온 것과 내가 이미 알고 있는 정보를 비교" 하는 일이 생겨요. 이 비교를 담당하는 게 검색(search)이고, 그 검색의 기반이 되는 저장소가 Document Store예요. 그런데 Haystack에는 Document Store 종류가 워낙 많아서, "뭘 고르지?" 하는 순간이 반드시 옵니다. 이 문서는 그 선택을 도와주기 위한 안내예요.

출처: Choosing a Document Store (공식 문서)

Haystack은 현재 일곱 가지 범주의 Document Store와 통합되어 있어요.

  • 벡터 데이터베이스 (Vector Databases) — 임베딩 검색과 의미론적 검색에 특화된 저장소
  • 검색 엔진 (Search Engines) — 벡터(kNN) 기능이 추가된 전문(full-text) 검색 엔진
  • 관계형 데이터베이스 (Relational Databases) — 플러그인/확장으로 벡터 검색을 지원하는 SQL 데이터베이스
  • 문서 / NoSQL 데이터베이스 — 위에 벡터 검색이 얹힌 유연한 문서 저장소
  • 인메모리 키-값 저장소 (In-memory Key-Value Stores) — HNSW 벡터 검색을 갖춘 초저지연 저장소
  • 벡터 인덱스 라이브러리 (Vector Index Libraries) — 외부 서비스 없이 프로세스 안에서 가볍게 돌아가는 벡터 유사도 검색
  • 멀티모델 데이터베이스 (Multi-model Databases) — 그래프·문서·벡터 데이터 모델을 한 엔진으로 지원

Haystack에서 사용 가능한 Document Store 통합

Haystack 통합은 두 가지 등급(tier)이 있어요. 코어 통합(Core integrations) 은 Haystack 팀이 만들고 유지 관리하는 것으로, 모든 릴리스에서 테스트되고 같은 API 규약을 따르며 완전한 문서와 지원을 제공해요. 외부 통합(External integrations) 은 커뮤니티가 기여하고 유지 관리하는 것으로, Haystack의 범위를 넓혀 주지만 코어 릴리스 주기의 적용을 받진 않아요.

아래 표에는 사용 사례에 맞는 것을 고르는 데 필요한 핵심 속성과 함께 모든 통합이 나열되어 있어요.

코어 통합 (Core Integrations)

통합 범주 엔진 타입 오픈소스 비동기 리트리버
ArcadeDB Multi-model Database HTTP/JSON API로 HNSW 벡터 검색을 지원하는 멀티모델 DB(그래프·문서·키-값) Yes No Embedding
AlloyDB Relational Database pgvector 확장을 탑재한 관리형 PostgreSQL(Google Cloud) No Yes Embedding, Keyword
ArangoDB Multi-model Database AQL 벡터 검색을 지원하는 멀티모델 DB(v3.12+ 필요) Yes (BUSL) No Embedding
Astra Document / NoSQL Database DataStax JSON API로 벡터 검색을 지원하는 클라우드 네이티브 관리형 NoSQL(Apache Cassandra 기반) No No Embedding
Azure AI Search Search Engine HNSW 벡터 검색을 지원하는 관리형 클라우드 검색 서비스(Microsoft) No No BM25, Embedding, Hybrid
Chroma Vector Database 벡터 검색 전용으로 만들어진 데이터베이스 Yes Yes Embedding
Elasticsearch Search Engine BM25 + 벡터(kNN) 검색을 지원하는 분산 검색·분석 엔진 Partial Yes BM25, Embedding, SQL
FAISS Vector Index Library 메타데이터용 JSON 파일을 사용하는 인메모리 벡터 유사도 검색 라이브러리(Meta/Facebook) Yes No Embedding
FalkorDB Graph Database ANN 벡터 검색을 지원하는 OpenCypher 그래프 DB Yes (SSPL) No Embedding, Cypher
MongoDB Atlas Document / NoSQL Database Atlas Vector Search와 전문 검색을 갖춘 클라우드 문서 DB No Yes Embedding, Full-text
Oracle Relational Database 네이티브 AI Vector Search, HNSW 벡터 인덱스와 DBMS_SEARCH 전문 키워드 인덱스를 갖춘 Oracle No Yes Embedding, Keyword
OpenSearch Search Engine BM25 + kNN 벡터 검색을 지원하는 분산 검색 엔진(Elasticsearch의 AWS 포크) Yes Yes BM25, Embedding, Hybrid, Metadata, SQL
PGVector Relational Database 벡터 유사도 검색용 pgvector 확장을 갖춘 관계형 DB(PostgreSQL) Yes Yes Embedding, Keyword
Pinecone Vector Database 관리형 클라우드 벡터 DB No Yes Embedding
Qdrant Vector Database 밀집 + 희소 임베딩을 지원하는 벡터 검색 전용 DB Yes Yes Embedding, Sparse Embedding, Hybrid
Solr Search Engine BM25 + kNN 밀집 벡터 검색을 지원하는 분산 검색 서버(Apache Lucene 기반) Yes Yes BM25, Embedding, Hybrid
Supabase Vector Database Supabase 특화 기본값으로 PgvectorDocumentStore를 감싼 관리형 클라우드 Yes Yes Embedding, Keyword
Valkey In-memory Key-Value Store glide 클라이언트로 HNSW 벡터 검색을 지원하는 인메모리 키-값 저장소(Redis 포크) Yes Yes Embedding
Vespa Search Engine BM25 어휘 + HNSW 벡터(ANN) 검색을 지원하는 분산 검색·서빙 엔진 Yes No BM25, Embedding
Weaviate Vector Database 하이브리드 검색을 지원하는 벡터 검색 전용 DB Yes Yes BM25, Embedding, Hybrid

외부 통합 (External Integrations)

통합 범주 엔진 타입 오픈소스 비동기 리트리버
Couchbase Document / NoSQL Database Search Service로 벡터 검색을 지원하는 분산 NoSQL 문서 DB Partial Yes Embedding, Full-text
LanceDB Vector Database Lance 컬럼형 포맷에 기반, 멀티모달 데이터에 최적화된 임베디드 벡터 DB Yes Yes Embedding, Full-text, Hybrid
Milvus Vector Database 확장 가능한 유사도 검색을 위해 만들어진 오픈소스 벡터 DB Yes No Embedding
Needle Search Engine 내장 문서 저장과 벡터 검색을 갖춘 관리형 RAG-as-a-service 플랫폼 No Yes Embedding, Sparse Embedding, Hybrid
Neo4j Multi-model Database 그래프 탐색과 유사도 검색을 결합할 수 있는 네이티브 벡터 인덱스 지원 그래프 DB Partial No Embedding
SingleStore Relational Database 네이티브 벡터 검색과 전문 검색을 지원하는 분산 SQL DB No Yes Embedding, Full-text, Keyword

벡터 데이터베이스 (Vector Databases)

  • 벡터·임베딩 검색에 특화된 목적으로 설계
  • 효율적인 유사도 검색을 위한 고급 인덱싱 기법
  • 대량의 고차원 데이터를 다루는 높은 확장성·가용성 지향
  • 대부분 벡터 검색과 함께 메타데이터 필터링 지원
  • 점점 하이브리드(벡터 + 키워드) 검색 지원 추가 중
  • 대부분 오픈소스, 관리형 클라우드 서비스로 널리 제공

이런 용도에 최적: 대규모 문서 컬렉션에 대한 의미론적 검색 — 예: 정확한 키워드보다 의미로 검색하는 지식 베이스.

검색 엔진 (Search Engines)

  • 원래 전문(BM25) 검색용으로 만들어졌고, 벡터(kNN) 기능이 나중에 추가됨
  • 텍스트 데이터, 형태소 분석, 언어 인식 쿼리에 탁월
  • 프로덕션 환경에서 수평·수직으로 모두 확장 가능
  • 키워드와 의미론적 검색을 결합한 하이브리드 검색의 강력한 기반
  • 성숙한 도구와 관찰성(observability)을 갖춘 엔터프라이즈 환경에서 검증됨

이런 용도에 최적: 전문(BM25) 검색과 벡터 검색이 모두 필요한 엔터프라이즈 검색이나 로그 분석 — 예: 필터가 있는 e커머스 상품 검색.

관계형 데이터베이스 (Relational Databases)

  • 플러그인/확장으로 벡터 검색이 추가된 표준 SQL 데이터베이스
  • 벡터가 관계형 데이터와 나란히 존재, 하나의 저장소에서 벡터 + SQL 쿼리 결합 가능
  • 이미 PostgreSQL을 쓰고 있다면 운영 오버헤드가 낮음
  • 벡터 검색 성능은 전용 DB보다 낮지만 많은 용도에 충분
  • 관계형 DB의 익숙한 도구, 트랜잭션, 데이터 무결성 보장

이런 용도에 최적: 문서가 구조화된 관계형 데이터와 함께 살아야 하는 경우 — 예: 벡터 검색과 SQL JOIN이 모두 필요한 상품 카탈로그.

문서 / NoSQL 데이터베이스

  • 위에 벡터 검색이 얹힌 범용 문서 저장소
  • 이질적인 문서 컬렉션에 적합한 유연하고 스키마 없는 데이터 모델
  • 기반 NoSQL 엔진에서 물려받은 수평 확장과 높은 가용성
  • 이미 DB를 쓰고 있는데 별도 벡터 저장소를 추가하기 싫을 때 좋은 선택
  • 벡터 검색 성능은 전용 DB에 못 미칠 수 있음

이런 용도에 최적: 새 인프라 요소를 도입하지 않고 RAG 기능을 추가하고 싶은 애플리케이션.

인메모리 키-값 저장소 (In-memory Key-Value Stores)

  • 인메모리 아키텍처로 읽기/쓰기 지연이 극도로 낮음
  • 기존 캐싱 인프라 위에 벡터 검색(HNSW)이 얹힘
  • 스택에 이미 Valkey를 캐시나 세션 저장소로 쓰고 있다면 이상적
  • 데이터는 기본적으로 휘발성(ephemeral); 영속화는 명시적 구성 필요
  • 메모리 비용이 커지는 대형 컬렉션에는 덜 적합

이런 용도에 최적: 저지연·실시간 검색 — 예: 서브 밀리초 응답이 필요한 챗봇.

벡터 인덱스 라이브러리 (Vector Index Libraries)

  • 완전한 DB가 아니라 저수준 프로세스 내 벡터 유사도 검색
  • 네트워크 오버헤드 없음, 완전히 애플리케이션 프로세스 안에서 실행
  • 하드웨어 자원(CPU/GPU)을 매우 효율적으로 사용
  • 벡터 전용; 메타데이터는 별도 관리 필요(예: JSON 파일로)
  • 내장 영속화·복제·다중 클라이언트 접근 없음

이런 용도에 최적: 외부 DB 서버를 돌리는 것보다 가벼운 프로세스 내 솔루션이 나은 로컬 프로토타이핑, 연구, 소규모 애플리케이션.

멀티모델 데이터베이스 (Multi-model Databases)

  • 그래프, 문서, 키-값, 벡터 등 여러 데이터 모델을 단일 엔진으로 지원
  • 서로 다른 데이터 표현을 위해 별도 DB를 유지할 필요 제거
  • 지식 그래프나 복잡한 엔티티 관계가 있는 앱에 적합
  • 그래프 탐색과 문서 쿼리와 함께 벡터 검색(HNSW) 사용 가능
  • 더 확립된 범주에 비해 커뮤니티와 생태계가 작음

이런 용도에 최적: 단일 엔진에 여러 데이터 모델이 필요한 애플리케이션 — 예: 엔티티가 관계로 연결되고 벡터 유사도 검색도 필요한 지식 그래프.

인메모리 Document Store

Haystack은 휘발성 Document Store 하나를 기본으로 동봉해요. 순수 파이썬 데이터 구조를 메모리에 유지하는 방식이라 위의 어느 벡터 DB 범주에도 속하지 않아요. 이 특별한 Document Store는 작은 데이터셋으로 빠른 프로토타입을 만들 때 이상적이에요. 특별한 설정이 필요 없고, 추가 의존성 설치 없이 바로 쓸 수 있어요.

마지막 고려사항 (Final Considerations)

순수 성능만 보고 Document Store를 고르기는 정말 어려워요. 벤치마크의 아주 사소한 차이만으로도 순위가 뒤바뀔 수 있으니까요(어떤 벤치마크는 클라우드 서비스를, 어떤 건 기준 머신을 테스트하기도 해요). 필터링 같은 기능을 포함할지 고민하는 것만으로도 비교가 훨씬 복잡해지는 새로운 복잡성이 생기거든요.

다행히 기억해 둘 점은, Document Store 인터페이스가 비용에 크게 영향을 주지 않고, 어떤 벡터 DB의 상대적 성능은 Haystack 파이프라인 안에서 쓰더라도 크게 달라지지 않는다는 거예요.

더 알아보기 (Learn more)