[Qdrant] 성능 최적화, 팁

Qdrant 기술지원팀과 이래저래 이야기도 해보고 이것저것 하면서 체득한 부분들을 정리해본다.

Scroll API

Scroll API는 문서상에는 잘 써있진 않지만, 권장되지는 않는 기능이다.
리소스를 과다하게 소모하고, 시스템에 큰 부하를 줄 수 있다.

그래서 일회성, 혹은 간헐적인 마이그레이션 등에만 쓸만하고, 실시간 서비스를 구현할 때는 되도록이면 쓰지 않는 것이 바람직하다.

Payload Index

난 payload index가 elasticsearch처럼 필터링에 최적화된 column base 인덱스인줄 알았는데, 기술팀과 이야기해보니까 그거랑은 좀 다르다고 하더라.
인덱스를 만드는 방식이 필드마다 하나씩이라서 컬럼별 인덱스 먼저 빠르게 로드하고 교집합 처리하는줄 알았지만, 인덱스 통계 기반으로 인덱스를 선택하는 고전적인 방식을 취한다고 한다.
인덱스 있다고 무조건 다 쓰는 것이 아니다.

그래서 벡터 없이 Elasticsearch의 빠른 필터링 대안으로 써보려고 했지만, 적합하지는 않았다.

Connection Option

프로토콜은 HTTP/gRPC를 제공하는데, 실제 프로덕션 시스템에서는 gRPC를 권장한다.
그리고 Qdrant Cloud를 사용하는 경우에는 Cloud 전용 커넥션 플래그를 제공한다.

커넥션 관리 능력이 현재로서는 그렇게 좋지는 않은 것 같다.
RDB들처럼 커넥션 수백 수천개 물려서 쓰는건 거의 불가능하고, 커넥션 개수 선택에 대한 권장사항이 없다.
스펙에 따라서 조정해야한다고만 하더라.

내가 경험하기론 vCPU 2개, 16gb 기준으로도 감당이 잘 되는 커넥션 풀 개수가 3-4개 정도고, 그 이상을 넘어서니까 처리량에 문제가 생기고 오류율이 급증했다.

인덱스 구성과 CPU Load

Qdrant는 쓰기 동작이 무거운 편이 속하는 DB다.
특히 벡터 인덱스를 구성하는 부분은 CPU에 큰 부하를 줄 수 있다.

인덱스 구성에 따른 CPU 스파이크

그래서 너무 자주 돌리지 않고, 되도록이면 사용량이 적은 시간에 적당히 분산해서 돌리는 것이 좋다.

스냅샷 로드

스냅샷 업로드는 기능이 좀 불안정한 편에 속하는 것 같다.
적당히 작은 크기의 컬렉션을 옮기는 데는 유용하지만, 컬렉션 크기가 몇기가를 넘어서면 실패할 확률이 매우 높아지고, 그냥 불가능할 수도 있다.

사이즈가 크면 그냥 마이그레이션 코드를 직접 작성하는 편이 낫다.