이전 글에서는 Vector DB가 무엇인지와 Vector DB에서 데이터를 검색하기 위한 방법들에 대해서 알아보았다.
오늘은 Vector DB의 종류들과 특성, 장단점에 대해 분석해보려 한다.
3. 어떤 Vector DB를 사용해야할까?#
VectorDB를 선택할때는 현재 진행하는 서비스 또는 프로젝트의 상황과 환경에 비추어 적절한 DB를 선택할 수 있어야 한다.
따라서, Vector DB의 여러 요소들을 살펴, 적합한 DB를 선택해야하는데, 아래 기준들을 면밀히 살펴봐야한다.
1) 성능과 속도
: 검색 속도
대규모 데이터셋에서 검색 속도는 가장 중요한 요소 중 하나이다. 검색 알고리즘의 효율성과 데이터 인덱싱 방법이 검색 속도에 큰 영향을 미치게 된다.
: 삽입 및 업데이트 속도
데이터의 삽입과 업데이트 속도 또한 벡터 데이터베이스의 성능을 결정하는데 중요하게 고려해야할 요소에 해당된다.
2) 확장성
: 수평 확장성
데이터베이스가 물리적으로 다른 서버에 데이터를 분산하여 저장하고 처리할 수 있는 능력을 의미하는데,
데이터의 양이 증가함에 따라 데이터베이스 시스템을 쉽게 확장할 수 있는지를 확인해야한다.
: 수직 확장성
하드웨어의 업그레이드를 통해 성능을 향상 시킬 수 있는 능력을 의미한다.
이는 초기 비용은 적지만 ,장기적으로는 한계가 있을 수 있기 때문에 중요한 고려요소에 해당한다.
3) 지원하는 검색 알고리즘 및 기능
: ANN(근사 최근접 이웃 검색)
대부분의 Vector DB는 ANN 검색을 지원한다.
다양한 ANN 알고리즘 중에서 특정 데이터베이스가 어떤 알고리즘을 지원하고있는지가 매우 중요하다.
: 고급 인덱싱 기법
데이터 인덱싱은 검색 성능에 큰 영향을 미친다.
예를들어, HNSW, IVF, PQ와 같은 인덱싱 기법을 빠짐없이 지원하는지는 매우 중요한 요소가 된다.
4) 용이성 및 관리 편의성
: 설치 및 설정
데이터 베이스의 설치와 설치 과정이 간단하고 문서화가 잘 되어 있는지 확인해야한다.
: 관리 도구 및 인터페이스
관리자 및 개발자가 데이터베이스를 쉽게 관리하고 사용할 수 있는 도구와 인터페이스를 지원하는지 확인해야한다.
5) 지원 및 커뮤니티
: 공식문서
충분하고 명확한 공식 문서가 있는지 살펴본다
: 커뮤니티 및 지원
활발한 커뮤니티 지원과 개발자 지원이 있는지 확인한다.
커뮤니티의 크기와 활동성은 문제 해결에 도움이 될 수 있고, 지속적인 개선이 가능한지를 판단할 수 있는 잣대가 된다.
6) 비용
: 라이선스 비용
오픈소스인지 상용 라이선스가 필요한지, 그리고 비용이 어떻게 구성되는지를 확인해야한다.
: 운영비용
클라우드 기반 서비스를 사용할 경우 발생할 수 있는 운영 비용도 고려해야 한다.
자, 이제 어떤 요소들을 중점적으로 판단해야하는지 확인했으므로,
아래 테이블을 통해 각 Vector DB들의 특징들을 자세히 살펴보고 현재 진행하려는 프로젝트의 환경과 목적에 부합하는
Vector DB를 선택할 수 있다.
| Vector DB | 오픈소스 유무 | 지원언어 | 지원 검색 알고리즘 | 특징 |
| Weaviate | O | Python, GO, Java, JS | Custom HNSW | - NLU기능 내장을 통해 텍스트 데이터에 대한 시맨틱 검색 강화 - GraphQL API 지원을 통해 간편한 질의 가능 |
| Milvus | O | Python, GO, C++ | ANN, HNSW, ANNOY | - 대규모 데이터셋에 강점 - 다양한 인덱싱 알고리즘 지원 - 높은 확장성 및 검색 성능 - K8s 를 통한 클라우드 배포 가능 |
| Vespa | O | Java, C++ | HNSW(graph) | - 실시간 인덱싱과 데이터처리에 최적화 - 자동화된 스케일링 - 설정과 관리방법은 다소 복잡 - 대규모 프로젝트에만 초점이 맞춰짐 |
| Vald | O | Go | NGT | - K8s 기반의 자동화된 운영 및 확장성 - 설정과 운영 복잡 |
| Chroma | O | Python, JS | HNSW | - 사용법 간단 - http방식, 디스크저장방식, 인메모리 방식을 선택할 수 있음 |
| Qdrant | O | Rust | HNSW(graph) | - Json기반의 REST API와 함께 직관적인 필터링(조회조건 설정) - 사용 난이도 낮음, 빠른검색 |
| Pinecone | X | - | 복합으로 사용하며, 독점 상태 | - 클라우드 기반(비용 발생) - 데이터양에 따른 오토 스케일링 가능 - 간단한 API 사용법 - 사용 난이도 낮음 |
| ElasticSearch | X | - | Neural hashing / Hamming distance | - 커뮤니티 - 전문 vector DB에 비해 벡터 검색기능의 제한 - 설정 및 관리 복잡 |
마치며#
결국, 어떤 Vector DB를 도입해야할지에 대해 고민할때는, 적용에 앞서 Vector DB가 꼭 필요한지와 적합성에 대해서 꼭 고민이 필요하다.
Vector DB가 모든 사례에서 긍정적인 효과를 기대할 수 있는것은 아니며, 아래의 경우에 해당한다면
도입효과는 반감되거나 오히려 추후에 서비스를 제공함에 있어 리스크로 작용할 수 있다.
먼저, 다루고자 하는 데이터가 모두 vector data인지 검토해야한다.
만약 vector data뿐아니라 다양한 정형데이터도 함께 관리되어야하며 이미 사용중인 DB가 있을 경우에는
위의 전문 Vector DB가 적합하지 않을 수 있고, ANN, NN을 지원해주는 기존의 DB를 활용하는것도 방법이다.
postgres의 pgvector과 같은 대안들을 고려해볼 수 있는것이다.
또한, 저장된 데이터의 Embedding의 dimension이 클 경우, 검색 알고리즘의 정확도가 낮아질 수 있기 때문에
embedding size를 고려하여 다른 방법을 강구하는것이 더 좋은 방향일 수도 있다.
그리고, 데이터베이스에 수록할 데이터가 매우 클 경우에도 데이터를 임베딩하고 인덱싱하는 작업 자체에, 많은 시간과 리소스가 필요하게 되므로, 지속적인 데이터베이스 업데이트와 인덱싱이 이뤄져야할 경우 문제가 될 수 있다.
주어진 쿼리에 대해 데이터베이스 내 데이터들과 유사도를 계산함에 있어서도, batch로 처리할지 realtime으로 처리할지에 대한
고민 또한 필요하기 때문에 고려할 부분이 많아진다.
따라서, Vector DB를 적용하기 전에, 먼저 복합적인 문제 요소를 다각도로 분석하여, Vector DB가 꼭 필요한지,
충분히 적합한지에 대한 검토가 깊게 이루어지는 것이 선행되어야 하겠다.
Reference#
https://hotorch.tistory.com/406