OpenData Vector: 객체 스토리지에서의 MIT 라이선스 벡터 검색

Generative AI와 대형 언어 모델(LLM)의 부상으로 전통적인 벡터 데이터베이스와 동일한 비용 부담 없이 선형적으로 확장할 수 있는 벡터 데이터베이스 아이디어가 필요해졌습니다. OpenData Vector는 객체 스토리지를 기본 저장 계층으로 활용하는 새로운 벡터 검색 접근 방식을 도입하여, 컴퓨팅과 스토리지를 효과적으로 분리하고 확장 가능한 MIT 라이선스 대안을 제공함으로써 기존의 독점 벡터 검색 엔진을 대체합니다.

OpenData Vector의 아키텍처

OpenData Vector는 핵심적으로 벡터 데이터베이스의 주요 병목 현상인 고성능 스토리지의 비용과 규모 문제를 해결하도록 설계되었습니다. 객체 스토리지(AWS S3, Google Cloud Storage, Azure Blob Storage 등)를 활용함으로써 사용자는 고성능 검색에 일반적으로 필요한 고가의 SSD 기반 인프라 없이도 대규모 임베딩 데이터를 유지할 수 있습니다.

이러한 컴퓨팅과 스토리지의 분리는 독립적인 확장을 가능하게 합니다. 검색량이 증가하면 전체 데이터 세트를 여러 고가 디스크에 복제할 필요 없이 더 많은 컴퓨팅 노드를 추가해 쿼리 부하를 처리할 수 있습니다. 반대로 데이터 양이 늘어나더라도 객체 스토리지는 고성능 블록 스토리지보다 훨씬 저렴하기 때문에 스토리지 비용은 낮게 유지됩니다.

성능 및 구현 세부 사항

객체 스토리지는 로컬 SSD보다 본질적으로 느리지만, OpenData Vector는 지연 시간을 완화하기 위한 전략을 구현합니다. 아키텍처는 인덱스와 데이터를 분리하는 패턴을 따르며, 인덱스는 보다 성능이 좋은 계층에 캐시되거나 저장되어 쿼리 결과가 빠르게 반환되도록 합니다.

이 접근 방식은 Turbopuffer와 같은 다른 고성능 벡터 검색 엔진에서 볼 수 있는 아키텍처 패턴과 유사합니다. 목표는 효율적인 인덱싱 및 메모리 관리를 통해 검색 정확도를 유지하면서 높은 쿼리 처리량을 달성하는 것입니다.

커뮤니티 토론 및 주요 고려 사항

출시 이후 커뮤니티는 성능 트레이드오프와 프로젝트의 현재 성숙도에 대해 여러 중요한 질문을 제기했습니다.

성능 격차

주요 우려 중 하나는 OpenData Vector가 고도로 최적화된 하드웨어 가속 시스템과 어떻게 비교되는가 하는 점입니다. 커뮤니티 멤버 @oliverio가 지적했듯이 일부 독점 시스템은 하드웨어 및 펌웨어 계층에서 상당한 최적화를 제공하여 성능 격차를 만들 수 있습니다. OpenData Vector의 과제는 이러한 최적화를 오픈소스 프로젝트에 적용하면서도 객체 스토리지의 범용성을 유지하는 것입니다.

객체 스토리지 QPS 비용

또 다른 논의 포인트는 요청 비율 비용입니다. 일반적인 인식으로는 객체 스토리지가 초당 쿼리 수(QPS)가 매우 높아질 경우 GET 및 PUT 작업에 따른 요청 비용 때문에 비싸질 수 있다는 것입니다.

"QPS 수치가 높아지면 객체 스토리지는 '일반' SSD에 비해 매우 비싸다는 인상을 받았습니다."

이를 해결하기 위해 객체 스토리지를 기반으로 하는 시스템은 일반적으로 공격적인 캐시 계층을 사용하거나 데이터가 스토리지 계층에 커밋되기 전에 DB 서버에서 상당한 사전 처리를 수행합니다. 객체 스토어에 대한 직접 호출 수를 줄임으로써 이러한 시스템은 스토리지 비용 효율성과 로컬 디스크 수준의 성능을 동시에 유지할 수 있습니다.

결론

OpenData Vector는 공급업체 종속성을 피하고 임베딩에 대한 제어권을 유지하려는 사람들에게 매력적인 MIT 라이선스 대안을 제공합니다. 벡터 검색 엔진을 객체 스토리지로 이동함으로써 고가의 고성능 스토리지 요구라는 전통적인 모델에 도전하고, 대규모 벡터 검색을 개발자와 MIT 라이선스 소프트웨어 프로젝트에 보다 접근 가능하게 만듭니다.