ClickHouse vs DuckDB năm 2026: OLAP nhúng trong bộ nhớ so với kho dữ liệu phân tán được vector hóa

Hướng dẫn này cung cấp một so sánh kiến trúc và đánh giá kỹ thuật dựa trên dữ liệu của DuckDB và ClickHouse cho các khối lượng công việc phân tích thời gian thực vào năm 2026. Chúng tôi phân tích sự phù hợp của chúng trên các quy mô dữ liệu, yêu cầu đồng thời và cấu hình chi phí hạ tầng khác nhau trên Google Cloud.

Tổng quan kiến trúc

DuckDB hoạt động như một cơ sở dữ liệu OLAP nhúng, chạy trong tiến trình. Sức mạnh chính của nó nằm ở công cụ thực thi dạng cột, vector hóa được tối ưu hóa cho các truy vấn phân tích hiệu suất cao trên một nút đơn. Nó vượt trội trong việc xử lý dữ liệu cục bộ, thường trực tiếp truy vấn các định dạng tệp Parquet, CSV hoặc các định dạng khác mà không cần nhập trước vào một tiến trình máy chủ riêng biệt.

ClickHouse là một cơ sở dữ liệu OLAP dạng cột, phân tán được thiết kế cho kho dữ liệu quy mô petabyte và phân tích thời gian thực. Nó tận dụng khả năng song song hóa lớn, lập chỉ mục tinh vi (ví dụ: họ MergeTree) và kiến trúc phân tán để xử lý việc nhập dữ liệu thông lượng cao và các truy vấn phân tích phức tạp trên các tập dữ liệu khổng lồ.

Phương pháp đánh giá

Đánh giá của chúng tôi tập trung vào ba lĩnh vực chính: hiệu suất truy vấn, chi phí bộ nhớ dưới sự đồng thời và thông lượng nhập dữ liệu. Tất cả các thử nghiệm được thực hiện trên Google Cloud Platform (GCP).

Tạo dữ liệu

Chúng tôi mô phỏng dữ liệu sự kiện với một lược đồ: (timestamp DATETIME, user_id UUID, event_type VARCHAR, value FLOAT, region VARCHAR, properties JSON). Quy mô dữ liệu: 10 triệu (10M), 100 triệu (100M) và 1 tỷ (1B) hàng. Định dạng dữ liệu: Parquet, nén bằng Snappy.

Thông số kỹ thuật phần cứng

DuckDB (Nút đơn):

• n2-standard-16 (16 vCPU, 64 GB RAM)
• n2-standard-32 (32 vCPU, 128 GB RAM)
• SSD cục bộ cho các tệp Parquet.

ClickHouse (Cụm phân tán):

• Cụm ClickHouse 3 nút (3 shard, 1 replica mỗi shard cho HA).
• Mỗi nút: n2-standard-16 (16 vCPU, 64 GB RAM).
• SSD bền vững để lưu trữ dữ liệu.
• Google Kubernetes Engine (GKE) để điều phối.

Khối lượng công việc truy vấn

Chúng tôi định nghĩa một tập hợp các truy vấn phân tích đại diện cho các bảng điều khiển thời gian thực và phân tích ad-hoc:

1. Q1: Tổng hợp theo chiều: SELECT region, count() FROM events WHERE timestamp BETWEEN ? AND ? GROUP BY region ORDER BY count() DESC LIMIT 10;
2. Q2: Tổng hợp chuỗi thời gian: SELECT toStartOfHour(timestamp) AS hour, avg(value) FROM events WHERE event_type = ? AND timestamp BETWEEN ? AND ? GROUP BY hour ORDER BY hour;
3. Q3: Nhóm theo có tính đa dạng cao: SELECT user_id, count() FROM events WHERE timestamp BETWEEN ? AND ? GROUP BY user_id HAVING count() > 50 ORDER BY count() DESC LIMIT 100;
4. Q4: Truy cập thuộc tính JSON (chỉ ClickHouse, DuckDB yêu cầu UDF hoặc phân tích cú pháp cụ thể): SELECT JSONExtractString(properties, 'campaign_id'), count() FROM events WHERE timestamp BETWEEN ? AND ? GROUP BY 1 ORDER BY count() DESC LIMIT 10; (Đối với DuckDB, chúng tôi sẽ mô phỏng bằng một cột được trích xuất trước hoặc UDF).

Kiểm tra đồng thời

Đồng thời được mô phỏng bằng locust cho ClickHouse và các tập lệnh Python đa luồng cho DuckDB, đo độ trễ truy vấn trung bình và dung lượng bộ nhớ dưới 10, 50 và 100 truy vấn đồng thời.

Chi tiết triển khai

DuckDB truy vấn Parquet

Sức mạnh của DuckDB là khả năng truy vấn trực tiếp các tệp Parquet.

import duckdb
import pandas as pd
import time
import os

# Ensure Parquet files are available locally
# For 1B rows, this would be multiple Parquet files
PARQUET_FILE_PATH = "s3://your-bucket/events_100M.parquet" # Or local path

def run_duckdb_query(query: str, params: tuple = None):
    """
    Executes a DuckDB query against a Parquet file.
    """
    start_time = time.perf_counter()
    try:
        # DuckDB can directly query S3/GCS paths if credentials are set up
        # For local files, just use the path
        con = duckdb.connect(database=':memory:', read_only=False)
        con.execute(f"INSTALL httpfs; LOAD httpfs;") # For S3/GCS access
        con.execute(f"SET s3_region='us-central1';") # Example for GCS, adjust as needed

        # Register the Parquet file as a table
        con.execute(f"CREATE OR REPLACE VIEW events AS SELECT * FROM '{PARQUET_FILE_PATH}';")

        if params:
            result = con.execute(query, params).fetchall()
        else:
            result = con.execute(query).fetchall()

        end_time = time.perf_counter()
        return (end_time - start_time) * 1000 # ms
    except Exception as e:
        print(f"DuckDB Query failed: {e}")
        return -1

# Example Q1 execution
start_date = "2026-01-01 00:00:00"
end_date = "2026-01-01 23:59:59"
query_q1 = """
SELECT region, count()
FROM events
WHERE timestamp BETWEEN ? AND ?
GROUP BY region
ORDER BY count() DESC
LIMIT 10;
"""
# print(f"DuckDB Q1 (100M rows): {run_duckdb_query(query_q1, (start_date, end_date)):.2f} ms")

# DuckDB ingestion (if needed, e.g., from CSV to Parquet)
def duckdb_ingest_csv_to_parquet(csv_path: str, parquet_path: str):
    con = duckdb.connect(database=':memory:', read_only=False)
    con.execute(f"COPY (SELECT * FROM '{csv_path}') TO '{parquet_path}' (FORMAT PARQUET, COMPRESSION SNAPPY);")
    con.close()

ClickHouse truy vấn

ClickHouse yêu cầu dữ liệu phải được nhập vào các bảng của nó. Chúng tôi sử dụng clickhouse-driver cho Python.

from clickhouse_driver import Client
import time
import json

CLICKHOUSE_HOST = "your-clickhouse-cluster-ip"
CLICKHOUSE_PORT = 9000 # Native protocol
CLICKHOUSE_USER = "default"
CLICKHOUSE_PASSWORD = "your-password"
CLICKHOUSE_DB = "default"

def get_clickhouse_client():
    return Client(
        host=CLICKHOUSE_HOST,
        port=CLICKHOUSE_PORT,
        user=CLICKHOUSE_USER,
        password=CLICKHOUSE_PASSWORD,
        database=CLICKHOUSE_DB
    )

def run_clickhouse_query(query: str, params: dict = None):
    """
    Executes a ClickHouse query.
    """
    client = get_clickhouse_client()
    start_time = time.perf_counter()
    try:
        result = client.execute(query, params)
        end_time = time.perf_counter()
        return (end_time - start_time) * 1000 # ms
    except Exception as e:
        print(f"ClickHouse Query failed: {e}")
        return -1
    finally:
        client.disconnect()

# Example Q1 execution
start_date = "2026-01-01 00:00:00"
end_date = "2026-01-01 23:59:59"
query_q1_ch = """
SELECT region, count()
FROM events
WHERE timestamp BETWEEN %(start_date)s AND %(end_date)s
GROUP BY region
ORDER BY count() DESC
LIMIT 10;
"""
# print(f"ClickHouse Q1 (100M rows): {run_clickhouse_query(query_q1_ch, {'start_date': start_date, 'end_date': end_date}):.2f} ms")

# ClickHouse Ingestion (example using HTTP interface for bulk)
def clickhouse_ingest_parquet(parquet_file_path: str, table_name: str):
    """
    Ingests a Parquet file into ClickHouse using the HTTP interface.
    Requires 'clickhouse-client' or similar tool for direct file upload.
    For Python, usually involves reading Parquet into DataFrame and then inserting.
    """
    # This is a simplified example. For 1B rows, use `clickhouse-client` or Kafka Connect.
    # Example using pandas and clickhouse-driver for smaller batches:
    import pandas as pd
    df = pd.read_parquet(parquet_file_path)
    client = get_clickhouse_client()
    start_time = time.perf_counter()
    try:
        # Ensure table schema matches DataFrame
        client.execute(f"INSERT INTO {table_name} VALUES", df.to_dict(orient='records'))
        end_time = time.perf_counter()
        return (end_time - start_time) * 1000 # ms
    except Exception as e:
        print(f"ClickHouse Ingestion failed: {e}")
        return -1
    finally:
        client.disconnect()

# For large-scale ingestion, consider:
# 1. `clickhouse-client --query="INSERT INTO events FORMAT Parquet"` < your_file.parquet
# 2. Kafka Connect with ClickHouse Sink Connector
# 3. Materialize views from object storage (e.g., S3/GCS) using `s3` or `gcs` table functions.

Kết quả đánh giá (Mô phỏng 2026)

Những kết quả này được ngoại suy dựa trên các xu hướng hiện tại và các tối ưu hóa dự kiến.

Hiệu suất truy vấn (Độ trễ trung bình tính bằng ms)

N/A: DuckDB yêu cầu UDF hoặc phân tích cú pháp trước để truy vấn JSON hiệu quả, điều này làm tăng độ phức tạp và chi phí không thể so sánh trực tiếp với các hàm JSONExtract gốc của ClickHouse.

Quan sát:

• Đối với 10M-100M hàng, DuckDB trên một nút đơn mạnh mẽ có tính cạnh tranh cao, thường vượt trội hơn ClickHouse đối với các tổng hợp đơn giản do không có chi phí mạng và thực thi hiệu quả trong tiến trình.
• Ở 1B hàng, bản chất phân tán và khả năng xử lý song song của ClickHouse mang lại lợi thế đáng kể, đạt thời gian truy vấn dưới giây trong khi DuckDB mất vài giây.
• Hiệu suất của DuckDB tăng tuyến tính với CPU/RAM cho các hoạt động trên một nút.
• Việc lập chỉ mục chuyên biệt của ClickHouse (ví dụ: MergeTree với các chỉ mục minmax và set) góp phần vào hiệu suất vượt trội của nó trên các tập dữ liệu lớn.

Chi phí bộ nhớ dưới sự đồng thời cao

Quan sát:

• DuckDB, là một hệ thống nhúng, chia sẻ bộ nhớ với ứng dụng chủ. Đồng thời cao có thể nhanh chóng làm cạn kiệt RAM khả dụng, đặc biệt khi xử lý các kết quả trung gian lớn. Mỗi truy vấn đồng thời có thể tải một phần đáng kể dữ liệu vào bộ nhớ.
• ClickHouse, với tư cách là một máy chủ, quản lý bộ nhớ của nó hiệu quả hơn trên các truy vấn đồng thời, tận dụng các bộ nhớ đệm dùng chung và xử lý phân tán để tránh các nút thắt cổ chai trên một nút. Dung lượng bộ nhớ của nó tăng theo số lượng truy vấn đang hoạt động và dữ liệu được xử lý, nhưng trong một môi trường máy chủ được quản lý.

Thông lượng nhập dữ liệu (Hàng/giây)

Quan sát:

• ClickHouse, với công cụ MergeTree được tối ưu hóa cao và khả năng nhập dữ liệu phân tán (ví dụ: Kafka Connect, INSERT INTO ... SELECT FROM S3), cung cấp thông lượng nhập dữ liệu cao hơn đáng kể.
• Việc nhập dữ liệu của DuckDB thường là đơn luồng cho các hoạt động từ tệp sang tệp, mặc dù nó rất nhanh đối với quy mô của nó. Trường hợp sử dụng chính của nó không phải là nhập dữ liệu liên tục với khối lượng lớn vào một máy chủ bền vững.

Chi phí hạ tầng (Ước tính hàng tháng trên GCP, 2026)

Ghi chú:

• Chi phí của DuckDB dành cho một VM đơn, mạnh mẽ.
• Chi phí của ClickHouse dành cho một cụm 3 nút, bao gồm chi phí GKE.
• Chi phí phụ thuộc rất nhiều vào việc sử dụng thực tế, khối lượng dữ liệu và các cấp giá GCP cụ thể. Đây là một cơ sở để so sánh.
• "Chi phí" của DuckDB thường được phân bổ vào cơ sở hạ tầng ứng dụng hiện có, vì nó chạy trong tiến trình. Chi phí ở đây đại diện cho một VM chuyên dụng cho các tác vụ phân tích nặng.

Ma trận quyết định

Những vấn đề và cách khắc phục trong sản xuất

DuckDB

1. Vấn đề: Cạn kiệt bộ nhớ trên các tệp lớn:
   • Triệu chứng: Ứng dụng gặp sự cố với lỗi OOM khi truy vấn các tệp Parquet lớn hoặc thực hiện các phép nối phức tạp.
   • Nguyên nhân: DuckDB tải một phần đáng kể dữ liệu vào bộ nhớ để xử lý. Nếu tập hợp làm việc vượt quá RAM khả dụng, hệ điều hành bắt đầu hoán đổi, dẫn đến hiệu suất giảm nghiêm trọng hoặc OOM.
   • Cách khắc phục:
     • Tăng RAM của VM.
     • Lọc dữ liệu sớm hơn: Đẩy các vị từ xuống các trình đọc Parquet.
     • Sử dụng LIMIT và OFFSET để phân trang.
     • Chia nhỏ các truy vấn phức tạp thành các bước nhỏ hơn, ghi kết quả trung gian vào các tệp Parquet tạm thời.
     • Điều chỉnh giới hạn bộ nhớ của DuckDB: PRAGMA memory_limit='XGB'; để ngăn chặn tình trạng thrashing ở cấp độ hệ điều hành, cho phép DuckDB báo lỗi một cách duyên dáng.
2. Vấn đề: Giới hạn xử lý tệp:
   • Triệu chứng: Lỗi Too many open files khi truy vấn nhiều tệp Parquet nhỏ hoặc dưới sự đồng thời cao.
   • Nguyên nhân: Mỗi tệp Parquet (hoặc phân đoạn) có thể yêu cầu một xử lý tệp.
   • Cách khắc phục:
     • Hợp nhất các tệp Parquet nhỏ thành các tệp lớn hơn.
     • Tăng giới hạn xử lý tệp của hệ điều hành (ulimit -n).
     • Đảm bảo quản lý kết nối đúng cách; đóng các kết nối DuckDB khi không còn cần thiết.
3. Vấn đề: Giảm hiệu suất với bộ nhớ từ xa (S3/GCS):
   • Triệu chứng: Các truy vấn chống lại các tệp Parquet trên S3/GCS chậm hơn đáng kể so với các tệp cục bộ.
   • Nguyên nhân: Độ trễ mạng và giới hạn băng thông. DuckDB có thể tìm nạp toàn bộ các nhóm hàng hoặc cột Parquet qua mạng.
   • Cách khắc phục:
     • Đảm bảo VM nằm trong cùng khu vực với nhóm S3/GCS.
     • Sử dụng tiện ích mở rộng httpfs và cấu hình thông tin xác thực S3/GCS đúng cách.
     • Tối ưu hóa các tệp Parquet: đảm bảo kích thước nhóm hàng phù hợp (ví dụ: 128MB-512MB), cắt tỉa cột và đẩy vị từ.
     • Cân nhắc các cơ chế bộ nhớ đệm cục bộ nếu các mẫu truy cập dữ liệu lặp lại.

ClickHouse

1. Vấn đề: GROUP BY có tính đa dạng cao trên các nút có bộ nhớ thấp:
   • Triệu chứng: Các truy vấn liên quan đến GROUP BY trên các cột có hàng triệu giá trị duy nhất bị lỗi với Memory limit exceeded hoặc cực kỳ chậm.
   • Nguyên nhân: ClickHouse cần xây dựng các bảng băm trong bộ nhớ cho các hoạt động GROUP BY. Nếu tính đa dạng quá cao so với RAM khả dụng trên một shard đơn, nó có thể bị lỗi.
   • Cách khắc phục:
     • Tăng cài đặt max_memory_usage và max_bytes_before_external_group_by.
     • Tăng RAM trên các nút ClickHouse.
     • Tổng hợp trước dữ liệu bằng cách sử dụng Chế độ xem vật lý (Materialized Views) cho các chiều có tính đa dạng cao phổ biến.
     • Sử dụng công cụ bảng DISTRIBUTED với GROUP BY trên khóa shard nếu có thể, hoặc đảm bảo dữ liệu được phân phối đều.
2. Vấn đề: Nhập dữ liệu chậm với các lô nhỏ:
   • Triệu chứng: Thông lượng nhập dữ liệu thấp, ngay cả với các nút mạnh mẽ.
   • Nguyên nhân: ClickHouse được tối ưu hóa cho các chèn hàng loạt lớn. Nhiều chèn nhỏ gây ra chi phí cao (chi phí giao dịch, tạo phần cây hợp nhất).
   • Cách khắc phục:
     • Chèn hàng loạt: Nhắm mục tiêu các lô từ 10.000 đến 100.000 hàng trở lên.
     • Sử dụng chèn không đồng bộ hoặc Kafka Connect để truyền trực tuyến.
     • Điều chỉnh merge_tree_min_rows_for_wide_part và merge_tree_min_bytes_for_wide_part cho các bảng MergeTree.
3. Vấn đề: Cạn kiệt không gian đĩa do hợp nhất:
   • Triệu chứng: Sử dụng đĩa tăng nhanh, ngay cả khi khối lượng dữ liệu không tăng theo tỷ lệ, dẫn đến lỗi No space left on device.
   • Nguyên nhân: Các bảng MergeTree định kỳ hợp nhất các phần dữ liệu nhỏ hơn thành các phần lớn hơn. Quá trình này tạm thời yêu cầu thêm không gian đĩa (lên đến 2 lần kích thước của các phần đang hợp nhất).
   • Cách khắc phục:
     • Cung cấp đủ không gian đĩa (ít nhất 2-3 lần kích thước dữ liệu dự kiến của bạn).
     • Giám sát việc sử dụng đĩa và hoạt động hợp nhất.
     • Điều chỉnh merge_tree_max_bytes_to_merge_at_once và merge_tree_max_parts_to_merge_at_once để kiểm soát hành vi hợp nhất, nhưng hãy thận trọng vì điều này có thể ảnh hưởng đến hiệu suất truy vấn.
     • Triển khai lưu trữ phân cấp nếu có sẵn (ví dụ: lưu trữ lạnh cho dữ liệu cũ hơn).

Các câu hỏi thường gặp

Q1: Khi nào tôi nên chọn DuckDB thay vì ClickHouse?

Chọn DuckDB khi:

• Dữ liệu của bạn nằm trong bộ nhớ/đĩa của một máy mạnh mẽ duy nhất (lên đến vài trăm GB).
• Bạn cần một công cụ phân tích nhúng trong một ứng dụng (ví dụ: ứng dụng máy tính để bàn, ETL cục bộ, thiết bị biên).
• Bạn ưu tiên sự đơn giản trong triển khai và không có chi phí vận hành.
• Nguồn dữ liệu chính của bạn là các tệp cục bộ (Parquet, CSV) và bạn muốn truy vấn chúng trực tiếp.
• Chi phí là một mối quan tâm lớn và bạn có thể tận dụng các tài nguyên tính toán hiện có.

Q2: Khi nào ClickHouse là người chiến thắng rõ ràng?

ClickHouse là lựa chọn vượt trội khi:

• Bạn hoạt động ở quy mô petabyte và yêu cầu xử lý phân tán.
• Bạn cần nhập dữ liệu thời gian thực thông lượng cao (hàng triệu hàng/giây).
• Ứng dụng của bạn yêu cầu đồng thời cao cho các truy vấn phân tích (hàng trăm đến hàng nghìn QPS).
• Bạn yêu cầu tính sẵn sàng cao và khả năng chịu lỗi cho kho dữ liệu phân tích của mình.
• Bạn có một nhóm vận hành chuyên trách hoặc cảm thấy thoải mái khi quản lý một hệ thống phân tán.
• Các phép nối phức tạp, nhiều bảng và các hàm phân tích nâng cao được sử dụng thường xuyên.

Q3: DuckDB và ClickHouse có thể được sử dụng cùng nhau không?

Có, chúng có thể bổ sung cho nhau.

• DuckDB để tiền xử lý/ETL cục bộ: Sử dụng DuckDB để làm sạch, chuyển đổi và tổng hợp dữ liệu cục bộ trước khi nhập vào cụm ClickHouse. Điều này giảm tải tính toán từ ClickHouse và đảm bảo dữ liệu sạch hơn.
• DuckDB để phân tích biên: Triển khai DuckDB trên các thiết bị biên hoặc ứng dụng khách để có thông tin chi tiết cục bộ, tức thì, trong khi ClickHouse đóng vai trò là kho dữ liệu trung tâm cho phân tích toàn cầu.
• ClickHouse để phục vụ, DuckDB để khám phá ad-hoc: ClickHouse cung cấp năng lượng cho các bảng điều khiển sản xuất, trong khi các nhà khoa học dữ liệu sử dụng DuckDB để khám phá nhanh chóng, ad-hoc các tập con dữ liệu nhỏ hơn được trích xuất từ ClickHouse hoặc các tệp thô.

Q4: Độ tươi mới của dữ liệu so sánh giữa hai loại như thế nào?

• DuckDB: Độ tươi mới của dữ liệu là tức thì nếu truy vấn các tệp cục bộ. Nếu dữ liệu được truyền trực tuyến đến các tệp, độ tươi mới phụ thuộc vào tần suất ghi tệp.
• ClickHouse: Cung cấp độ tươi mới dữ liệu tuyệt vời. Với các bảng MergeTree và nhập dữ liệu truyền trực tuyến (ví dụ: Kafka), dữ liệu có thể sẵn sàng để truy vấn trong vòng vài mili giây sau khi được nhập. Điều này làm cho nó lý tưởng cho phân tích thời gian thực.

Q5: Các giới hạn mở rộng chính cho mỗi loại vào năm 2026 là gì?

• DuckDB: Chủ yếu mở rộng theo chiều dọc (nhiều CPU, RAM, lưu trữ cục bộ nhanh hơn). Hạn chế cơ bản của nó vẫn là kiến trúc một nút. Mặc dù nó có thể truy vấn các hệ thống tệp phân tán, nhưng bản thân quá trình xử lý là cục bộ. Các phát triển trong tương lai có thể bao gồm song song hóa đa lõi hạn chế cho các hoạt động cụ thể, nhưng xử lý truy vấn phân tán thực sự không phải là sứ mệnh cốt lõi của nó.
• ClickHouse: Mở rộng theo chiều ngang bằng cách thêm nhiều nút (shard). Các hạn chế của nó thường liên quan đến băng thông mạng giữa các nút, sự phức tạp của việc quản lý các cụm rất lớn và chi phí của các phép nối phân tán nếu dữ liệu không được phân chia tối ưu. Tuy nhiên, những cải tiến liên tục trong tối ưu hóa truy vấn phân tán và triển khai đám mây gốc (ví dụ: ClickHouse Cloud) đã giảm thiểu nhiều thách thức này.