ADR 0005Chấp nhậnĐiều chỉnh một phần ADR 0015Bổ sung ADR 0014

ADR 0005: Chuỗi thời gian lưu trong TSDB (VictoriaMetrics) qua remote-write, không lưu trong MySQL

VictoriaMetrics nhận dữ liệu qua Prometheus remote-write. Bắt đầu single node, lên cluster khi cần.

Ngày quyết định

30/09/2026

Chấp nhận

30/09/2026

Phạm vi

Collector

Người chấp nhận

Chưa ghi

1. Đề xuất30/09/2026
2. Chấp nhận30/09/2026

Trạng thái: Chấp nhận, một phần bị điều chỉnh bởi ADR 0015 (ghi bằng /api/v1/import JSON thay cho remote-write; hiệu năng đã đo ở spike S3, xem ADR 0015 mục 6). Bổ sung bởi ADR 0014. Ngày: 2026-09-30.

Bối cảnh

Cần lưu hàng chục nghìn mẫu/giây, truy vấn theo khoảng thời gian, giữ hàng tháng đến hàng năm, với chi phí thấp.

Lựa chọn

MySQL, TimescaleDB, InfluxDB, Prometheus, VictoriaMetrics, ClickHouse.

Quyết định

VictoriaMetrics nhận dữ liệu qua Prometheus remote-write. Bắt đầu single node, lên cluster khi cần.

Lý do

• Nén rất tốt (khoảng 1 byte mỗi mẫu), tốn ít tài nguyên, vận hành đơn giản.
• Giao thức ghi chuẩn (remote-write) nên thay được TSDB (Prometheus, Mimir, Thanos, VictoriaMetrics) mà không đổi collector.
• MySQL không phù hợp lưu chuỗi thời gian quy mô này và sẽ tranh chấp với ứng dụng nghiệp vụ.

Giới hạn đã biết và cách xử lý

• Bản OSS: một retention cho mỗi instance, không downsampling (tính năng trả phí). Dùng hai instance vm-raw và vm-long với vmalert recording rules (xem 04-data-model).
• Retention là toàn cụm, không theo công ty. Retention theo công ty ghi ở GĐ 4.
• Đặt tiền tố ah_ cho tên chỉ số, nhãn hệ thống company_id, server_id.

Hệ quả

• Thêm một thành phần lưu trữ để vận hành và sao lưu.
• Cần logic chọn nguồn (raw hay rollup) trong API truy vấn.
• Truy vấn chỉ đi qua API cố định của collector, không cho PromQL thô (cô lập tenant).