SQL

ClickHouse là cơ sở dữ liệu cột (column-store) mã nguồn mở tối ưu cho phân tích tốc độ cao trên hàng tỷ dòng. Bài này dựng mô hình tinh thần về OLAP vs OLTP, giải thích vì sao lưu trữ cột và vector execution khiến aggregate cực nhanh, định vị ClickHouse so với BigQuery/Snowflake và PostgreSQL, và chỉ rõ khi nào NÊN và KHÔNG NÊN dùng.

Cách ClickHouse lưu dữ liệu theo cột trên đĩa: mỗi cột một file .bin, nén LZ4/ZSTD và codec chuyên biệt, part immutable + merge nền, granule và sparse primary index qua mark file. Giải thích vì sao quét analytic cực nhanh và khác gì B-tree của OLTP.

MergeTree là trái tim của ClickHouse: ORDER BY quyết định sắp xếp và primary key thưa, PARTITION BY để prune và quản lý TTL. Bài này giải thích cơ chế insert→part→merge, các biến thể Replacing/Summing/Aggregating/Collapsing, TTL cho retention, và bẫy 'merge bất định' khi đọc dữ liệu chưa gộp.

Cách đưa dữ liệu vào ClickHouse cho đúng: INSERT theo lô lớn thay vì nhiều insert nhỏ, async insert, nạp từ file/URL/S3 với các format CSV/JSONEachRow/Parquet, và ingest streaming từ Kafka qua Kafka engine + Materialized View. Kèm nguyên tắc thiết kế schema OLAP: chọn kiểu hẹp, LowCardinality, hạn chế Nullable, denormalize và dùng dictionary.

ClickHouse nói SQL gần ANSI nhưng mở rộng bằng kho hàm tổng hợp cực mạnh: uniq/quantile xấp xỉ, combinator -If/-State/-Merge, topK, argMax, arrayJoin. Bài này còn giải thích điểm khác biệt lớn nhất — Materialized View là trigger lúc INSERT đẩy rollup incremental vào AggregatingMergeTree — và projections như một chỉ mục thay thế trong bảng.

Cách ClickHouse mở rộng ngang: ReplicatedMergeTree đồng bộ dữ liệu giữa các replica qua ClickHouse Keeper/ZooKeeper để bền vững và đọc HA; sharding chia dữ liệu theo nhiều node; Distributed engine định tuyến truy vấn scatter-gather tới các shard. Bài giải thích cluster config, sharding key, insert idempotent, GLOBAL IN/JOIN và đánh đổi nhất quán eventual — trên bối cảnh cụm phân tích log/giao dịch nhiều node.

Điều tra một dashboard chậm trên ClickHouse: từ thiết kế ORDER BY khớp mẫu truy vấn (yếu tố số một), data skipping index, PREWHERE, đến cảnh báo về mutation nặng nề, quản lý 'too many parts' và merge. Kèm cách quan sát bằng system tables, EXPLAIN, quản lý bộ nhớ, quota và các thao tác vận hành cơ bản.

Bài tổng kết đặt ClickHouse vào bối cảnh thực chiến của một ngân hàng: dashboard giám sát giao dịch/gian lận độ trễ giây, phân tích log & metrics, clickstream hành vi khách, phân tích near-real-time cho vận hành. Kèm kiến trúc tham chiếu nguồn→Kafka→ClickHouse→dashboard, bảng quyết định chọn ClickHouse vs Snowflake/BigQuery vs PostgreSQL vs Elasticsearch, và các cạm bẫy triển khai.