Posted inDatabase

Triển khai QuestDB trên Docker: Hướng dẫn xử lý dữ liệu chuỗi thời gian tốc độ cao

Database tutorial - IT technology blog
Database tutorial - IT technology blog

Tại sao các cơ sở dữ liệu truyền thống lại “vỡ trận” khi mở rộng quy mô

Việc mở rộng quy mô cơ sở dữ liệu cho hàng nghìn cảm biến IoT hoặc các mã chứng khoán tần suất cao thường đi theo một kịch bản đau đớn và dễ đoán. Mọi thứ chạy trơn tru với vài nghìn hàng. Tuy nhiên, một khi bạn chạm ngưỡng 100 triệu hàng mỗi ngày, các cơ sở dữ liệu quan hệ tiêu chuẩn như PostgreSQL hoặc MySQL bắt đầu trở nên chậm chạp. Các truy vấn từng chỉ mất 10 mili giây đột ngột trễ tới 15 giây. Trong khi đó, mức sử dụng CPU tăng vọt lên 100% chỉ để cố gắng bắt kịp luồng dữ liệu ghi liên tục.

Điểm nghẽn nằm ở cấu trúc chỉ mục B-Tree truyền thống và lưu trữ hướng dòng (row-oriented). Mặc dù chúng hoàn hảo cho các hoạt động CRUD thông thường, nhưng chúng không được thiết kế cho dữ liệu chỉ thêm (append-only) và được sắp xếp theo thời gian.

Mỗi khi bạn chèn một hàng vào bảng có nhiều chỉ mục, cơ sở dữ liệu phải cập nhật các cấu trúc đó trên đĩa. Điều này tạo ra gánh nặng I/O khổng lồ. Hơn nữa, nếu bạn cần tính nhiệt độ trung bình đơn giản, một cơ sở dữ liệu hướng dòng sẽ đọc toàn bộ hàng từ đĩa ngay cả khi bạn chỉ cần một cột cụ thể.

QuestDB vượt qua những giới hạn này bằng cách sử dụng công cụ lưu trữ dạng cột (columnar storage engine) và các chỉ thị SIMD (Single Instruction, Multiple Data) để xử lý dữ liệu song song. Nó coi thời gian là một đối tượng ưu tiên hàng đầu. Trên phần cứng 16 lõi khiêm tốn, kiến trúc này cho phép tốc độ nạp dữ liệu vượt quá 4 triệu hàng mỗi giây.

Bức tranh toàn cảnh: QuestDB và các đối thủ lớn

Việc lựa chọn cơ sở dữ liệu chuỗi thời gian (time-series database) thường xoay quanh ba cái tên lớn. Dưới đây là cách QuestDB so sánh với các lựa chọn thay thế mà tôi thường thấy nhất trong môi trường thực tế.

QuestDB vs. InfluxDB

InfluxDB là một “lão làng” trong ngành. Tuy nhiên, kể từ phiên bản 2.x, nó đã chuyển sang Flux, một ngôn ngữ truy vấn hàm. Đối với các đội ngũ đã thành thạo SQL, việc học Flux là một rào cản lớn và thường không cần thiết. QuestDB trung thành với chuẩn ANSI SQL với các phần mở rộng chuỗi thời gian trực quan. Theo kinh nghiệm của tôi, định dạng lưu trữ của QuestDB cũng hiệu quả hơn đáng kể, thường giảm dung lượng đĩa từ 30% đến 50% so với InfluxDB cho cùng một tập dữ liệu.

QuestDB vs. TimescaleDB

TimescaleDB về cơ bản là PostgreSQL với “siêu năng lực”. Đây là một lựa chọn thay thế đáng tin cậy nếu bạn cần tuân thủ đầy đủ tính chất ACID và đã lún sâu vào hệ sinh thái Postgres. Nhưng vì nó dựa trên công cụ lưu trữ của Postgres, nó mang theo nhiều gánh nặng hệ thống hơn. QuestDB là một bản thực thi độc lập được xây dựng từ đầu để tối ưu tốc độ. Nếu ưu tiên của bạn là thông lượng nạp dữ liệu thô và các truy vấn phân tích dưới một mili giây, QuestDB thường thắng trong các bài kiểm tra hiệu năng (benchmark).

Ưu và Nhược điểm

Ưu điểm

  • SQL thuần túy: Chạy các lệnh JOIN và tổng hợp phức tạp mà không cần học cú pháp riêng biệt.
  • Giao thức linh hoạt: Nạp dữ liệu qua InfluxDB Line Protocol (ILP), PostgreSQL Wire, hoặc REST.
  • Chuyển dữ liệu Zero-Copy: Sử dụng các tệp ánh xạ bộ nhớ (memory-mapped files) để cung cấp khả năng truy cập dữ liệu nhanh như chớp.
  • Trực quan hóa tức thì: Giao diện web tích hợp cho phép bạn đi từ con số không đến trực quan hóa dữ liệu trong vài giây.

Nhược điểm

  • Kích thước thư viện: Hệ sinh thái đang phát triển, nhưng vẫn thiếu thư viện plugin bên thứ ba khổng lồ như của PostgreSQL.
  • Cấu trúc cứng nhắc: Không giống như NoSQL, bạn phải xác định cột “timestamp chỉ định” sớm để có hiệu suất tốt nhất.
  • Ngốn RAM: Vì dựa vào ánh xạ bộ nhớ, hiệu suất sẽ giảm nhanh chóng nếu máy chủ của bạn không có đủ RAM để ánh xạ các phần dữ liệu đang hoạt động.

Thiết lập: Docker và Docker Compose

Docker là cách hiệu quả nhất để triển khai QuestDB cho mục đích phát triển hoặc các khối lượng công việc sản xuất quy mô vừa. Nó cô lập môi trường và giúp việc quản lý phiên bản trở nên dễ dàng. Luôn sử dụng một volume riêng để lưu trữ dữ liệu; nếu không, việc khởi động lại container sẽ xóa sạch toàn bộ cơ sở dữ liệu của bạn.

Khi làm việc với việc xuất dữ liệu thô, tôi thường cần chuyển đổi các tệp CSV lộn xộn thành JSON sạch để kiểm thử API. Tôi sử dụng toolcraft.app/vi/tools/data/csv-to-json cho việc này. Nó chạy hoàn toàn trong trình duyệt, đảm bảo rằng dữ liệu cảm biến hoặc tài chính nhạy cảm không bao giờ rời khỏi máy cục bộ của bạn.

Hướng dẫn triển khai

1. Khởi chạy QuestDB

Tạo một thư mục dự án và một tệp docker-compose.yml. Cấu hình này đảm bảo dữ liệu của bạn được lưu trữ lâu dài trong một thư mục cục bộ có tên là questdb_data.

mkdir questdb-project && cd questdb-project
touch docker-compose.yml

Thêm cấu hình này vào tệp của bạn:

services:
  questdb:
    image: questdb/questdb:latest
    container_name: questdb
    restart: always
    ports:
      - "9000:9000"   # Giao diện Web
      - "9009:9009"   # ILP (TCP)
      - "8812:8812"   # Postgres Wire
      - "9003:9003"   # Thông số đo lường (Metrics)
    volumes:
      - ./questdb_data:/var/lib/questdb
    environment:
      - QDB_TELEMETRY_ENABLED=false

Khởi động container:

docker-compose up -d

Truy cập giao diện người dùng ngay lập tức tại http://localhost:9000.

2. Thiết kế bảng

“Timestamp chỉ định” (Designated Timestamp) là bí quyết cốt lõi. Nó cho QuestDB biết cách phân vùng dữ liệu trên đĩa. Đối với dữ liệu IoT, hãy sử dụng schema sau:

CREATE TABLE sensors (
    device_id SYMBOL,
    temperature DOUBLE,
    humidity DOUBLE,
    timestamp TIMESTAMP
) TIMESTAMP(timestamp) PARTITION BY DAY WAL;

Các chi tiết quan trọng:

  • SYMBOL: Chuyển đổi các chuỗi như “sensor_01” thành các số nguyên nội bộ. Nó tiết kiệm một lượng lớn không gian đĩa và tăng tốc độ lọc.
  • PARTITION BY DAY: Tổ chức dữ liệu thành các tệp hàng ngày. Điều này giúp việc xóa dữ liệu cũ trở nên đơn giản như việc xóa một tệp tin.
  • WAL: Write-Ahead Logging đảm bảo tính nhất quán của dữ liệu ngay cả khi mất điện đột ngột.

3. Nạp dữ liệu tốc độ cao với Python

Mặc dù SQL INSERT vẫn hoạt động, nhưng InfluxDB Line Protocol (ILP) được xây dựng để tối ưu tốc độ. Cài đặt thư viện client trước:

pip install questdb

Sử dụng script này để truyền dữ liệu:

from questdb.ingress import Sender, TimestampNanos

def stream_data():
    try:
        # Kết nối tới QuestDB trên localhost
        with Sender('localhost', 9009) as sender:
            for i in range(100):
                sender.row(
                    'sensors',
                    symbols={'device_id': f'sensor_{i}'},
                    columns={'temperature': 20.0 + (i * 0.1), 'humidity': 45.0},
                    at=TimestampNanos.now()
                )
            sender.flush()
            print("Đã nạp xong một đợt (batch).")
    except Exception as e:
        print(f"Nạp dữ liệu thất bại: {e}")

if __name__ == "__main__":
    stream_data()

4. Truy vấn với SAMPLE BY

QuestDB tỏa sáng khi tổng hợp dữ liệu chuỗi thời gian. Để tìm nhiệt độ trung bình mỗi giờ trong 24 giờ qua, hãy sử dụng từ khóa SAMPLE BY:

SELECT timestamp, avg(temperature) 
FROM sensors 
WHERE timestamp > dateadd('d', -1, now()) 
SAMPLE BY 1h;

Cách này nhanh hơn đáng kể so với GROUP BY tiêu chuẩn. Vì dữ liệu đã được phân vùng theo thời gian, QuestDB chỉ quét chính xác các khối dữ liệu cần thiết cho khoảng thời gian cụ thể đó.

Lời kết

Triển khai QuestDB qua Docker mang lại sự gia tăng hiệu suất tức thì cho bất kỳ dự án nào xử lý dữ liệu nhạy cảm về thời gian. Cho dù bạn đang giám sát một đội xe gồm 50.000 thiết bị hay xây dựng bảng điều khiển tiền điện tử theo thời gian thực, sự kết hợp giữa tính dễ dùng của SQL và tốc độ nạp dữ liệu cao là một lợi thế khó đánh bại. Chỉ cần nhớ chọn chiến lược PARTITION BY (Ngày, Tháng hoặc Năm) dựa trên khối lượng dữ liệu dự kiến để giữ cho các truy vấn luôn nhanh nhạy khi tập dữ liệu của bạn lớn dần.

Share:
Tags: