10 tahun open source ClickHouse
(clickhouse.com)- ClickHouse dirilis sebagai open source pada 15 Juni 2016 dan selama 10 tahun berkembang menjadi proyek database analitik open source terkemuka dengan kontribusi dari lebih dari 2.000 orang
- Bukan sekadar membuka kode, proyek ini menargetkan open source Level 3 dengan panduan kontribusi, code review, roadmap, CI, rilis, dan dokumentasi yang semuanya terbuka
- Titik awalnya adalah keterbatasan sistem analitik web berbasis MySQL, dan pengalaman dari OLAPServer serta Metrage kemudian mengarah pada pemrosesan berorientasi kolom dan desain MergeTree
- ClickHouse bukan ekstensi di atas DBMS yang sudah ada, melainkan DBMS yang diimplementasikan dari nol sejak 2009 dengan membangun representasi kolom, fungsi agregasi, table engine, kompresi, parser SQL, server·client, dan ReplicatedMergeTree secara bertahap
- Setelah memproses ratusan miliar record per hari di production internal pada 2014, ClickHouse melalui tulisan publik dan proses persetujuan internal pada 2015 sebelum akhirnya dirilis ke seluruh dunia pada 2016
10 tahun sejak dirilis sebagai open source
- ClickHouse dirilis sebagai open source pada 15 Juni 2016
- Sejak itu, lebih dari 2.000 orang telah berkontribusi, dan ClickHouse menjadi “database analitik open source paling populer”
- Tujuan utama proyek ini bukan hanya membuka kode, tetapi juga membuat proses pengembangan dan proses kontribusi seterbuka mungkin
Tingkat open source yang dituju ClickHouse
- Open source memiliki beberapa tingkat
- Level 0: Kode dibuka agar bisa dibaca, tetapi tidak lebih dari itu. Contohnya adalah publikasi bergaya arsip atau museum seperti Doom dan MS-DOS
- Level 1: Diperbarui lewat commit di repositori publik, tetapi belum tentu menerima kontribusi. Contohnya SQLite dan Ladybird
- Level 2: Menerima kontribusi, tetapi proses pengembangannya tidak transparan dan tidak sepenuhnya terbuka. Sebagian besar proyek open source aktif berada di sini
- Level 3: Memiliki panduan kontribusi, pelacakan pekerjaan, code review, roadmap pengembangan, pengujian dan CI, siklus rilis, dukungan pengguna, dan dokumentasi
- ClickHouse menargetkan open source Level 3
- Salah satu tujuannya juga adalah menjadi contoh kode dan praktik pengembangan yang bisa dijadikan rujukan oleh pengembang yang ingin membuat database baru
- Kodenya diarahkan agar modular, ortogonal, dan terdokumentasi
- Saat konsep yang kompleks diperlukan, penjelasan diberikan dari awal di komentar agar pembaca tidak harus merujuk ke buku teks, Wikipedia, atau AI
Tempat untuk pengembangan C++ dan eksperimen performa
- ClickHouse adalah salah satu repositori open source C++ yang populer, dan ditujukan sebagai tempat untuk mempelajari pekerjaan dasar seperti fitur bahasa terbaru semisal C++23, build system, continuous integration·testing, serta praktik code review
- Eksperimen pada struktur data dan optimasi performa juga menjadi cara penggunaan yang penting
- Pull Request eksperimental yang memang tidak ditujukan untuk digabungkan pun diuji dengan tingkat yang sama seperti rilis production
- Eksperimen seperti allocator memori baru, library kompresi, hash table, format data, dan algoritme pengurutan dapat divalidasi di ClickHouse
- Roadmap juga mencakup item yang eksperimental, aneh, bahkan lucu
- Semua kontributor mendapat kredit di CHANGELOG dan tabel internal database system.contributors
- Banyak kasus di mana fitur yang implementasi awalnya belum lengkap kemudian disempurnakan bersama, dan bahkan jika seluruh kode harus ditulis ulang, niat serta use case penulis awal tetap diakui
Masalah sebelum ClickHouse dan prototipe awal
- Commit pertama ClickHouse dibuat pada 29 Mei 2009 dan merupakan optimasi performa untuk mengurangi masalah fungsi libc seperti
localtime,mktime, dangmtimeyang terlalu lambat hingga muncul di profiler - Titik awalnya adalah eksperimen pemrosesan data untuk sistem analitik web
- Sistem tersebut menerima log pageview yang dikirim dari website, mirip Google Analytics
- Sistem ini memakai MySQL, pemrosesan data C++, dan struktur data C++ kustom untuk bagian yang tidak cukup ditangani MySQL
- Database MySQL menyimpan laporan pra-agregasi untuk pelanggan, sementara struktur data kustom dipakai untuk menghitung sesi pengguna dan riwayat pengguna
- Data terus bertambah dan log baru masuk secara real time; jika log per 5 menit tidak bisa diproses dalam 5 menit, keterlambatan akan terus menumpuk
- Berbagai database dan library lain juga sempat dicoba
- TokuDB, LMDB, Judy Arrays, Hadoop, LZO, QuickLZ, HyperLogLog, materi kompresi data, dan dokumentasi server event loop semuanya ditinjau
- Kebutuhan agar pengguna dapat menyusun laporan sesuka hati memperlihatkan batas laporan pra-agregasi, dan ini mendorong evaluasi database berorientasi kolom
OLAPServer dan Metrage
- Pendekatan berorientasi kolom berarti menyimpan log terstruktur yang belum diagregasi, lalu melakukan agregasi secara langsung saat pelanggan menunggu halaman dimuat
- Ekstensi MySQL seperti Infobright dan InfiniDB, serta database analitik mandiri seperti Vertica, MonetDB, dan LucidDB diuji, tetapi tidak berjalan pada beban 100 miliar record per hari dan 500 kolom
- Prototipe kustom pertama adalah OLAPServer
- Diimplementasikan pada Desember 2008 dan diterapkan pada Januari 2009
- Semua kolom disimpan dalam satu file biner per hari dan per website
- Menggunakan hash alih-alih string, dan hanya mendukung tipe integer
- Menggunakan kompresi ringan, dan diperbarui sekali sehari dengan jeda beberapa jam
- Menyediakan API untuk menentukan kolom pengelompokan, fungsi agregasi, filter, dan pengurutan, sementara query ditentukan dalam XML
- Evgenii Gatov menyelesaikan pekerjaan mengisi data agregat MySQL lama dengan cara “de-agregasi” agar menghasilkan output yang sama
- OLAPServer juga bekerja pada endpoint yang menganalisis data internet seluruh perusahaan, bukan hanya satu website, dan responsnya cukup cepat hingga analis internal memakainya sebagai pengganti MapReduce internal
- Prototipe kedua adalah Metrage
- Sekitar 50TB data menumpuk di MySQL dalam 50 shard, dan banyak struktur data kustom disimpan sebagai BLOB
- Saat agregasi, program harus membaca BLOB, menerapkan kode kustom, lalu memasukkannya kembali
- Data MySQL tidak dikompresi, dan urutan kedatangannya tidak cocok dengan urutan rentang query sehingga pembacaan juga lambat
- Metrage adalah struktur data kustom untuk agregasi inkremental yang menggunakan merge di background, dan setiap record didefinisikan sebagai struct C++ dengan metode
add,update,merge,serializeText/Binary,deserializeText/Binary
- OLAPServer adalah struktur berorientasi kolom yang belum diagregasi, sedangkan Metrage adalah struktur berorientasi baris real time dengan CRDT arbitrer
- ClickHouse lahir dengan menggabungkan kecepatan agregasi berorientasi kolom dan pembaruan real time serta lokalitas data berbasis merge tree, sambil digeneralisasi agar mendukung bahasa query dan tipe data yang sebenarnya
DBMS yang dibuat dari nol
- ClickHouse adalah salah satu contoh langka DBMS yang diimplementasikan dari nol, bukan dibangun di atas database yang sudah ada
- Commit awal pada 2009 berkaitan dengan optimasi struktur data lain dalam monorepo yang sama, dan tetap tersisa karena saat proses open source riwayatnya dipertahankan ketika repositori dipisah
- Tahap pertama implementasi DBMS baru adalah implementasi kolom di memori, dan kelas
IColumnsertaFieldyang masih dikenal hingga kini mulai muncul- Ini mungkin tampak mirip Apache Arrow, tetapi saat itu Apache Arrow belum ada
- Format berorientasi kolom lain seperti RCFile, Trevni, ORC, dan Parquet juga belum ada saat itu
- Setelah itu fungsi agregasi diperkenalkan, dan hingga kini tetap menjadi salah satu bagian terpenting ClickHouse
- Table engine juga diperkenalkan
- Pada awalnya sempat memakai nama “primary key” selama beberapa hari
- Ini memungkinkan pembacaan dan penulisan kolom di disk
- Table engine pertama mirip TinyLog yang masih ada sampai sekarang
- Untuk kompresi, awalnya digunakan QuickLZ, tetapi kemudian diganti ke LZ4 setelah membaca blog Yann Collet
Pipeline query dan implementasi SQL
- block streams adalah komponen pipeline pemrosesan data yang memproduksi, mengonsumsi, dan mentransformasikan potongan kolom dalam bentuk streaming
- Kini telah digantikan oleh Processors
- Ini menjadi dasar untuk formatting hasil dan implementasi query tabel
- Dalam commit yang sama,
StorageSystemNumbersditambahkan untuk pengujian, dan kini tetap ada sebagai tabelsystem.numbers - Pipeline query pertama adalah mencetak angka dalam TSV, dan operator relasional pertamanya adalah
LIMIT - Parser SQL awalnya mencoba boost::spirit tetapi gagal, lalu dibuat parser recursive descent
- Ada juga ide yang sempat diperkenalkan lalu dihapus, atau baru diperkenalkan kembali kemudian
- Kolom angka dengan variable-length encoding dihapus karena lambat, dan jauh belakangan diperkenalkan custom compression codec yang terpisah dari kolom
- Tipe kolom
Variantuntuk menampung nilai field arbitrer juga dihapus karena lambat, dan Variant yang lebih baik ditambahkan pada 2025 - Tipe array berukuran tetap dihapus karena kebutuhan rendah, dan kini sedang dipertimbangkan untuk ditambahkan kembali
- Ini menunjukkan prinsip pengembangan bahwa menghapus kode yang tidak perlu lebih penting daripada menambah kode baru
Penerapan production dan ReplicatedMergeTree
- Struktur tabel nyata pertama yang diuji di ClickHouse adalah tabel
hits, yang sampai sekarang juga bisa dilihat di ClickBench - Dalam proses membaca dan menulis tabel ini terlihat bahwa C++ iostreams lambat, sehingga
WriteBufferdanReadBufferdiperkenalkan dan masih digunakan sampai sekarang - Fungsi SQL pertama adalah operator aritmetika, dan darinya interpreter query
SELECTpertama diimplementasikan - Server ClickHouse diperkenalkan pada 9 Maret 2012, dan
clickhouse-clientpada 25 Maret 2012 - Bersama table engine
Log,TinyLog,Merge,Distributed, danMemory, penerapan production menjadi memungkinkan- Use case production pertamanya adalah penyimpanan potongan log untuk pemrosesan tambahan dan query global di atas log mentah
- Ini digunakan seperti antrean log persisten yang dapat di-query dengan SQL
- Setelah itu MergeTree ditambahkan
- Meski data masuk berdasarkan urutan waktu, pengurutan inkremental dilakukan di background
- Ini memungkinkan query rentang untuk satu website diproses dengan cepat
- Penerapan production yang menggantikan OLAPServer dan Metrage menjadi memungkinkan
- Pada 2012, Michael Kolupaev bergabung sebagai karyawan kedua tim dan ikut mengimplementasikan ReplicatedMergeTree
- Production diterapkan di beberapa data center lintas wilayah, dan tim infrastruktur melakukan “drills” dengan mematikan satu data center selama satu jam setiap bulan
- Semua layanan production harus memiliki replikasi multi-data center
- Pada awalnya digunakan double-write sederhana dan backfill setelah downtime
- Untuk konsistensi 100% dan pemulihan otomatis, diperlukan konsensus terdistribusi
- ReplicatedMergeTree pun diimplementasikan dengan ZooKeeper sebagai lapisan metadata
- ReplicatedMergeTree memungkinkan penerapan production ClickHouse untuk query yang berhadapan langsung dengan pengguna pada 2014
Proses menuju rilis open source
- Pada 2014, ClickHouse di production menyimpan ratusan miliar record per hari dan menjawab query real time dari pelanggan
- Data scientist internal perusahaan menghitung tren internet dengan ClickHouse, dan dokumentasi penggunaan sederhana juga dibuka
- Departemen lain seperti periklanan, e-commerce, infrastruktur, dan analitik bisnis juga mulai mencoba ClickHouse, dan memindahkan sebagian use case dari MapReduce internal, MySQL, dan Postgres
- Pada akhir 2014, ClickHouse sudah digunakan luas di dalam satu perusahaan, dan secara luar biasa CERN juga menerapkannya dalam kolaborasi eksperimen LHCb
- Juga terkonfirmasi bahwa engineer di perusahaan lain membuat sesuatu yang mirip OLAPServer atau Metrage karena database yang ada tidak menangani use case mereka dengan baik
- Pada 2015, tulisan tentang ClickHouse dan terjemahannya dipublikasikan, yang makin mengonfirmasi minat publik
- Sebelum dirilis, disiapkan daftar potensi keuntungan dan risiko untuk meyakinkan manajemen perusahaan
- Setelah mendapat persetujuan, rencana rilis, logo pertama, website pertama, tulisan blog, dan repositori Debian disiapkan, lalu ClickHouse dirilis ke seluruh dunia pada 15 Juni 2016
- Kini ClickHouse telah menjadi database analitik populer yang digunakan perusahaan-perusahaan besar di seluruh dunia
1 komentar
Opini Hacker News
Saya menemukan ClickHouse sekitar tahun 2017~2018 dan membuat proof of concept untuk menggantikan Elasticsearch, dan dalam beberapa minggu saja penggunaan storage dan jumlah kueri per detik membaik 5x
Tapi para pengelola menolaknya karena kurang dikenal dan terlihat seperti “database buatan orang Rusia”
Secara pribadi cukup menyesal karena melihat kereta itu datang begitu awal tapi tidak sempat ikut naik
Rasio kompresinya juga benar-benar gila, dan benchmark biaya penyimpanan turun sampai setara biaya S3
Lapisan storage yang sebelumnya menelan biaya jutaan dolar per bulan turun menjadi ribuan dolar per bulan
ClickHouse bukan obat untuk segala hal, tetapi jika Anda memahami bagaimana data diakses dan bisa menatanya sesuai pola itu, efisiensi yang didapat bisa luar biasa
Setahu saya ClickHouse cenderung hanya membantu untuk pencarian seperti grep
Sebagai orang yang lama memakai TimescaleDB, ClickHouse terasa sangat menyegarkan. psql itu yang terbaik, dan saya juga suka bisa mengandalkan satu sistem database untuk semuanya, tetapi pada tahap pemeliharaan migrasi dan deployment rasanya cukup menyiksa
TimescaleDB juga terasa seperti berubah bentuk di tiap versi, dan arah pengembangannya agak goyah, jadi kadang terasa seperti produk dengan kualitas alpha
Saya masih memikirkan apakah akan memperbesar mirror ClickHouse dengan PeerDB, atau men-deploy-nya secara terpisah tanpa lapisan rentan tambahan
Saya penasaran apakah Anda memang cenderung tidak merekomendasikan TimescaleDB sama sekali. PostgreSQL adalah bagian paling solid di stack kami saat ini, jadi saya jelas ingin menghindari penderitaan software berkualitas alpha
Di sisi DuckDB juga ada pekerjaan pg_duckdb, dan ada juga tempat seperti Xata
Sebagai catatan, saya bekerja di ParadeDB
Mesin metrik dan autoscaling Cloud 66 melewati 5 iterasi sebelum akhirnya menetap di ClickHouse: Redis, Cassandra, implementasi sendiri dengan Ruby+RabbitMQ, implementasi sendiri dengan Go+RabbitMQ, lalu ClickHouse
Setiap kali kami menabrak batas tertentu atau beban optimasi yang tidak sanggup ditanggung, sementara ClickHouse sangat stabil selama 4 tahun terakhir
Baru setelah mengganti Loki dengan ClickHouse, stack observability kami akhirnya terasa “pas”. Sangat kuat untuk log dan kueri analitik umum
Selain sebagai database OLAP yang bagus, konektor bawaan untuk mengambil data dari sumber jarak jauh benar-benar mengubah permainan
Anda bisa mengatur impor otomatis berkala dari folder S3 yang berisi file Parquet/JSON, dan juga bisa terhubung langsung ke Postgres
Di data warehouse sebuah surat kabar berukuran menengah, kami mengganti kombinasi Druid+Postgres+Trino dengan satu node ClickHouse besar, dan tidak pernah menoleh ke belakang
Jauh lebih cepat, lebih praktis, dan jauh lebih sedikit perawatannya
Saya sangat suka ClickHouse dan performanya luar biasa. Saya memang harus menyetel beberapa kueri di sana-sini demi performa, tetapi secara keseluruhan hasilnya melebihi ekspektasi
Awalnya saya membangun pipeline ingestion real-time untuk menangani load inkremental besar, karena Redshift yang kami pakai sebelumnya mahal dan relatif lambat
Sejauh ini ClickHouse mampu menangani banyak data dan transformasi besar dengan mudah, jadi pipeline itu tidak lagi diperlukan
Satu-satunya masalah adalah pada konfigurasi default ada fitur tracing yang cukup berat menyala, dan itu sangat menurunkan performa pada perangkat yang relatif kecil
Setelah itu kami melakukan scale-up dan sekarang ini menjadi inti stack data kami
Kalau skalanya benar-benar sangat besar mungkin saya akan memilih yang lain, tetapi selama masih di level beberapa node, kompleksitasnya masih bisa dikelola dan enak dipakai
“Anda bisa membuka pull request sebagai eksperimen tanpa harus menargetkan merge, dan tetap mendapat tingkat pemeriksaan yang sama seperti rilis produksi. Menemukan allocator memori baru, library kompresi, hash table, format data, atau algoritme pengurutan baru? Bawa ke ClickHouse dan ia akan mengungkap semuanya sampai detail terdalam” — ini luar biasa
Termasuk kernel Linux, pada dasarnya bug ditemukan di mana-mana
Ada fuzzer yang sangat ketat, beberapa fuzzer berjalan di berbagai level, dan pengujian dijalankan dengan kombinasi konfigurasi yang jumlahnya tidak masuk akal
Angka terakhir yang saya dengar sekitar setahun lalu adalah satu eksekusi CI penuh memakan sekitar 400 jam untuk satu commit saja
Jadi dalam arti yang baik, ini memang cukup gila
Menarik bahwa tulisan blog itu memasukkan SQLite dan Ladybird ke dalam spektrum, tetapi tidak menyebut pesaing open source utama, yaitu DuckDB
Saya setuju bahwa yang membangun kepercayaan adalah tiga tahap itu
Namun untuk bisa berkelanjutan di era database hasil vibe coding, mereka perlu menemukan model bisnis baru
Saat mengueri kolom yang tidak diindeks, ClickHouse bisa dengan mudah 10x lebih cepat daripada DuckDB yang mengueri Parquet, dan saat menyentuh primary key, perbedaannya praktis tidak sebanding
Ada banyak tulisan yang membandingkan keduanya, tetapi secara realistis ClickHouse dan DuckDB berada di wilayah yang benar-benar berbeda
DuckDB adalah mesin analitik yang kuat, sedangkan ClickHouse adalah sistem manajemen database penuh dengan replikasi, mesin MergeTree, dan seterusnya
Kebanyakan orang tidak punya masalah skala sebesar itu, tetapi ketika itu muncul, perbedaannya besar
Agak disayangkan bahwa halaman itu enggan mengatakan bahwa “pemrosesan data untuk sistem analitik web mirip Google Analytics” sebenarnya dipakai di Yandex
Mungkin mereka memang tidak ingin mengiklankan perusahaan itu, tetapi saya kurang paham kenapa itu harus dianggap menyedihkan
ClickHouse adalah game changer di beberapa perusahaan tempat saya pernah bekerja. Ini mengingatkan saya pada episode adopsi Rust di podcast Rust in Production
https://open.spotify.com/episode/0TBKDUhO0KihBxEzZqnQx1