VectorDB #1 (production usage)

OpenSearch based Faiss HNSW 인덱싱

• 벡터 인덱싱 시 그래프 구조가 디스크에 저장되며, 검색 시 메모리에 적재되는 방식 확인
• 인덱싱 및 검색 시 파라미터가 메모리 사용량과 검색 성능(latency, accuracy) 직접적인 영향을 미침을 확인함
  • m: 각 노드가 유지하는 연결(edge)의 수 → 높을수록 recall 상승, 메모리 사용 증가
  • ef_construction: 인덱싱 시 그래프 탐색 폭 → 인덱스 정확도 상승, 인덱싱 시간 증가
  • ef_search: 검색 시 탐색 범위 → 높을수록 정확도 상승, latency 증가
  • dimension: 그래프 노드에 해당 벡터 값 저장 -> 높을수록 메모리 사용량 증가
• 인덱싱 파라미터 (m, dimension) 가 메모리 사용량에 미치는 영향 분석
  • 노드 하나당 메모리 사용량 근사 : (d * 4 + M * 2 * 4) bytes
  • d(Dimension size) * 4(float type size)
  • M(neigbor count) * 2(bidirectional edge) * 4(node address size)
  • d = 1024, M = 16, nodes: 1.7M
    • (1024 * 4 + 16 * 4 * 2) * 1.7M (bytes) ~= 7.1808 GB

Production 환경에서 vector DB serving시, 고려해야하는 요소 확인

• 실서비스 환경에서의 주요 고려 사항 파악
  • 벡터 인덱스의 메모리 상주 여부
    Faiss HNSW 알고리즘의 경우 그래프 정보만을 메모리상에 올려놓고 search 진행
  • production 샤딩 전략 및 부하 분산
    production 환경에서는 고가용성을 보장하기 위해, 멀티노드 샤딩 전략을 사용
    최소한의 가용성을 보장하기 위해 shard count = node count , replica = 1을 사용
    
    

replica에도 primary shard의 index 정보를 copy하기에 knn index 메모리를 두배로 사용

(alwaysLoadKnnIndex default true)

 

실제 production 환경(1.7M vectors, 1024 dimension) 총 indexing memory만 15GB 필요

• Document embedding시 chuncking
  • embedding model의 input size 및 맥락을 위해 문서를 쪼개는 chunking 과정 진행
  • 때문에 하나의 문서당 여러개의 벡터로 표현 -> vector 갯수 증가 -> 메모리 사용 증가