
ClickHouse là gì?
ClickHouse là OLAP database mã nguồn mở được thiết kế cho truy vấn phân tích (analytical queries) tốc độ cực cao trên dữ liệu cột (column-oriented). Khác với PostgreSQL hay MySQL tối ưu cho OLTP (transactional), ClickHouse xuất sắc ở aggregation, filter và join trên hàng tỷ hàng — thường nhanh 100-1000x so với database truyền thống.
Được phát triển bởi Yandex từ 2009 và open-source từ 2016, ClickHouse hiện được dùng bởi Cloudflare, Uber, Spotify, eBay và hàng nghìn công ty cho logging, metrics, user behavior analytics và real-time dashboards.

Tại sao ClickHouse nhanh đến vậy? Ba yếu tố cốt lõi: column-oriented storage, vectorized query execution và data compression. Column-oriented nghĩa là dữ liệu cùng cột được lưu liền kề nhau trên disk. Khi query chỉ cần 3 cột trong 100 cột, ClickHouse chỉ đọc 3 cột đó — giảm I/O đáng kể. Vectorized execution dùng SIMD instructions để xử lý nhiều giá trị cùng lúc thay vì loop từng hàng. Compression (LZ4, ZSTD, Delta, Gorilla) nén dữ liệu cực tốt vì cùng cột thường có pattern tương tự.
Kiến trúc và các bảng engine
ClickHouse không dùng một engine duy nhất. Engine phổ biến nhất là MergeTree family — tương tự LSM tree nhưng tối ưu cho append-heavy workloads. Các biến thể: MergeTree (cơ bản, sắp xếp theo primary key, merge background), ReplacingMergeTree (tự động deduplicate theo primary key), SummingMergeTree (pre-aggregate numeric columns khi merge), AggregatingMergeTree (lưu trữ trạng thái aggregation như uniq, quantiles), CollapsingMergeTree (hỗ trợ update/delete logic qua sign column). Đối với Kafka/HTTP streaming, có Kafka Engine và Null Engine (write-only buffer). Để query external data: JDBC, ODBC, MySQL, PostgreSQL engines.

MergeTree family là tim ClickHouse. Dữ liệu được sắp xếp theo ORDER BY key trong các partition. Mỗi partition lưu trữ dưới dạng các “parts” (các file columnar). Background merge process gộp các parts nhỏ thành parts lớn, đồng thời áp dụng TTL, deduplication, aggregation. Mục tiêu: duy trì số lượng parts ổn định để tránh quá nhiều small files.
So sánh ClickHouse với các giải pháp khác
ClickHouse không phải là lös duy nhất trong thị trường OLAP. Tuy nhiên, sự kết hợp giữa hiệu năng cao, độ dễ triển khai và tính open-source khiến nó trở nên phổ biến. Bảng dưới so sánh ClickHouse với các database phân tích khác:
| Database | Kiểu | Phù hợp nhất | Latency trung bình (1 tỷ rows) | Setup complexity |
|---|---|---|---|---|
| ClickHouse | OLAP columnar | Analytics, logging, metrics | 10-50ms | Trung bình |
| PostgreSQL | OLTP row-based | Transactional, app backend | 1000ms+ (full scan) | Dễ |
| TimescaleDB | Hybrid time-series | IoT, monitoring có time dimension | 50-200ms | Dễ (PostgreSQL extension) |
| Apache Druid | OLAP real-time | Sub-second dashboard, high cardinality | 20-100ms | Phức tạp |
| Apache Pinot | OLAP real-time | User-facing analytics, LinkedIn scale | 10-50ms | Phức tạp |
| Amazon Redshift | OLAP columnar | Enterprise data warehouse | 100-300ms | Phức tạp (AWS) |
Triển khai thực tế: Logging platform
Một setup điển hình cho log aggregation (nginx, app logs) với ClickHouse:
CREATE TABLE nginx_logs (
timestamp DateTime64(3),
level LowCardinality(String),
service LowCardinality(String),
message String,
trace_id String,
duration_ms UInt32,
http_code UInt16,
client_ip String
) ENGINE = MergeTree()
PARTITION BY toDate(timestamp)
ORDER BY (service, level, timestamp, trace_id)
TTL timestamp + INTERVAL 30 DAY
SETTINGS index_granularity = 8192, max_bytes_to_merge_at_max_space_in_pool = 2147483648;
Partition theo ngày giúp drop old data nhanh (DETACH PARTITION). ORDER BY tối ưu cho filter theo service + level + timestamp. TTL tự động xóa dữ liệu cũ hơn 30 ngày. index_granularity = 8192 phù hợp với log volume lớn (mỗi granule ~8KB dữ liệu nén). max_bytes_to_merge_at_max_space_in_pool tránh merge quá lớn gây OOM.
Kết nối từ ứng dụng và ingest data
ClickHouse hỗ trợ nhiều client: Python (clickhouse-connect), Go (clickhouse-go), Java (JDBC), Node.js, Rust, .NET. HTTP interface cũng sẵn sàng cho curl hoặc any HTTP client — nên bạn có thể push logs bằng Fluent Bit, Vector, hoặc Telegraf.
Ví dụ Python insert batch (batch size 10k-100k rows để tối ưu):
from clickhouse_connect import get_client
client = get_client(host='localhost', port=8123, username='default', password='')
data = []
for i in range(50000):
ts = datetime.now() - timedelta(seconds=i)
data.append((ts, 'info', 'api', f'request {i} completed', f'trace-{i}', 25 + i%20, 200, '192.168.1.'+str(i%255)))
client.insert('nginx_logs', data, column_names=['timestamp','level','service','message','trace_id','duration_ms','http_code','client_ip'])
Materialized View cho real-time aggregation
ClickHouse Materialized View là công cụ mạnh mẽ để tính toán trước (pre-aggregate) dữ liệu khi insert — giúp query dashboard cực nhanh. Ví dụ: tạo view cho thống kê requests mỗi phút mỗi service:
CREATE MATERIALIZED VIEW nginx_logs_1min
ENGINE = SummingMergeTree()
ORDER BY (service, minute)
AS SELECT
toStartOfMinute(timestamp) as minute,
service,
count() as requests,
sum(duration_ms) as total_duration,
avg(duration_ms) as avg_duration
FROM nginx_logs
GROUP BY minute, service
Mỗi khi dữ liệu mới được insert vào nginx_logs, materialized view tự động cập nhật aggregation tương ứng. Khi bạn query view này để hiển thị trên Grafana, kết quả trả về ngay lập tức vì đã được pre-aggregate — không cần scan toàn bộ bảng logs.
Khi nào KHÔNG nên dùng ClickHouse
ClickHouse không phù hợp cho: transactional workloads (ACID), frequent point updates/deletes, low-latency key-value lookups, hay dữ liệu dưới 100GB (overhead không đáng). Trong các trường hợp này, PostgreSQL hoặc Redis vẫn tốt hơn. Ngoài ra, ClickHouse không hỗ trợ JOIN phức tạp giữa nhiều bảng lớn (>100GB mỗi) vì không có broadcast hash join — cần thiết kế schema cẩn thận.
