Vì Sao Không Tự Lưu Tất Cả Dữ Liệu?

Một vector database thường phải quản lý nhiều loại dữ liệu khác nhau:
  • metadata của collection,
  • thông tin từng point,
  • payload đi kèm point,
  • trạng thái active/live/deleted,
  • version,
  • thời gian tạo/cập nhật,
  • tiến trình build index,
  • dữ liệu vector thực tế,
  • cấu trúc index phục vụ tìm kiếm.
Nếu tự tổ chức toàn bộ cơ chế lưu trữ riêng, EzyVector sẽ phải giải quyết lại rất nhiều bài toán mà MySQL đã làm ổn định trong nhiều năm: transaction, index dữ liệu có cấu trúc, truy vấn phân trang, backup, restore, migration schema, durability và tooling vận hành.
Với mục tiêu là một plugin gọn nhẹ cho EzyPlatform, cách hợp lý hơn là tận dụng MySQL làm nền tảng dữ liệu có cấu trúc, còn EzyVector tập trung vào phần khác biệt nhất: lưu vector, build index và tìm kiếm tương đồng.

MySQL Là Source Of Truth Cho Metadata Và Payload

Trong EzyVector, MySQL giữ vai trò nguồn dữ liệu đáng tin cậy cho collection và point.
Collection lưu các thông tin như tên, kích thước vector, distance metric, loại index, trạng thái và số lượng point. Point lưu id, payload, version, trạng thái và vector gốc. Segment lưu metadata về cách dữ liệu vector được tổ chức.
Điều này giúp hệ thống có thể trả lời các câu hỏi vận hành rất tự nhiên:
  • Collection này đang active không?
  • Vector size là bao nhiêu?
  • Point này thuộc collection nào?
  • Payload của kết quả tìm kiếm là gì?
  • Có bao nhiêu point trong collection?
  • Segment hiện tại đang ở trạng thái nào?
Những dữ liệu này có tính quan hệ rõ ràng, rất phù hợp với MySQL.

Vector Storage Được Tách Riêng

Vector embedding có đặc điểm khác metadata thông thường. Một vector có thể gồm hàng trăm hoặc hàng nghìn số thực. Nếu có hàng triệu vector, tổng dung lượng sẽ rất lớn.
Nếu tải toàn bộ vector vào Java heap, bộ nhớ sẽ tăng nhanh và tạo áp lực lớn cho GC. Nếu truy vấn toàn bộ vector trực tiếp từ MySQL ở mỗi lần search, độ trễ cũng không phù hợp cho tìm kiếm ngữ nghĩa.
Vì vậy EzyVector tách vector storage sang file riêng trên filesystem. Vector được ghi theo slot, có mapping với point id, và có thể được scan theo từng chunk khi cần fallback search.
flowchart TD
    A[MySQL] --> A1[Collection metadata]
    A --> A2[Point metadata]
    A --> A3[Payload]
    A --> A4[Segment metadata]

    B[Filesystem] --> B1[Vector data]
    B --> B2[Point id mapping]
    B --> B3[HNSW index]
    B --> B4[Backfill progress]

    C[EzyVector Service] --> A
    C --> B
Cách tách này giúp mỗi lớp làm đúng việc của nó: MySQL quản lý dữ liệu có cấu trúc, filesystem chứa dữ liệu vector lớn và index phục vụ tìm kiếm.

Dễ Backup, Restore Và Quan Sát

Một lợi ích lớn của MySQL là hệ sinh thái vận hành đã rất quen thuộc. Người quản trị có thể backup database, kiểm tra dữ liệu, migration schema, truy vấn phân trang và tích hợp với admin dashboard.
Với EzyVector, admin plugin có thể hiển thị collection, point, segment, trạng thái, số lượng point, payload và cấu hình index nhờ metadata nằm trong MySQL. Nếu mọi thứ bị nhét vào một file binary riêng, việc quan sát và quản trị sẽ khó hơn nhiều.

Phục Hồi Và Backfill Dễ Hơn

Khi MySQL giữ dữ liệu point và vector gốc, EzyVector có thể rebuild phần file storage hoặc HNSW index khi cần. Đây là điểm quan trọng.
Nếu index bị thiếu, chưa sẵn sàng hoặc cần build lại, hệ thống có thể đọc point từ MySQL theo từng lô, ghi lại vector xuống storage và xây lại HNSW ở nền. Trong thời gian đó, hệ thống vẫn có thể fallback sang tìm kiếm tuần tự trên file storage khi HNSW chưa sẵn sàng.
sequenceDiagram
    participant DB as MySQL
    participant Service as EzyVector Service
    participant File as Vector Storage
    participant Index as HNSW Index

    Service->>DB: Đọc point theo từng lô
    Service->>File: Ghi lại vector storage
    Service->>Index: Insert vector vào HNSW
    Index->>File: Lưu index sau khi build xong
Cơ chế này làm cho hệ thống dễ phục hồi hơn so với việc toàn bộ dữ liệu chỉ tồn tại trong một engine riêng.

Giảm Độ Phức Tạp Khi Tích Hợp Với EzyPlatform

EzyPlatform đã có hệ thống cấu hình, admin, phân quyền, database và plugin lifecycle. Khi EzyVector dùng MySQL cho metadata, nó đi theo luồng vận hành quen thuộc của platform.
Điều này giúp plugin dễ cài đặt, dễ quản trị và dễ tích hợp với các module khác. Các ứng dụng không cần học thêm một mô hình vận hành hoàn toàn mới chỉ để lưu metadata của vector.

Vì Sao Không Chỉ Dùng MySQL?

MySQL rất tốt cho metadata và payload, nhưng không phải lựa chọn tối ưu nếu dùng một mình cho vector search hiệu năng cao.
Tìm kiếm vector yêu cầu tính toán similarity trên nhiều vector có chiều lớn. Nếu chỉ dựa vào truy vấn database thông thường, hệ thống khó đạt độ trễ tốt khi dữ liệu tăng. Vì vậy EzyVector không “chỉ dùng MySQL”, mà dùng MySQL ở nơi phù hợp và dùng vector storage/HNSW ở nơi cần tối ưu riêng.

Kết Luận

EzyVector sử dụng MySQL không phải vì muốn biến MySQL thành vector engine, mà vì MySQL là nền tảng vững chắc cho dữ liệu có cấu trúc, metadata, payload và khả năng vận hành.
Thiết kế này tạo ra sự cân bằng thực dụng:
  • MySQL lưu dữ liệu đáng tin cậy và dễ quản trị.
  • Filesystem lưu vector dung lượng lớn.
  • HNSW index tăng tốc tìm kiếm tương đồng.
  • Backfill giúp phục hồi và rebuild index khi cần.
  • Admin plugin có đủ metadata để quan sát hệ thống.
Nhờ đó, EzyVector có thể hoạt động như một vector database tích hợp cho EzyPlatform mà vẫn giữ kiến trúc đơn giản, dễ triển khai và dễ vận hành.