Vector DB란 무엇일까? 그리고 어떤 Vector DB를 사용해야할까? (2)

이전 글에서는 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

https://www.ethanrosenthal.com/2023/04/10/nn-vs-ann/

https://medium.com/thirdai-blog/understanding-the-fundamental-limitations-of-vector-based-retrieval-for-building-llm-powered-48bb7b5a57b3