기존 pgvector의 HNSW 인덱스를 이 확장으로 교체하려면 몇 가지 제약을 먼저 확인해야 함. PRISM의 최대 벡터 차원은 1968이며, 이를 넘는 기존 인덱스는 현재 사용할 수 없음. PRISM은 양자화된 IVF 인덱스임. Postgres 18 이상이 필요하므로 이전 버전에서는 데이터베이스부터 이전해야 함. 운영 환경에 PG 14나 15가 여전히 많아, 단순히 시험해 보기에는 이전 비용이 너무 큼.
어제 출시된 알파 단계라 Timescale 외부 운영 환경에서 충분히 검증되지 않았고, Azure 등 대형 클라우드의 관리형 PG 확장 허용 목록에도 없음. 관리형 환경에서는 지원을 기다리거나 PG 18 자체 호스팅으로 이전해야 함.
인덱스용으로 벡터 차원을 잘라낸 뒤 전체 벡터로 추가 비교할 수 있음. 현재 작업 중인 프로젝트에서는 subvector(..., 1, 768)::vector(768)로 768차원만 사용해 조인 후보를 찾고, WHERE 절에서 전체 임베딩의 <-> 거리를 다시 확인함.
인덱스로 빠르지만 덜 정확한 검색을 수행한 다음, 일치한 결과에만 인덱스 없는 전체 벡터 비교를 적용하는 방식임.
Azure DB에서 pgvector를 사용했는데 꽤 괜찮게 작동했음. HNSW와 PRISM의 전문가는 아니지만, 모두 하위 호환된다면 왜 pgvector에 PR을 보내지 않고 별도 확장을 만들었는지 궁금함.
가볍게 내린 결정은 아닐 테지만, 이런 설계에 이른 과정을 더 알고 싶음. README만으로는 위의 번거로움을 감수해야 할 이유가 충분히 드러나지 않음.
현재 VectorChord를 아주 만족스럽게 사용 중이며, 빠른 디스크와 함께 쓰니 Postgres 비용이 절반으로 줄어듦. RAM을 적게 쓰는 벡터 인덱스 도구에 경쟁이 생겨 반가움. 메모리 대란이 최신 NVMe의 속도를 더 적극적으로 활용할 동기를 만들어 주는 듯함.
pg_vectorsearch의 주 기여자임. 두 도구를 모두 사용해 본다면 사용 소감과 개선할 부분을 알려 주기 바람.
같은 팀이 만든 pgvectorscale은 지금 유지보수가 안 되는 듯한데, 기존 확장을 개선하지 않고 새 인덱스를 만든 이유가 무엇인가?
pgvectorscale 개발자임. 블로그 글에서 이 부분을 직접 다룸.
pgvectorscale의 예측하기 어려운 재현율이 만족스럽지 않았고, 문헌에서도 해결책을 찾지 못했음. 장기적으로는 그래프 알고리즘에서 분할 기반 알고리즘으로 전환하는 편이 낫다고 판단함.
훨씬 빠르고 저장 공간도 적게 쓰는 것으로 아는 비트 정밀도와 해밍 거리 연산자 지원이 보이지 않는데, 지원하지 않는 것인가?
필터링을 지원하는지 확인해 보니 사후 필터링만 지원함. 이런 인덱스로 테넌트·사용자·권한 범위를 어떻게 효율적으로 제한하는지 이해하기 어려움.
파티셔닝은 Postgres에서 자연스럽게 해결되는 쉬운 부분이라고 봄. 그런데 벡터 데이터베이스에서 최신 데이터에 가중치를 주는 처리는 어떻게 하는가? 우리가 시도한 방식은 모두 비용이 크거나 지나치게 임시방편에 가까움.
다중 테넌트 테이블용 다중 열 인덱스는 향후 출시 버전에 계획되어 있음.
LanceDB는 DataFusion을 통해 필터 푸시다운과 리스트·배열의 원소 포함 여부 검사를 지원함.
SQLite에도 이런 기능이 있으면 정말 좋겠음.
SQLite 위에서 Paxos를 사용하고, SQLite의 FTS와 sqlite-vec 확장으로 상호 순위 융합(RRF) 및 분포 기반 점수 융합(DBSF) 을 구현한 두 프로젝트를 살펴볼 수 있음.
zaxonlite: https://github.com/insanai/zaxonlite.
sqlodin: https://github.com/insanai/sqlodin.
SQLite는 한 번에 하나의 쓰기 작업만 허용하므로 두 프로젝트 모두 이 제약을 고려해야 함. PostgreSQL은 MVCC를 사용하므로 여러 클라이언트의 동시 쓰기 성능이 더 나을 수 있지만, 직접 비교 측정을 하지는 않아 단정할 수 없음.