ClickHouse

Co to jest ClickHouse i do czego służy?

ClickHouse: open-source kolumnowy database management system (OLAP). Yandex, 2016. Przeznaczony do real-time analytics na ogromnych danych. Główne cechy: Columnar storage — dane przechowywane kolumna po kolumnie. Przy zapytaniu SELECT sum(amount) FROM orders — czyta tylko kolumnę amount, nie całe wiersze. 10-100x mniejszy I/O dla analytical queries. Vectorized execution — przetwarza dane w blokach (SIMD). Data compression — LZ4/ZSTD compression per kolumna. Dane tej samej kolumny są podobne -> wysoka kompresja (10-20x). MergeTree engine: podstawowy silnik ClickHouse. Dane przechowywane posortowane (ORDER BY). Merge w tle (jak LSM tree). Primary key (sparse index) — co N wierszy entry. Granule size (8192 wierszy) — minimalna jednostka read. Use cases: Log Analytics — Cloudflare przetwarza 6M req/s do ClickHouse. Real-time dashboards — Grafana datasource. Business Intelligence (BI). Event analytics (Posthog, Amplitude alternatywa). Time-series analytics. Ad-click analysis (Yandex pierwotne zastosowanie). E-commerce analytics. Performance: 1 mld wierszy w sekundy. Agregacje na miliardach wierszy w milliseconds. Benchmarki: ClickHouse szybszy niż BigQuery, Redshift i Snowflake dla OLAP queries.

ClickHouse vs PostgreSQL vs BigQuery — kiedy co wybrać?

PostgreSQL (OLTP): Row-based storage. Dobry dla transakcyjnych operacji (INSERT/UPDATE/DELETE). Point lookups (WHERE id = X). ACID transakcje. Joins (małe-średnie). Słaby dla analytical aggregations na miliardach wierszy. ClickHouse (OLAP): Column-based storage. Idealny dla analytical queries. COUNT, SUM, AVG, GROUP BY na miliardach wierszy. Niedobry dla transakcji i point lookups. Brak UPDATE (append-only + mutations). Joins działają ale nie są mocną stroną. BigQuery (Google): serverless OLAP. Pay per query (per TB processed). Standard SQL. Dobrze integruje się z ekosystemem GCP. Drogi przy dużym query volume. Snowflake: cloud data warehouse. Multi-cloud. Data sharing. Dobra separacja compute i storage. Droższe niż ClickHouse self-hosted. Redshift (AWS): managed data warehouse. Dobry dla AWS-native. PostgreSQL-compatible SQL. Apache Druid: real-time OLAP. Streaming ingestion (Kafka). Sub-second queries. Bardziej złożony niż ClickHouse. Apache Pinot (LinkedIn): real-time OLAP, podobny do Druid. StarRocks (open-source): ClickHouse-like, dobry dla joins. DuckDB: embedded analytical database. Świetny dla local analytics. Pandas replacement. Kiedy ClickHouse: self-hosted, cost-effective OLAP. High-velocity data (logs, events, metrics). Real-time analytics dashboard.

ClickHouse MergeTree family — ReplicatedMergeTree, AggregatingMergeTree?

MergeTree: podstawowy silnik. Dane posortowane po ORDER BY. Partitioning po PARTITION BY (np. miesiąc). Primary key = sparse index. Data TTL (automatyczne usuwanie starych danych). ReplicatedMergeTree: replikacja danych między węzłami. Używa ZooKeeper/ClickHouse Keeper do koordynacji. Dwa serwery z tymi samymi danymi (ha). ReplicatedMergeTree('/clickhouse/tables/{shard}/{table}', '{replica}'). SummingMergeTree: automatycznie sumuje wartości przy merge. Dla pre-aggregated data. Dobry dla metryki/counters. AggregatingMergeTree: przechowuje stany agregacji (częściowe wyniki). Materialized views z AggregatingMergeTree. Szybkie pre-aggregations bez dodatkowych zapytań. CollapsingMergeTree: do aktualizacji danych. Sign column (+1 = insert, -1 = delete). Usuwa pary podczas merge. ReplacingMergeTree: ostatni wiersz per PK jest zachowany po merge. Soft deletes/updates. Materialized Views w ClickHouse: automatycznie aktualizowana przy INSERT. Transformacja danych przy ingestion. Pre-aggregation — count/sum/avg materialized. MV + AggregatingMergeTree + AggregateFunction(sum, Float64). Zapytanie na MV jest szybsze niż na raw data. Projection: alternatywa dla Materialized View. Automatycznie utrzymywana. Dobra dla pre-sorted data w innym porządku.

Jak ładować dane do ClickHouse — batch vs streaming?

Batch Insert: ClickHouse jest zoptymalizowany dla dużych insertów. Optymalny batch size: 10K-1M wierszy. Zbyt małe inserty: overhead per-part. Wiele małych insertów -> too many parts error. INSERT INTO table VALUES (...), (...), (...) — jeden duży batch. OLTP do ClickHouse: nie insertuj row-by-row. Buffer Engine: buffering insertów w pamięci. Po N wierszach lub M sekundach -> flush do main table. Ochrona przed too many parts. Kafka Integration (native): CREATE TABLE kafka_queue ENGINE = Kafka() SETTINGS kafka_broker_list = '...', kafka_topic_list = '...', kafka_group_name = '...', kafka_format = 'JSONEachRow'. Materialized View: Kafka engine -> MV -> main table. Automatyczny streaming ingestion. ClickHouse + Kafka: popularna kombinacja. Debezium -> Kafka -> ClickHouse. HTTP interface: POST /query z JSONEachRow lub CSV. Wiele SDK (Python, Go, Java, Node). clickhouse-client (CLI). Native protocol: bardziej efektywny niż HTTP. Compression. Asynchronous inserts (ClickHouse 22.x+): server buforuje małe inserty. Dobry dla high-frequency small inserts (IoT). async_insert=1, wait_for_async_insert=0. File import: clickhouse-client --query 'INSERT INTO ... FORMAT CSV' plik data.csv. HDFS, S3 integrations.

ClickHouse w produkcji — sharding, replikacja, monitoring?

Architektura produkcyjna: Shard — poziomy podział danych. Replika — kopia sharrda (HA). Typowo: 2 repliki per shard. Distributed Engine: wirtualna tabela łącząca shardy. SELECT na Distributed -> wysyła do wszystkich shardów -> merge wyników. Sharding key: PARTITION BY lub shard_by w distributed table. Konfiguracja klastra: config.xml z cluster definition. Shard -> repliki -> host/port. ZooKeeper/ClickHouse Keeper: koordynacja replikacji. ClickHouse Keeper: wbudowany, zastępuje ZooKeeper. ClickHouse Cloud: managed ClickHouse. Serverless. Auto-scaling. Object storage (S3) backend. Altinity.Cloud: managed ClickHouse na AWS/GCP. Tinybird: ClickHouse-as-a-service z API layer. Monitoring: system.metrics — current metrics. system.asynchronous_metrics — background metrics. system.events — cumulative events. system.query_log — historia zapytań. Prometheus integration. Grafana ClickHouse datasource. Typowe problemy: too many parts — zbyt częste inserty. Rozwiązanie: batch inserts lub async_insert. Memory limit exceeded — zbyt duże zapytanie. Rozwiązanie: limit memory per query. Part pruning nie działa — WHERE nie na partition key. Posthog: open-source analytics platform. ClickHouse jako storage. Alternatywa Amplitude/Mixpanel dla product analytics.

Wyślij zapytanie