Vector DB 5 — Các hệ vector database chuyên dụng

Vì sao (và khi nào) cần một vector DB chuyên dụng?

Ở Vector DB 4 — pgvector ta đã thấy Postgres + pgvector đủ dùng cho phần lớn dự án tìm kiếm ngữ nghĩa: dữ liệu, embedding và metadata nằm chung một database quen thuộc, transaction đầy đủ, đội DBA đã biết vận hành. Với kho vài triệu vector, một node Postgres tuned tốt hoàn toàn cân được. Vậy vì sao vẫn tồn tại cả một họ vector database chuyên dụng (Milvus, Qdrant, Weaviate, Pinecone...)?

Câu trả lời không phải "cái nào hiện đại hơn" mà là ngưỡng ràng buộc. Có bốn tín hiệu cho thấy nên cân nhắc tách sang vector DB riêng:

• Quy mô rất lớn: kho vượt vài chục triệu tới hàng trăm triệu, thậm chí hàng tỷ vector. pgvector chạy trên một node Postgres bị chặn bởi RAM/CPU của node đó; đồ thị HNSW cho 1 tỷ vector 1024 chiều không nhét vừa một máy. Vector DB chuyên dụng sharding dữ liệu ra nhiều node ngay từ thiết kế.
• Throughput/QPS cao: cần hàng nghìn truy vấn/giây với latency p99 ổn định. Postgres phục vụ vector song song với tải OLTP (giao dịch, báo cáo) sẽ tranh chấp tài nguyên; vector DB tối ưu riêng cho workload tìm kiếm.
• Tính năng vector nâng cao: filtered ANN hiệu quả, hybrid search (dense + sparse/BM25) tích hợp sẵn, nhiều loại quantization, multi-tenancy, versioning collection, replica đọc theo vùng. pgvector đang bắt kịp nhưng vẫn sau các engine chuyên dụng ở một số tính năng.
• Tách khỏi OLTP: nhiều tổ chức không muốn tải embedding/ANN nặng đè lên database giao dịch cốt lõi. Tách vector ra một hệ riêng giúp cô lập lỗi, scale độc lập, và không đụng tới SLA của core banking.

Ngược lại, nếu kho dưới ~vài triệu vector, QPS vừa phải, và bạn đã có Postgres, thì đừng vội thêm một hệ phân tán mới — chi phí vận hành (một cluster nữa để giám sát, backup, vá lỗi) thường lớn hơn lợi ích. Nguyên tắc: bắt đầu với pgvector, chỉ chuyển khi chạm trần thật sự.

Kiến trúc chung của một vector DB chuyên dụng

Dù mỗi sản phẩm khác nhau, các vector DB "cỡ lớn" chia sẻ một số nguyên tắc kiến trúc chung — hiểu chúng giúp so sánh và vận hành tốt hơn.

Tách compute và storage

Các hệ hiện đại (điển hình Milvus) tách tầng tính toán (query/index node) khỏi tầng lưu trữ (object storage như S3/MinIO cho segment, message queue cho log ghi). Lợi ích: scale phần tìm kiếm độc lập với dung lượng lưu trữ, node compute stateless dễ thay/thêm, và dữ liệu bền vững nằm ở object storage rẻ. Ngược lại, các hệ gọn nhẹ hơn (Qdrant, pgvector) thường gắn liền compute–storage trên cùng node — đơn giản vận hành hơn nhưng scale kém linh hoạt hơn.

Sharding & replication cho quy mô tỷ vector

• Sharding (phân mảnh): chia collection thành nhiều shard, mỗi shard giữ một phần vector, đặt trên các node khác nhau. Truy vấn được fan-out tới mọi shard rồi gộp (merge) top-k lại. Đây là cách vượt trần một-node để tới quy mô tỷ.
• Replication (nhân bản): mỗi shard có nhiều bản sao để (1) chịu lỗi khi mất node và (2) chia tải đọc, tăng QPS. Ghi đi vào replica chính rồi đồng bộ sang bản sao.

Index ANN tối ưu

Mọi vector DB đều dựa trên các thuật toán ANN đã trình bày ở Vector DB 3 — ANN & chỉ mục: HNSW (mặc định cho recall/latency tốt) và họ IVF / IVF-PQ (cho kho khổng lồ, nén để tiết kiệm RAM). Khác biệt giữa các sản phẩm nằm ở: cài đặt được tối ưu ở tầng thấp (SIMD, Rust/C++), số loại index hỗ trợ, và mức độ tinh chỉnh tham số (M, ef_search, nlist, nprobe).

Metadata filtering hiệu quả

Điểm phân biệt lớn giữa các engine là filtered ANN: lọc theo metadata (phòng ban, ngày, trạng thái) ngay trong lúc duyệt đồ thị/cụm thay vì post-filter thô. Qdrant nổi tiếng mạnh về mảng này nhờ payload index; Milvus, Weaviate, pgvector 0.8+ cũng hỗ trợ. Filtering tốt tránh được bẫy "top-N không đủ k sau lọc" đã bàn ở Vector DB 3.

Quantization giảm bộ nhớ

HNSW ngốn RAM vì đồ thị và vector phải nằm trong bộ nhớ. Quantization (lượng tử hoá) nén vector để nhét được nhiều hơn, đổi lại recall giảm nhẹ:

• Scalar quantization (SQ): nén mỗi chiều float32 (4 byte) xuống int8 (1 byte) → giảm ~4× RAM, mất recall rất ít. Lựa chọn mặc định an toàn.
• Product quantization (PQ): chia vector thành đoạn con, mỗi đoạn thay bằng chỉ số centroid (xem Vector DB 3) → nén tới hàng chục lần, cho kho tỷ vector, đánh đổi recall nhiều hơn.
• Binary quantization (BQ): nén mỗi chiều xuống 1 bit (dấu), giảm ~32×, tính khoảng cách bằng Hamming cực nhanh — hợp một số embedding chịu được (thường kèm re-ranking bằng vector gốc để bù recall).

Chiến lược phổ biến: giữ vector nén trong RAM để lọc thô nhanh, rồi re-score một tập nhỏ ứng viên bằng vector gốc (đọc từ disk/storage) để phục hồi độ chính xác.

Điểm qua & so sánh các lựa chọn

Milvus / Zilliz

Milvus (mã nguồn mở, Apache 2.0) là vector DB phân tán "hạng nặng": kiến trúc tách compute/storage, nhiều loại index (HNSW, IVF-*, DiskANN, GPU index), scale tới hàng tỷ vector. Đổi lại vận hành phức tạp — cluster gồm nhiều thành phần (coordinator, query/data/index node, etcd, object storage, message queue). Zilliz Cloud là bản managed của Milvus. Phù hợp khi quy mô thật sự lớn và có đội hạ tầng đủ mạnh.

Qdrant

Qdrant (mã nguồn mở, viết bằng Rust) nổi bật ở filtering mạnh (payload index), hiệu năng tốt, và dễ vận hành hơn Milvus (một binary gọn, ít thành phần phụ trợ). Hỗ trợ quantization (scalar/product/binary), hybrid, distributed mode. Là lựa chọn cân bằng rất tốt cho đội vừa và nhỏ muốn self-host mà không gánh cluster nặng.

Weaviate

Weaviate (mã nguồn mở) đi theo hướng schema hoá dữ liệu (class + property), hỗ trợ hybrid search (dense + BM25) sẵn, và hệ module để cắm sẵn mô hình embedding, reranker, generative (RAG). Tốt khi muốn một hệ "trọn gói" gần với ứng dụng, ít phải ghép nhiều mảnh.

Pinecone

Pinecone là SaaS quản lý hoàn toàn (fully managed) — không có bản self-host. Bạn chỉ gọi API, nhà cung cấp lo hạ tầng, scale, HA. Cực nhanh để khởi động, vận hành nhẹ nhất. Nhược điểm với ngân hàng: dữ liệu rời khỏi hạ tầng nội bộ — thường là điểm chặn về tuân thủ.

Vespa

Vespa (mã nguồn mở, từ Yahoo) là engine tìm kiếm/serving quy mô lớn, mạnh về kết hợp ranking phức tạp (tensor, ML ranking, hybrid) và low-latency ở tải rất cao. Đường học dốc, cấu hình nặng — hợp bài toán search/recsys lớn hơn là "chỉ vector".

Chroma

Chroma là vector store nhẹ, hướng developer, chạy embedded/local rất nhanh để prototyping và ứng dụng RAG nhỏ. Không nhắm tới quy mô tỷ vector hay HA production nặng — nhưng tuyệt cho giai đoạn thử nghiệm (xem LLM 4 — RAG).

Đã có sẵn hạ tầng: pgvector & Elasticsearch/OpenSearch kNN

• pgvector: nếu đã có Postgres, đây là điểm khởi đầu mặc định (xem Vector DB 4).
• Elasticsearch / OpenSearch kNN: nếu tổ chức đã vận hành ES/OpenSearch cho log/tìm kiếm văn bản, cả hai đều có kNN vector (dựa HNSW) và hybrid dense+BM25 sẵn. Tận dụng hạ tầng và kỹ năng hiện có, khỏi thêm hệ mới — xem Elasticsearch — Tổng quan.

Bảng so sánh

(Bảng mang tính định hướng; con số quy mô phụ thuộc phần cứng, chiều vector, index và quantization.)

Tiêu chí chọn — nhìn từ ngân hàng

Không có "engine tốt nhất", chỉ có phù hợp nhất với ràng buộc. Sáu tiêu chí cần cân:

1. Quy mô dữ liệu: dưới vài triệu → pgvector; hàng trăm triệu–tỷ → Milvus/Vespa; ở giữa → Qdrant/Weaviate/ES.
2. Độ trễ / QPS: cần p99 thấp ở tải cao, đọc song song lớn → hệ có replication đọc mạnh (Milvus, Vespa, Qdrant distributed).
3. Self-host on-prem vì tuân thủ: đây thường là ràng buộc cứng của ngân hàng — dữ liệu khách hàng, hồ sơ tín dụng không được rời hạ tầng nội bộ. Loại thẳng Pinecone (SaaS-only); ưu tiên OSS self-host: Milvus, Qdrant, Weaviate, pgvector, OpenSearch.
4. Chi phí: SaaS trả theo dung lượng/QPS (dễ đội khi kho lớn); self-host tốn phần cứng + nhân lực vận hành. Tính tổng chi phí sở hữu (TCO), không chỉ giá license.
5. Hệ sinh thái & kỹ năng sẵn có: đã có Postgres → pgvector; đã có ES/OpenSearch → kNN của nó; muốn tối giản cluster mới → Qdrant.
6. Filtering / hybrid cần thiết: filter nặng theo phòng ban/hiệu lực → Qdrant; cần hybrid dense+lexical sẵn → Weaviate/OpenSearch (xem Vector DB 6 — Hybrid Search).

Kết luận điển hình cho NCB: vì tuân thủ, chọn nền tảng vector self-host giữ toàn bộ dữ liệu trong nội bộ. Với quy mô vài triệu tới vài chục triệu chunk và đội đã quen Postgres, pgvector là lựa chọn khởi đầu; khi chạm trần (quy mô/QPS/filtering) thì Qdrant self-host là bước tiến hợp lý (dễ vận hành, filtering mạnh), còn Milvus dành cho khi thật sự tới quy mô tỷ vector.

Các khái niệm vận hành cần nắm

Dù chọn engine nào, một số khái niệm lặp lại (tên gọi khác nhau):

• Collection: đơn vị chứa vector cùng chiều và schema metadata (tương đương "bảng"). Trong pgvector là một bảng có cột vector.
• Namespace / partition / tenant: chia logic bên trong collection để cô lập dữ liệu theo nhóm (ví dụ mỗi phòng ban một namespace) — hữu ích cho multi-tenancy và tăng tốc filter.
• Upsert: ghi vector kèm id và payload; nếu id đã tồn tại thì cập nhật, chưa có thì chèn. Là thao tác ghi chuẩn của vector DB (không phân biệt insert/update như SQL).
• Filter: điều kiện metadata áp lên truy vấn ANN (ví dụ department = 'TinDung' AND active = true).
• Consistency: mức nhất quán giữa ghi và đọc. Nhiều vector DB phân tán mặc định eventual consistency (vector vừa upsert có thể chưa hiện ngay trong kết quả tìm) — khác với ACID của Postgres. Cần biết để không kỳ vọng đọc-thấy-ngay như OLTP.

Ví dụ API minh hoạ (KHÔNG phải SQL chạy được — pseudocode client vector DB):

# Minh hoạ (KHÔNG phải SQL chạy được) — tạo collection, upsert, tìm có filter
client.create_collection(
    name="quy_trinh_noi_bo",
    dim=1024, metric="cosine",
    index={"type": "HNSW", "M": 32, "ef_construct": 200},
    quantization="scalar",          # int8, giảm ~4x RAM
)

client.upsert("quy_trinh_noi_bo", points=[
    {"id": "doc-102-chunk-7",
     "vector": embed("Điều kiện giải ngân khoản vay tín chấp..."),
     "payload": {"department": "TinDung", "active": True, "lang": "vi"}},
])

hits = client.search(
    "quy_trinh_noi_bo",
    query_vector=embed("hồ sơ giải ngân cần giấy tờ gì"),
    k=10, ef_search=80,
    filter={"must": [{"department": "TinDung"}, {"active": True}]},
)

Để so sánh, cùng ý tưởng truy vấn trong pgvector là một câu SELECT thật (chi tiết ở Vector DB 4):

-- Minh hoạ pgvector (KHÔNG chạy trong sandbox — sandbox không có bảng chunks/vector)
SELECT id, content
FROM chunks
WHERE department = 'TinDung' AND active
ORDER BY embedding <=> $1     -- <=> là cosine distance của pgvector
LIMIT 10;

Use case thực tế

Bối cảnh: Trợ lý tra cứu nội bộ NCB (đã dựng ở Vector DB 3) đang chạy trên pgvector với 5,2 triệu chunk, p95 ~11ms, phục vụ ~150 QPS/node — ổn. Sau một năm, kho phình lên 90 triệu chunk (thêm email nghiệp vụ, ticket, biên bản), QPS mục tiêu 1.200, và yêu cầu filter phức tạp hơn (phòng ban × loại tài liệu × thời hạn hiệu lực). Một node Postgres bắt đầu chạm trần RAM và tranh chấp với tải báo cáo.

Đánh giá lựa chọn:

• Pinecone bị loại ngay: dữ liệu hồ sơ khách hàng không được rời hạ tầng nội bộ (ràng buộc tuân thủ).
• Milvus: đủ sức nhưng cluster nặng (etcd, MinIO, nhiều loại node) — quá mức cần thiết cho 90 triệu vector, tốn nhân lực vận hành.
• Qdrant self-host được chọn: filtering mạnh (đúng nhu cầu filter đa chiều), vận hành nhẹ (một binary + distributed mode), hỗ trợ scalar quantization giảm RAM ~4×.

Triển khai: 3 node Qdrant, collection docs chia 6 shard, replica = 2 (chịu mất 1 node). Bật scalar quantization (int8) → vector từ ~360 GB float32 nén còn ~90 GB, đủ nằm RAM cụm; cấu hình re-score top-100 bằng vector gốc để giữ recall. Index HNSW M=32, ef_search=100. Payload index trên department, doc_type, valid_until để filtered search nhanh.

Kết quả (đo được sau tuning): recall@10 ≈ 0,98, p95 ~14ms ở 1.200 QPS, tách hẳn tải khỏi Postgres OLTP. Dữ liệu giữ toàn bộ on-prem, đạt yêu cầu tuân thủ. Postgres vẫn giữ vai trò nguồn sự thật (source of truth) cho nội dung gốc; Qdrant chỉ phục vụ tìm kiếm — đồng bộ qua pipeline upsert.

Ghi nhớ

• Bắt đầu với pgvector, chỉ chuyển sang vector DB chuyên dụng khi chạm trần thật: quy mô rất lớn (tỷ vector), QPS cao, filtering/hybrid nâng cao, hoặc cần tách khỏi OLTP.
• Kiến trúc vector DB lớn: tách compute/storage, sharding (fan-out + merge top-k) và replication cho quy mô tỷ + HA; index HNSW / IVF-PQ; filtered ANN; quantization giảm RAM.
• Quantization: scalar (int8, ~4×, mất ít recall — mặc định an toàn), product (nén mạnh cho tỷ vector), binary (~32×, kèm re-rank).
• So sánh nhanh: Milvus (tỷ vector, vận hành nặng), Qdrant (Rust, filtering mạnh, dễ vận hành), Weaviate (schema + hybrid + module), Pinecone (SaaS, không self-host), Vespa (ranking/hybrid lớn), Chroma (nhẹ, cho dev), pgvector / ES-OpenSearch kNN (tận dụng hạ tầng sẵn có).
• Ngân hàng: tuân thủ thường buộc self-host on-prem — loại Pinecone; ưu tiên OSS self-host (pgvector → Qdrant → Milvus theo quy mô).
• Khái niệm vận hành: collection, namespace, upsert, filter, consistency (nhiều hệ eventual consistency — vector vừa upsert có thể chưa hiện ngay).
• Chọn theo ràng buộc: quy mô, latency/QPS, self-host, chi phí (TCO), hệ sinh thái sẵn có, filtering/hybrid cần thiết — không có "engine tốt nhất" tuyệt đối.