EzyVector có sử dụng bộ nhớ, nhưng không theo cách “load toàn bộ vector data vào Java heap” để tìm kiếm. Thiết kế của EzyVector tách dữ liệu thành nhiều lớp: MySQL lưu metadata và payload, filesystem lưu vector data và HNSW index, còn RAM chủ yếu được dùng cho chỉ mục HNSW, buffer xử lý tạm thời và page cache của hệ điều hành.
Điểm quan trọng là: EzyVector không cố giữ toàn bộ vector storage trong Java object memory. Vector data được ghi xuống file và có thể đọc theo chunk khi cần fallback search. Khi HNSW index sẵn sàng, hệ thống dùng RAM để giữ cấu trúc index nhằm tìm kiếm nhanh hơn.

Bộ Nhớ Được Dùng Ở Đâu?

Có ba phần chính cần hiểu khi nói về bộ nhớ trong EzyVector.
flowchart TD
    A[EzyVector] --> B[Java Heap]
    A --> C[Filesystem]
    A --> D[OS Page Cache]

    B --> B1[HNSW index khi đã load]
    B --> B2[Batch xử lý tạm thời]
    B --> B3[Request/response object]

    C --> C1[Vector data]
    C --> C2[Point id mapping]
    C --> C3[HNSW index file]

    D --> D1[Cache dữ liệu file được đọc gần đây]
Java heap dùng cho service runtime, batch khi upsert/backfill/build index, và đặc biệt là HNSW index khi index được load.
Filesystem lưu vector data, point id mapping và file HNSW index. Đây là nơi chứa dữ liệu bền vững, không phải toàn bộ đều nằm trong heap.
OS page cache là bộ nhớ do hệ điều hành dùng để cache file đã đọc. Khi EzyVector scan vector storage, hệ điều hành có thể cache một phần dữ liệu file để lần đọc sau nhanh hơn.

Vector Data Có Tốn RAM Không?

Vector data được lưu trên filesystem. Khi upsert point, EzyVector ghi vector xuống file storage. Khi search fallback, hệ thống có thể đọc vector theo chunk thay vì biến toàn bộ collection thành một map lớn trong Java heap.
Ví dụ một collection có:
  • 1.000.000 vector,
  • mỗi vector có 1.536 chiều,
  • mỗi chiều là float32, tức 4 bytes.
Dung lượng raw vector data là: 
1.000.000 * 1.536 * 4 bytes
= 6.144.000.000 bytes
≈ 5,72 GiB
Nếu load toàn bộ số vector này thành object Java, bộ nhớ thực tế còn lớn hơn vì có thêm object overhead, array overhead, map/hash table, metadata và áp lực GC.
EzyVector tránh mô hình này bằng cách lưu vector data trên file. Khi cần scan, hệ thống đọc theo vùng dữ liệu thay vì giữ toàn bộ raw vector data trong Java heap.

HNSW Index Có Tốn RAM Không?

Có. HNSW index là phần tiêu tốn RAM đáng kể nhất khi collection lớn.
HNSW không chỉ lưu danh sách vector. Nó còn lưu cấu trúc đồ thị tìm kiếm, gồm:
  • node id,
  • vector đã chuẩn hóa,
  • level của node,
  • danh sách neighbor ở từng tầng,
  • entry point,
  • các cấu trúc phụ trợ để tìm kiếm.
Vì vậy, khi HNSW index được load để search nhanh, RAM sẽ tăng theo số lượng point và kích thước vector.
Ví dụ với 100.000 vector, mỗi vector 1.536 chiều:
100.000 * 1.536 * 4 bytes
= 614.400.000 bytes
≈ 586 MiB
Đây mới chỉ là phần raw vector trong index. HNSW còn cần thêm bộ nhớ cho graph neighbor, node object, collection object và overhead của JVM. Vì vậy RAM thực tế sẽ lớn hơn con số raw này.
Với 1.000.000 vector cùng kích thước:
1.000.000 * 1.536 * 4 bytes
≈ 5,72 GiB raw vector
Nếu HNSW index cho 1 triệu vector được load vào RAM, bạn cần chuẩn bị nhiều hơn 5,72 GiB vì index còn chứa graph và overhead. Đây là trade-off bình thường của vector search: muốn tìm kiếm nhanh thì cần bộ nhớ cho chỉ mục.

Vì Sao Không Load Tất Cả Vector Vào RAM?

Nếu lưu toàn bộ vector trong RAM theo kiểu đơn giản, ví dụ Map<pointId, float[]>, hệ thống sẽ gặp nhiều vấn đề:
  • startup chậm vì phải load dữ liệu lớn,
  • request đầu tiên chậm nếu lazy load,
  • Java heap phình to,
  • GC nặng,
  • khó chạy trên server tài nguyên vừa phải,
  • khó kiểm soát khi collection tăng nhanh.
EzyVector chọn cách an toàn hơn: vector data nằm trên filesystem, HNSW index chỉ được dùng như lớp tăng tốc tìm kiếm. Khi index chưa sẵn sàng, hệ thống vẫn có thể fallback sang scan vector storage. 
flowchart TD
    A[Search request] --> B{HNSW index sẵn sàng?}
    B -->|Có| C[Tìm nhanh bằng HNSW trong RAM]
    B -->|Không| D[Scan vector storage theo chunk]
    C --> E[Lấy payload từ MySQL]
    D --> E
    E --> F[Trả kết quả]

Ví Dụ Với Website Nhỏ

Giả sử một website có 20.000 bài viết, mỗi bài viết có một embedding 768 chiều.
Raw vector data:
20.000 * 768 * 4 bytes
= 61.440.000 bytes
≈ 58,6 MiB
Với quy mô này, vector storage khá nhỏ. HNSW index cũng có thể chạy nhẹ trên một server phổ thông. Đây là nhóm use case rất phù hợp cho semantic search, chatbot nội bộ hoặc RAG trên một website vừa và nhỏ.

Ví Dụ Với Website Trung Bình

Giả sử một hệ thống có 200.000 đoạn nội dung, mỗi đoạn có embedding 1.536 chiều.
Raw vector data:
200.000 * 1.536 * 4 bytes
= 1.228.800.000 bytes
≈ 1,14 GiB
Vector data trên filesystem khoảng hơn 1 GiB, chưa tính point id mapping và file index. Nếu dùng HNSW, RAM cần cho index sẽ lớn hơn phần raw vector vì còn có graph neighbor và overhead.
Ở quy mô này, EzyVector vẫn hợp lý, nhưng nên cấu hình heap và RAM server cẩn thận. Ví dụ server 8-16 GiB RAM sẽ thoải mái hơn so với server chỉ có 2 GiB RAM.

Ví Dụ Với Collection Lớn

Giả sử một collection có 1.000.000 đoạn nội dung, mỗi vector 1.536 chiều.
Raw vector data:
1.000.000 * 1.536 * 4 bytes
≈ 5,72 GiB
Nếu chỉ scan file, hệ thống không cần load toàn bộ raw vector vào heap, nhưng search sẽ chậm hơn HNSW. Nếu dùng HNSW để search nhanh, index cần nhiều RAM vì phải giữ vector và graph trong bộ nhớ.
Ở quy mô này, nên xem EzyVector như một thành phần cần sizing nghiêm túc: RAM, heap, dung lượng disk, tốc độ disk và số lượng collection đều ảnh hưởng đến hiệu năng.

Khi Nào RAM Tăng?

RAM có thể tăng trong các tình huống sau:
  • HNSW index được build hoặc load vào memory.
  • Có nhiều collection lớn được search và index cùng lúc.
  • Backfill đang chạy theo batch.
  • Upsert số lượng point lớn trong một request.
  • Fallback search đọc nhiều dữ liệu file, làm OS page cache tăng.
  • Query đồng thời nhiều, tạo thêm object tạm thời trong runtime.
Điều này không có nghĩa là EzyVector “ăn RAM vô hạn”. Nó có nghĩa là bộ nhớ tăng theo quy mô dữ liệu và chế độ tìm kiếm.

Trade-off Giữa RAM Và Tốc Độ

Có thể hiểu đơn giản:
  • Ít dùng RAM hơn: scan vector storage trên file, tiết kiệm heap hơn nhưng chậm hơn.
  • Search nhanh hơn: dùng HNSW index trong RAM, tốn RAM hơn nhưng độ trễ thấp hơn.
  • Dễ phục hồi hơn: giữ vector data và metadata riêng, có thể rebuild index khi cần.
Đây là trade-off cốt lõi của hầu hết hệ thống vector search. EzyVector không loại bỏ chi phí bộ nhớ, mà tổ chức nó theo cách dễ kiểm soát hơn.

Kết Luận

EzyVector có tốn bộ nhớ, đặc biệt khi sử dụng HNSW index để tìm kiếm nhanh. Tuy nhiên, EzyVector không load toàn bộ vector data vào Java heap theo kiểu đơn giản và nguy hiểm.
Thiết kế của EzyVector là:
  • MySQL lưu metadata và payload.
  • Filesystem lưu vector data và HNSW index file.
  • Java heap dùng cho runtime, batch xử lý và HNSW index khi cần search nhanh.
  • OS có thể dùng page cache khi đọc vector file.
Nói ngắn gọn:
> EzyVector vẫn cần RAM cho hiệu năng tìm kiếm, nhưng tránh việc nhồi toàn bộ vector storage vào Java heap. Vector data được lưu trên filesystem, còn RAM chủ yếu dành cho HNSW index và xử lý tạm thời.
Vì vậy, với website nhỏ và vừa, EzyVector có thể chạy gọn trong hạ tầng EzyPlatform hiện có. Với collection lớn hàng trăm nghìn hoặc hàng triệu vector, cần tính toán RAM và disk tương ứng, đặc biệt nếu muốn bật HNSW index để tìm kiếm nhanh.