벡터 데이터베이스 가이드
최근에 서비스에 벡터 DB를 도입하게 되면서 조사를 이래저래 좀 해봤다.
근데 벡터DB 자체가 뜬지 오래지 않아서인지, 신뢰할만한 벤치마크 정보도 별로 없고, 정신없이 난립만 하는 느낌이 좀 있다. 게다가 기술 베이스에 대해 전체적으로 잘 정리된 자료도 잘 없는거같아서 조금 헤맸다.
헤매는 나그네들에게 지침이 될수 있게끔 정리를 한번 해본다.
기반 지식
다음 내용들은 미리 알아두는 것이 좋다.
그래야 벡터 DB의 사용 구조나, 기술 판단에 최소한의 길을 잡을 수 있을 것이다.
-
벡터 검색의 일반적인 사용 구조와, 유사도 알고리즘
https://blog.naver.com/sssang97/223790220320 -
벡터 DB의 일반적인 인덱스 구조: HNSW
https://blog.naver.com/sssang97/223845582324 -
벡터 압축 매커니즘: 양자화
https://blog.naver.com/sssang97/223848217468
DB 평가 및 선택 기준
AI로 크게 hype이 생긴만큼 벡터 DB들은 꽤 많고, 선택지도 많다.
하지만 각자 장점으로 삼는 부분들이 다르고 제약도 다르기 때문에 성격을 잘 파악하고 고르는 것이 중요하다.
내가 파악한 각 벡터 DB들이 가진 장단점이나 선택할만한 근거들을 나열해보겠다.
비-전문 벡터 DB로서 벡터 DB를 부가기능으로 제공하는 것은 Elasticsearch, PostgreSQL(pgvector), Redis, MongoDB(Atlas), AWS Opensearch 등이 있다.
그리고 전문 벡터 DB로 유명한 것들은 Qdrant, Pinecone, Milvus 정도가 있다.
이 중 클라우드로만 지원되는 VectorDB인 Pinecone, AWS Opensearch, MongoDB Vector Search는 대상에서 제외했다. 비용 최적화가 필요한 수준에 이른다면 직접 Self-Host로 구성하는 것도 고려해야 하기 때문이다.
그리고 인메모리라 데이터 확장에 큰 한계가 있는 Redis는 바로 걸러졌다. 내 생각에 이건 프로토타이핑 이상의 가치는 없을듯하다.
사전 필터링(pre-filtering) 지원 여부도 선택의 주요 근거 중 하나가 될 수 있다.
대표적으로 pgvector는 사전 필터링을 지원하지 않는다. Elasticsearch, Qdrant, milvus는 사전 필터링을 지원한다. 하지만 사전 필터링 구현 방식도 각각 다 달라서 성능/정확도에 차이가 있다.
아무튼 나는 결과적으로 pgvector, elasticsearch, milvus, qdrant 정도만 후보로 두고 부하테스트를 해봤다.
공통적으로 메모리 8GB, 1cpu 사양을 주고, 길이 256짜리 벡터를 1000만개 정도만 넣고 갈궜다. 의도적으로 각박한 환경을 조성했다.
pgvector
- 사전 필터링이 필요하지 않고, 애초에 PostgreSQL를 쓰고 있다면 멋진 선택이 될 수 있다. hnsw도 좋지만 ivfflat도 저렴하고 쌈마이한 맛이 있다. 초기 도입이나 PoC 용으로 충분하다.
- pgvector-ivfflat: 1000만개 미만에서는 ivfflat로도 충분히 감당이 가능하다. 대체로 n00밀리초 단위로 처리가 된다. 엄청나게 빠른 레이턴시가 필요한게 아니라면 쓸만하다.
- pgvector-hnsw도 훌륭한 성능을 보였다. INSERT나 인덱스 구성 속도는 매우 느리긴 했는데, 조회는 두자릿수 ms로 다른 벡터DB들과 비교해서도 꿇리지 않았다. 메모리 사용량이 높긴 했다. (터지진 않는다.)
elasticsearch
- elasticsearch을 기존에 쓰고 있다면 이것도 괜찮은 선택이 될 수 있다. 근데 그게 아니라면 굳이...?
- 레이턴시 보장이 잘 안됐다. 1초를 넘어가기도 했다. 그렇게 안정적이진 않다.
- 디스크 저장 효율도 전문 VectorDB에 비하면 조금 모자라다.
milvus
- 가장 끔찍한 데이터베이스였다.
- 다른 DB들은 8GB 잡고 넣으면 느리더라도 다 들어갔는데, 이건 DB에서 OOM이 나서 계속터졌다. 그래서 32GB 잡으니까 그제야 벤치마크가 가능해졌다. 리소스 효율성이 공포스러운 수준이다.
- 보통 디스크 DB들은 메모리가 부족하면 속도가 느려지더라도 메모리를 좀 아껴쓰는 식으로 가용성을 가져가는데, 이건 아니다.
- API 문서화도 좀 그렇고, API 오류 응답까지 좀.. 가라로 해뒀다. 사용성이 가장 낮다.
- 벤치마크 싸움에만 골몰해서 내실을 신경쓰지 않는 느낌을 받았다.
- 단일노드 구성 같은게 불가능하다. 무조건 etcd와 스토리지 매니저(minio 등)까지 세트로 구성해야 하기 때문에, 관리포인트가 분산되고 가볍게 시작하기 어렵다.
- 장점을 꼽자면, 메모리를 미친듯이 먹는만큼 레이턴시가 빠르긴 했다는 것이다. 다른 DB들과 동일스펙으로 맞춰서 때렸을 때도 가장 빨랐다. (거의 두자릿수 ms 보장)
- 스토리지 기반으로 데이터를 제어할 수 있다는 것도 장점으로 볼 수 있다. 예를 들어, 데이터를 S3에 저장해놓고 쓸 수 있는 것이다. 근데 이게 비용적으로 효율적이고 관리 가능한 방식인지는 잘 모르겠다. 나는 통제가 어려울 것 같아서 별로 끌리진 않았다.
qdrant
- 단일노드로 가볍게 시작하기 쉽고, 클러스터를 통한 확장도 잘 지원한다.
- 문서화도 잘 되어있고 기능이 elasticsearch 사용자에게 친화적인 구조다.
- 리소스 효율성은 가장 뛰어난 편이다. 기본적인 디스크 사용량도 다른 VectorDB의 절반쯤 되고, 메모리 사용량도 가장 적었다.
- 속도는 200ms-400ms 정도로 특출난 정도는 아니지만 꽤 무난하고 안정적이었다.
결론적으로 나는 사용성과 성능, 비용이 가장 균형잡혔다고 판단한 qdrant를 선택했다.
qdrant Cloud도 경쟁이 많아서인지 그렇게 비싸진 않았고, Self-Host 관리 용이성도 가장 나아보였다.
하지만 나는 내 상황에 맞는 것을 선택했을 뿐이다. 무엇을 고를지는 당신의 선택에 달렸다.
벤치마크 참조
- pgvector, elasticsearch, qdrant
https://blog.naver.com/sssang97/223840387576
- milvus