Cơ sở dữ liệu chuỗi thời gian (Time Series Database, TSDB)

1. Tổng quan

Cơ sở dữ liệu chuỗi thời gian (TSDB) là cơ sở dữ liệu chuyên dụng lấy thời gian (timestamp) làm trục hạng nhất (first-class), được tối ưu hóa để thu thập, nén, truy vấn và lưu giữ tốc độ cao các giá trị đo (metric) không ngừng tích lũy theo thứ tự thời gian. Nếu CSDL quan hệ lưu "điều gì là đúng (trạng thái hiện tại)", thì TSDB lưu "vào lúc nào giá trị là gì (lịch sử thay đổi trạng thái)", và chuyên biệt cho việc ghi append-only khối lượng lớn cũng như tổng hợp theo khoảng thời gian (range aggregation).

Dữ liệu chuỗi thời gian là dãy giá trị đo lặp lại theo thời gian đối với một đối tượng quan sát. Giá trị tỷ lệ sử dụng CPU của máy chủ được ghi mỗi giây, giá trị mà cảm biến rung của thiết bị trong nhà máy thông minh phát ra hàng nghìn lần mỗi giây, giá khớp lệnh cổ phiếu, lượng điện tiêu thụ của đồng hồ thông minh hộ gia đình đều là chuỗi thời gian. Điểm chung của chúng là sự kiện không thay đổi (immutable) sau khi thời gian trôi qua, áp đảo về ghi (write-heavy), và truy vấn thường mang dạng tổng hợp theo khoảng thời gian cho "N phút gần nhất/một khoảng cụ thể".

Nếu đưa nguyên dữ liệu như vậy vào CSDL quan hệ truyền thống (RDBMS), nhiều chỗ sẽ không khớp. RDBMS dùng chỉ mục B-tree và lưu trữ theo hàng với tiền đề cập nhật/xóa hàng tùy ý và phép nối (join) phức tạp, nhưng chuỗi thời gian hầu như không cập nhật mà chỉ có lượng chèn bùng nổ, nên chỉ mục B-tree liên tục bị tách trang (page split) và hiệu năng ghi giảm mạnh. Ngoài ra, khi hàng trăm nghìn điểm mỗi giây tích lũy vô hạn, dung lượng lưu trữ tăng tuyến tính, trong khi CSDL đa dụng không có khái niệm nén chuyên biệt theo trục thời gian hay tự động hết hạn (retention), làm tăng gánh nặng vận hành. TSDB chính là bộ máy lưu trữ được thiết kế để giải quyết khoảng trống này — thu thập tốc độ cao, nén cực độ, truy vấn theo khoảng thời gian, quản lý vòng đời.

Trong bài luận, không nên thu hẹp TSDB thành "CSDL để chứa dữ liệu thời gian", mà nên triển khai theo ba trục: (1) đặc tính cấu trúc của mô hình dữ liệu chuỗi thời gian (giá trị đo·tag·timestamp), (2) công nghệ bộ máy lưu trữ gồm tối ưu hóa append dựa trên LSM và nén delta·nén theo cột, (3) quản lý vòng đời dữ liệu tiêu biểu là downsampling và chính sách lưu giữ.

A. Bối cảnh ra đời và sự cần thiết

Thứ nhất, sự bùng nổ của khả năng quan sát (Observability) và IoT là động lực quyết định. Khi kiến trúc microservice (MSA) lan rộng, hàng trăm dịch vụ mỗi dịch vụ xuất ra hàng trăm chỉ số theo từng giây, và tại hiện trường công nghiệp, hàng chục nghìn cảm biến đồng thời đổ ra giá trị đo. Chẳng hạn, nếu 100 container mỗi container ghi 50 chỉ số mỗi 10 giây thì chỉ trong một ngày đã phát sinh khoảng 43 triệu điểm, quy mô này dễ dàng vượt quá giới hạn xử lý chèn của CSDL đa dụng.

Thứ hai là áp lực chi phí lưu trữ (TCO). Chuỗi thời gian không bao giờ ngừng tích lũy, nên nếu giữ nguyên dữ liệu gốc thì chi phí lưu trữ tăng vô hạn. Tận dụng tính chất các giá trị đo liên tiếp có biên độ thay đổi nhỏ (ví dụ: CPU 60% → 61% → 60%), có thể nén hơn 10 lần bằng mã hóa delta và bit-packing, nên nén chuyên dụng trực tiếp dẫn đến cắt giảm chi phí.

Thứ ba là sự thiên lệch của mẫu truy vấn. Truy vấn chuỗi thời gian áp đảo là tổng hợp theo từng khoảng (bucket) thời gian như "trung bình 5 phút trong 6 giờ qua", "xu hướng thời gian phản hồi P99", hơn là tìm kiếm từng hàng riêng lẻ. Để xử lý nhanh những truy vấn như vậy, cần cấu trúc chuyên dụng sắp xếp và phân vùng (partitioning) dữ liệu về mặt vật lý theo trục thời gian và tận dụng các bản roll-up đã tổng hợp trước.

2. Mô hình dữ liệu chuỗi thời gian và cấu trúc tổng thể

Mô hình dữ liệu của TSDB phần lớn gồm tổ hợp tên giá trị đo (measurement/metric) + tập tag (tags/labels) + giá trị trường (field) + timestamp. Ở đây, mỗi tổ hợp tag duy nhất định nghĩa một chuỗi thời gian (series). Ví dụ, cpu_usage{host="web-01", region="seoul"} và cpu_usage{host="web-02", region="seoul"} cùng tên nhưng khác tag nên là hai chuỗi thời gian riêng biệt, và mỗi chuỗi là một dãy các cặp (timestamp, value) được sắp xếp theo thời gian.

Khái niệm cốt lõi để hiểu mô hình này là lực lượng (cardinality). Cardinality là tổng số chuỗi thời gian khác nhau, xấp xỉ bằng tích số lượng giá trị mà mỗi tag có thể nhận. Nếu host có 1.000 loại, region có 10 loại, metric có 50 loại thì về lý thuyết sinh ra 500 nghìn chuỗi thời gian. Khi cardinality bùng nổ, chỉ mục chiếm hết bộ nhớ và truy vấn chậm đi, nên nguyên tắc thiết kế số một là không dùng các mục có số loại giá trị tăng vô hạn như ID người dùng, ID yêu cầu làm tag.

graph TB
    subgraph SRC["Nguồn dữ liệu"]
        S1["Chỉ số máy chủ·container"]
        S2["Luồng IoT·cảm biến"]
        S3["Sự kiện ứng dụng"]
    end
    S1 --> COL["Thu thập·agent (Telegraf·Exporter)"]
    S2 --> COL
    S3 --> COL
    COL -->|"Ghi theo lô (append)"| ING["Tầng thu nhận (Ingestion·WAL)"]
    ING --> MEM["Bộ đệm bộ nhớ (dữ liệu gần đây)"]
    MEM -->|"flush định kỳ"| STORE["Lưu trữ bền vững (khối nén·TSM/Chunk)"]
    STORE --> RET["Bộ máy lưu giữ·downsampling"]
    RET -->|"Xóa khi hết hạn"| DROP["Hủy dữ liệu gốc cũ"]
    RET -->|"Lưu roll-up"| ROLL["Chuỗi tổng hợp (lưu trữ dài hạn)"]
    QRY["Bộ máy truy vấn (PromQL·Flux·SQL)"] --> MEM
    QRY --> STORE
    QRY --> ROLL
    DASH["Dashboard·cảnh báo (Grafana)"] --> QRY

Trong cấu trúc trên, dữ liệu bắt đầu khi agent thu thập chỉ số từ nguồn và gửi theo lô tới tầng thu nhận. Dữ liệu vừa đến trước tiên được ghi vào WAL (Write-Ahead Log) để bảo đảm độ bền rồi được tích lũy trong bộ đệm bộ nhớ; do dữ liệu càng mới thì tần suất truy vấn càng cao nên được phản hồi trực tiếp từ bộ nhớ. Khi bộ đệm đạt kích thước nhất định, dữ liệu được đẩy xuống đĩa (flush) thành các khối bất biến đã sắp xếp theo thời gian và nén; bộ máy lưu giữ xóa dữ liệu gốc cũ khi hết hạn và giữ lại phần cần lưu dài hạn dưới dạng roll-up độ phân giải thấp. Bộ máy truy vấn đi xuyên suốt một cách trong suốt qua bộ nhớ, đĩa và roll-up để kết hợp kết quả, và dashboard trực quan hóa kết quả truy vấn này.

A. Bộ máy lưu trữ: LSM và nén theo trục thời gian

Bí quyết giúp TSDB chịu được lượng chèn tốc độ cao phần lớn nằm ở cấu trúc họ LSM (Log-Structured Merge). B-tree của RDBMS tìm vị trí chèn và cập nhật trang nên có nhiều thao tác ghi ngẫu nhiên, còn LSM trước hết tích lũy tuần tự các thao tác ghi đến vào bộ nhớ (memtable), sau đó ghi tuần tự toàn bộ xuống đĩa thành tệp bất biến đã được sắp xếp. Ghi tuần tự nhanh hơn ghi ngẫu nhiên hàng chục lần và có lợi cho tuổi thọ SSD, nên có thể đáp ứng lượng append từ hàng trăm nghìn đến hàng triệu điểm mỗi giây. Bộ máy TSM của InfluxDB và cấu trúc block/chunk của Prometheus tuân theo nguyên lý này.

Nén là lợi thế ấn tượng nhất của TSDB. Timestamp thường có khoảng cách đều (ví dụ: 10 giây) nên bằng mã hóa delta-of-delta phần lớn được biến thành giá trị gần 0 và biểu diễn bằng vài bit; còn giá trị đo dấu phẩy động được áp dụng nén Gorilla, XOR với giá trị trước rồi loại bỏ các bit 0 ở đầu và cuối. Theo bài báo Gorilla do Facebook công bố, kỹ thuật này giảm mỗi điểm chuỗi thời gian xuống trung bình khoảng 1,37 byte, đạt tỷ lệ nén hơn 10 lần so với không nén. Trong thực tế, khi một điểm thô 16 byte (timestamp 8B + giá trị 8B) giảm xuống 1–2 byte, chi phí lưu trữ và I/O đĩa cùng giảm mạnh.

B. Vòng đời dữ liệu: chính sách lưu giữ và downsampling

Với chuỗi thời gian, việc xem "càng gần càng chi tiết, càng xa càng thô" là tự nhiên. Khi theo dõi sự cố theo thời gian thực cần độ phân giải 1 giây, nhưng khi xem xu hướng dung lượng của 1 năm trước thì trung bình 1 giờ là đủ. Tận dụng tính chất này, TSDB dùng downsampling (giảm mẫu) để tóm tắt dữ liệu gốc cũ thành roll-up độ phân giải thấp (ví dụ: 1 giây → trung bình/lớn nhất/nhỏ nhất 1 phút), và dùng chính sách lưu giữ (retention policy) để tự động cho dữ liệu gốc hết hạn.

Ví dụ, nếu đặt chính sách "dữ liệu gốc lưu 7 ngày, roll-up 1 phút lưu 90 ngày, roll-up 1 giờ lưu 2 năm", ta đồng thời bảo đảm độ chính xác cho phân tích sự cố gần đây và tính kinh tế cho phân tích xu hướng dài hạn. Chẳng hạn, khi downsampling 1 điểm/giây thành trung bình 1 phút, lượng dữ liệu giảm còn 1/60, nên dữ liệu dài hạn 2 năm cũng có thể duy trì với chi phí thực tế. Đây là chức năng vận hành cốt lõi chuyên biệt cho khối lượng công việc chuỗi thời gian mà CSDL đa dụng không có.

3. Các loại sản phẩm chính và so sánh kiến trúc

TSDB được chia thành ba nhánh lớn tùy theo nguồn gốc và triết lý thiết kế. Tiêu biểu là loại bộ máy chuyên dụng (InfluxDB), loại tích hợp giám sát (Prometheus) và loại mở rộng quan hệ (TimescaleDB), mỗi loại có điểm mạnh và sự đánh đổi khác nhau.

InfluxDB là bộ máy chuyên dụng được thiết kế từ đầu chỉ dành cho chuỗi thời gian, có định dạng lưu trữ riêng (TSM) và ngôn ngữ truy vấn riêng (Flux/InfluxQL), đạt thông lượng chèn và tỷ lệ nén cao. Ngược lại, khả năng tương thích với hệ sinh thái SQL yếu, và các chức năng sẵn sàng cao như clustering bị gắn với phiên bản thương mại là điểm hạn chế.

Prometheus là tiêu chuẩn thực tế cho quan sát Kubernetes, là nền tảng giám sát kết hợp thu thập theo kiểu kéo (pull), ngôn ngữ truy vấn mạnh mẽ PromQL và quy tắc cảnh báo. Do mặc định là lưu trữ cục bộ trên một nút, để lưu trữ dài hạn và mở rộng ngang phải gắn thêm tầng lưu trữ từ xa như Thanos hoặc Cortex/Mimir.

TimescaleDB hoạt động như một extension của PostgreSQL, cho phép dùng nguyên SQL chuẩn, join, giao dịch, đồng thời bên trong cung cấp phân vùng tự động theo thời gian (hypertable) và nén theo cột. Điểm mạnh lớn nhất là có thể tái sử dụng tài sản quan hệ và nhân lực hiện có, đổi lại phải nhường phần nào hiệu năng chèn cực độ so với bộ máy chuyên dụng thuần túy.

Phân loại	InfluxDB (bộ máy chuyên dụng)	Prometheus (giám sát)	TimescaleDB (mở rộng RDBMS)
Nền tảng	Bộ máy TSM riêng	Block/chunk riêng	Extension PostgreSQL
Thu thập	Push (line protocol)	Pull (scraping)	SQL INSERT/COPY
Truy vấn	Flux·InfluxQL	PromQL	SQL chuẩn
Điểm mạnh	Nén cao·chèn cao	Quan sát cloud-native	Tương thích SQL·join
Hạn chế	Hệ sinh thái SQL yếu	Lưu trữ dài hạn cần cấu hình riêng	Nhường hiệu năng chèn siêu tốc

Tuy nhiên, bảng trên chỉ là điểm xuất phát cho việc lựa chọn; quyết định thực tế phụ thuộc vào "ngăn xếp công nghệ đã có và năng lực đội ngũ, cardinality yêu cầu, yêu cầu lưu trữ dài hạn". Nếu quan sát Kubernetes là cốt lõi thì Prometheus là lựa chọn tự nhiên; nếu đội vận hành PostgreSQL hiện có dày dặn và cần song song phân tích SQL thì TimescaleDB có lợi về tổng chi phí; còn nếu mục đích là thu thập IoT khối lượng lớn thuần túy thì bộ máy chuyên dụng chiếm ưu thế.

A. Kết hợp truy vấn và trực quan hóa

Giá trị của chuỗi thời gian được hiện thực hóa không phải ở lưu trữ mà ở truy vấn·trực quan hóa·cảnh báo. rate(http_requests_total[5m]) của PromQL tính tốc độ tăng số yêu cầu mỗi giây trong 5 phút gần nhất; như vậy, các ngôn ngữ chuyên cho chuỗi thời gian cung cấp các phép tính cửa sổ thời gian, tỷ lệ, phân vị (P95/P99) như phép toán hạng nhất. Phần lớn hiện trường trực quan hóa kết quả truy vấn này bằng dashboard như Grafana và hoàn thiện bằng pipeline phát cảnh báo khi vượt ngưỡng.

sequenceDiagram
    participant SRC as Đối tượng(Target)
    participant P as TSDB(thu thập·lưu trữ)
    participant Q as Bộ máy truy vấn
    participant G as Dashboard·cảnh báo
    SRC->>P: Công bố/gửi chỉ số(scrape·push)
    P->>P: Ghi WAL rồi nạp vào bộ đệm bộ nhớ
    P->>P: flush thành khối nén
    G->>Q: Truy vấn tổng hợp theo khoảng thời gian(rate·P99)
    Q->>P: Tra cứu bộ nhớ+đĩa+roll-up
    P-->>Q: Trả về chuỗi thời gian đã sắp xếp
    Q-->>G: Phản hồi kết quả tổng hợp
    G->>G: Đánh giá ngưỡng rồi phát cảnh báo

4. Chuyên sâu: Xu hướng mới nhất và ứng dụng thực tiễn

Lưu trữ chuỗi thời gian gần đây đang chuyển trọng tâm sang kiến trúc dựa trên lưu trữ đối tượng phân tán. Thanos, Grafana Mimir, VictoriaMetrics v.v. xử lý nhanh dữ liệu gần đây tại cục bộ, còn các khối nén cũ được chuyển xuống lưu trữ đối tượng như S3, hiện thực hóa lưu trữ dài hạn gần như không giới hạn với chi phí thấp. Xu hướng tách rời (disaggregation) tính toán và lưu trữ này cho phép mở rộng tầng lưu trữ một cách độc lập và rẻ ngay cả khi lượng thu thập tăng đột biến.

Ngoài ra, sự hợp nhất khả năng quan sát (Observability) đang được tăng cường. Trước đây metric (TSDB), log và trace là các hệ thống riêng biệt, nhưng khi OpenTelemetry thống nhất tiêu chuẩn thu thập cho ba tín hiệu (signal) này, xu hướng tiến hóa là phân tích tương quan (correlation) metric chuỗi thời gian với log và truy vết phân tán. Ví dụ, quan sát hợp nhất theo kiểu đi sâu (drill-down) ngay vào trace tại thời điểm một chỉ số tăng vọt đang trở thành tiêu chuẩn.

Về trường hợp thực tiễn, các doanh nghiệp thương mại điện tử và fintech lớn tại Hàn Quốc và trên thế giới nạp chỉ số dịch vụ theo từng giây vào TSDB, và đội SRE tính toán SLO/error budget bằng dữ liệu này. Trong lĩnh vực sản xuất, luồng cảm biến thiết bị được lưu vào TSDB để dự đoán trước hỏng hóc (bảo trì dự đoán) từ các xu hướng nhỏ của độ rung và nhiệt độ, và ở đây TSDB còn đảm nhận vai trò nguồn cung cấp đặc trưng (feature) cho các mô hình phát hiện bất thường thời gian thực. Thất bại trong quản lý cardinality là nguyên nhân sự cố tiêu biểu: khi đưa ID yêu cầu vào làm tag khiến số chuỗi thời gian bùng nổ lên hàng triệu, bộ nhớ sẽ cạn kiệt, vì vậy nhất định phải giới hạn số loại giá trị ngay ở giai đoạn thiết kế tag.

5. Những điểm cần cân nhắc và hàm ý

Từ góc nhìn Kỹ sư chuyên nghiệp (Professional Engineer), việc triển khai TSDB cần được tiếp cận không phải như thay thế kho lưu trữ mà như thiết kế lại chiến lược quan sát và vòng đời dữ liệu, cân nhắc tổng hợp các điểm sau.

Quản trị cardinality: Thiết kế tag (label) quyết định hiệu năng và chi phí. Các mục có số loại giá trị có thể tăng vô hạn (ID người dùng, ID phiên, URL đầy đủ) cần được tách sang log/trace thay vì làm tag, đồng thời thiết lập hệ thống quản trị tính toán trước và giám sát giới hạn trên của các tổ hợp tag.
Đánh đổi độ chính xác–chi phí: Độ phân giải gốc, thời gian lưu giữ và chính sách downsampling là quan hệ đánh đổi giữa độ chính xác phân tích và chi phí lưu trữ. Cần phân tầng giữa khoảng độ phân giải cao cần cho phân tích sự cố và roll-up dài hạn cho phân tích xu hướng, văn bản hóa chính sách đáp ứng đồng thời yêu cầu tuân thủ (yêu cầu lưu giữ log kiểm toán) và chi phí.
Hiểu giới hạn của mô hình nhất quán và tổng hợp: Tổng hợp chuỗi thời gian có thể mang tính xấp xỉ, xác suất (ví dụ: phân vị dựa trên histogram là giá trị xấp xỉ). Cần phân biệt lĩnh vực đòi hỏi tổng chính xác như quyết toán tài chính với lĩnh vực chỉ cần quan sát xu hướng để xác định phạm vi áp dụng.
Công nghệ liên kết và tích hợp kiến trúc: TSDB không tự hoàn chỉnh một mình. Nó chỉ tạo ra giá trị khi kết hợp với thu thập (Telegraf·OpenTelemetry), trực quan hóa·cảnh báo (Grafana), lưu trữ dài hạn (S3·Thanos), xử lý luồng (Kafka). Đặc biệt cần thiết kế đồng thời việc hợp nhất khả năng quan sát (log·trace·metric), vận hành SLO/error budget của SRE, và liên kết với các pipeline AI như bảo trì dự đoán và phát hiện bất thường.
Triển vọng: Khi TSDB cloud-native kiểu tách rời tính toán–lưu trữ và việc hợp nhất tín hiệu dựa trên OpenTelemetry trở thành tiêu chuẩn, chuỗi thời gian đang được nâng tầm từ giám sát đơn thuần thành tầng dữ liệu cốt lõi cho ra quyết định và dự đoán theo thời gian thực.

Tài liệu tham khảo

Facebook, "Gorilla: A Fast, Scalable, In-Memory Time Series Database", VLDB 2015 — https://www.vldb.org/pvldb/vol8/p1816-teller.pdf
Prometheus Documentation, "Storage" — https://prometheus.io/docs/prometheus/latest/storage/
InfluxData, "Time Series Database (TSDB) explained" — https://www.influxdata.com/time-series-database/
Timescale Documentation, "Hypertables and compression" — https://docs.timescale.com/

Tóm tắt một câu: Cơ sở dữ liệu chuỗi thời gian là kho lưu trữ chuyên dụng lấy thời gian làm trục hạng nhất, tối ưu hóa thu thập append-only khối lượng lớn, nén theo trục thời gian (delta/Gorilla), tổng hợp theo khoảng, downsampling và chính sách lưu giữ; nó đảm nhận tầng dữ liệu thời gian thực cho khả năng quan sát, IoT và bảo trì dự đoán, trong đó quản trị cardinality và đánh đổi độ chính xác–chi phí là mấu chốt của việc triển khai.