Turbopuffer tái cấu trúc lõi lưu trữ: Khi cơ sở dữ liệu vector không còn xoay quanh vector

Cơ sở dữ liệu vector từng là "ngôi sao" của làn sóng AI, nhưng có lẽ đã đến lúc chúng ta phải nhìn lại vị trí thực sự của nó trong kiến trúc hệ thống. Turbopuffer — nền tảng được Cursor và Notion tin dùng — vừa công bố bước ngoặt lớn: thay đổi tận gốc kiến trúc lưu trữ, biến chỉ mục vector từ "trung tâm vũ trụ" thành một thành phần phụ bình thường.

Từ "chỉ mục vector là tất cả" đến một cơ sở dữ liệu tổng quát

Turbopuffer khởi đầu như một cơ sở dữ liệu vector serverless, chuyên biệt hóa cao độ cho bài toán tìm kiếm vector rẻ và đủ nhanh. Triết lý thiết kế rất rõ ràng: dùng lưu trữ đối tượng (object storage) làm nguồn sự thật để có chi phí kinh tế, kết hợp bộ đệm phân tầng NVMe SSD/bộ nhớ để có hiệu năng. Nhờ đó, họ phục vụ được các chỉ mục đơn lẻ với hơn 100 tỷ vector, đạt độ trễ p99 khoảng 200 ms ở mức 1.000+ truy vấn mỗi giây.

Nhưng theo thời gian, nhu cầu của khách hàng mở rộng: lọc theo thuộc tính, tìm kiếm toàn văn BM25, tổng hợp dữ liệu, tìm kiếm regex, khớp mờ, tìm kiếm vector thưa... Tất cả đều được xây dựng xoay quanh cùng một bố cục lưu trữ lấy vector làm gốc.

"Chúng tôi đã đẩy chỉ mục ANN chính đến giới hạn tối đa, nhưng đã đến lúc phải bước tiếp. Chúng tôi đang chuyển sang một chỉ mục chính mới, và biến ANN thành một chỉ mục phụ bình thường."

Ba vấn đề nhức nhối của kiến trúc cũ

Điểm mấu chốt nằm ở cách tổ chức dữ liệu: mọi thứ trong tài liệu — vector, thuộc tính, chỉ mục nghịch đảo — đều được đánh khóa theo "địa chỉ ANN" (tổ hợp ClusterId và LocalId, ví dụ C0L1). Cách này hoạt động rất tốt cho tìm kiếm vector, nhưng lại kìm hãm mọi truy vấn phi vector khác.

Ba hệ quả cụ thể:

• Khuếch đại lưu trữ: khi một tài liệu có nhiều vector (ví dụ biểu diễn lồng nhau hoặc late interaction), nội dung tài liệu phải bị sao chép cho từng vector. Đây là nguyên nhân dẫn đến nhiều giới hạn đáng tiếc của hệ thống.
• Khuếch đại ghi: mỗi khi thêm, sửa hay xóa tài liệu, thuật toán SPFresh có thể tái cân bằng cluster vector. Vì toàn bộ tài liệu và chỉ mục nghịch đảo đều gắn với địa chỉ ANN, việc cập nhật một vector có thể kéo theo hàng trăm thuộc tính và chỉ mục phải di chuyển theo. Nỗ lực tối ưu thông lượng đánh chỉ mục vì thế đã bắt đầu chạm ngưỡng hiệu suất giảm dần.
• Giới hạn vector hóa: các engine truy vấn hiện đại chạy theo lô (batch) để tận dụng SIMD và giữ CPU luôn bận. DuckDB xử lý theo lô 2.048 dòng, ClickHouse lên tới ~65.000, khối posting của Lucene là 256 tài liệu — trong khi chỉ mục ANN của turbopuffer chỉ hiệu quả với cluster 100–200 tài liệu. Mọi kế hoạch truy vấn đều bị "trói" vào kích thước cluster, dù chúng muốn khối lớn hơn nhiều.

Bài học từ chính full-text search

Turbopuffer đã từng chứng minh vấn đề này quan trọng đến mức nào. Phiên bản full-text search đầu tiên phân vùng danh sách posting theo ranh giới cluster ANN, khiến khối trung vị chỉ chứa ~1,5 posting. Khi FTS v2 tái cấu trúc posting thành khối cố định ~256, chỉ mục nhỏ đi 10 lần và truy vấn nhanh hơn tới 20 lần.

Điểm mấu chốt: danh sách posting làm được điều đó vì chúng được lưu riêng và trỏ tới tài liệu, nên bố cục không buộc phải theo cluster. Trong khi đó, các truy vấn tổng hợp và quét dữ liệu đọc trực tiếp tài liệu — vốn được lưu mỗi cluster một khối — nên mãi bị giới hạn ở kích thước cluster.

turbopuffer v3: giải pháp và lộ trình

Giải pháp được tóm gọn trong một câu: đừng đánh khóa theo địa chỉ ANN nữa. Đó chính xác là thay đổi mà turbopuffer v3 thực hiện — và như có thể hình dung, đây không phải thay đổi nhỏ.

Cột mốc gần đây nhất: 100% bài kiểm tra CI đã chạy qua trên turbopuffer v3. Tuy nhiên, phiên bản mới hiện vẫn chậm hơn đáng kể so với bản production. Đội ngũ cho biết họ mới chỉ tập trung vào thiết kế nền tảng và tính đúng đắn, và giờ mới bắt đầu quá trình tinh chỉnh hiệu năng — một quá trình mà họ gọi vui là "mài hiệu năng từ ngày số 0".

Theo lộ trình, turbopuffer sẽ công bố kết quả benchmark dần theo từng bước, đồng thời đi sâu vào chi tiết kiến trúc mới và các tối ưu hóa nhằm đưa hệ thống vượt qua chính bản production hiện tại.

Ý nghĩa với cộng đồng phát triển tại Việt Nam

Đối với các đội ngũ xây dựng ứng dụng AI tại Việt Nam — đặc biệt là các startup làm RAG, chatbot hay tìm kiếm ngữ nghĩa — câu chuyện này mang theo vài gợi ý thực tế:

• Vector không phải là tất cả. Khi hệ thống lớn dần, nhu cầu lọc thuộc tính, tìm kiếm từ khóa và tổng hợp dữ liệu sẽ xuất hiện, và kiến trúc lấy vector làm trung tâm có thể trở thành gánh nặng.
• Lựa chọn lưu trữ đối tượng là hợp lý về chi phí, nhưng cần cân nhắc kỹ trade-off về khuếch đại ghi nếu dữ liệu có tần suất cập nhật cao.
• Đừng đánh giá thấp bài toán kích thước khối trong truy vấn. Sự khác biệt giữa khối 200 và khối 2.048 phần tử có thể tạo ra chênh lệch hiệu năng lên tới hàng chục lần.

Turbopuffer hiện vận hành hơn 1.000 tỷ tài liệu, xử lý hơn 10 triệu lượt ghi mỗi giây và phục vụ hơn 25.000 truy vấn mỗi giây. Với v3, họ kỳ vọng sẽ mở rộng được nhiều dạng truy vấn hơn nữa ở quy mô lớn hơn — dấu hiệu cho thấy kỷ nguyên "cơ sở dữ liệu vector" đang dần nhường chỗ cho thế hệ cơ sở dữ liệu tìm kiếm đa năng.