벡터 데이터베이스 — pgvector 와 Qdrant · 전용 벡터 DB · 퀴즈
퀴즈: 전용 벡터 데이터베이스
문항 8개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.
Qdrant 가 필터를 다루는 방식이 pgvector 의 HNSW 와 다른 점은?
- 필터를 검색 뒤에 거는 것은 같지만 후보 수에 상한이 없어 결국 다 찾는다
- 필터 조건마다 부분 컬렉션을 자동으로 만들어 두고 그중 하나를 고른다
- payload 인덱스로 조건에 맞는 점만 그래프 탐색하고, 조건이 좁으면 전수 검사로 바꾸어 결과가 줄지 않는다
- 필터가 있으면 언제나 전수 검사를 하므로 인덱스의 이점이 사라진다
Qdrant 검색 응답의 `score` 는 무엇인가?
- 유사도라 클수록 가깝고, pgvector 의 <=> 와 순위는 같되 숫자의 방향이 반대다
- 코사인 거리라 작을수록 가깝고 pgvector 의 <=> 와 같은 값이다
- 순위 그 자체라 1 이 가장 가깝고 정수만 나온다
- L2 거리의 제곱이라 0 에 가까울수록 같은 문서다
'billing 범주의 점을 전부' 훑어야 할 때 검색(query) 대신 scroll 을 쓰는 이유는?
- 검색 결과를 정렬해서 보려면 scroll 로 다시 읽어야 하기 때문
- REST 응답은 1MB 를 넘지 못해 큰 벡터는 scroll 로만 받을 수 있기 때문
- scroll 이 payload 인덱스를 만들어 다음 검색을 빠르게 하기 때문
- 검색은 상위 k 건만 돌려주므로 조건에 맞는 점을 전부 훑으려면 next_page_offset 으로 넘겨야 하기 때문
payload 인덱스를 만들지 않고 필터 검색을 하면?
- 필터가 있는 검색이 오류로 거부된다
- 필터는 동작하지만 조건에 맞는 점을 찾으려고 payload 를 전부 읽어 느려진다
- 필터는 되지만 결과가 pgvector 처럼 limit 보다 적게 온다
- scroll 이 동작하지 않아 페이지를 넘길 수 없다
스냅샷을 '만들었다' 와 '보관했다' 의 차이는?
- 스냅샷은 만들면 자동으로 원격 저장소에 복제되므로 확인만 하면 된다
- 스냅샷은 벡터만 담고 payload 는 빠지므로 payload 는 따로 덤프해야 한다
- 파일을 다른 곳으로 옮기고 새 컬렉션에 복원해 점 수와 검색 결과를 확인해야 백업이다
- 스냅샷은 컬렉션을 잠그므로 만든 직후 바로 지워야 한다
Qdrant 의 payload 에는 무엇을 넣는 것이 맞나?
- 가능한 모든 열 — 조인이 없으니 payload 가 곧 데이터베이스다
- id 만 — payload 는 검색 속도를 늦추므로 비워 둔다
- 벡터의 원문 텍스트 — 재임베딩 때 원본 대신 쓸 수 있다
- 필터와 표시에 필요한 것만 — 본문까지 넣으면 원본이 둘이 되어 동기화 사고가 난다
컬렉션을 만들 때 반드시 정해야 하고 나중에 바꿀 수 없는 것은?
- 벡터 크기와 거리 함수 — 이후 들어오는 벡터는 그 크기여야 하고 거리는 바꿀 수 없다
- payload 스키마 전체 — 선언하지 않은 키는 저장이 거부된다
- 점의 최대 개수 — 넘으면 오래된 점부터 지워진다
- 질의당 ef_search — 컬렉션 단위로 고정되어 질의마다 바꿀 수 없다
다음 중 전용 벡터 DB 없이 pgvector 로 충분한 상황은?
- 벡터 검색이 서비스의 중심이고 필터가 까다로운 수천만 건일 때
- 수십만 건에 조건이 단순하고 이미 PostgreSQL 을 운영하고 있어 새 시스템의 비용이 더 클 때
- 트랜잭션이 필요 없고 벡터를 자주 통째로 갈아 끼울 때
- gRPC 로만 접근해야 하는 클라이언트가 많을 때