Mengapa ClickHouse Unggul dalam Perang Observability

• Tidak seperti pengalaman grep pada sistem kecil, log menjadi data yang paling sulit ditangani dalam observability ketika layanan dan konsumennya bertambah, karena bertumpuk dengan volume besar, tidak terstruktur, dan kueri yang sulit diprediksi
• ClickHouse berawal sebagai DB untuk analisis clickstream, tetapi sangat cocok dengan pola penggunaan log: volume tinggi, append-only, berurutan berdasarkan waktu, dan pembacaan berbasis agregasi
• Penyimpanan berbasis kolom memungkinkan hanya kolom yang diperlukan saja dibaca, dan pada data observability nyata menunjukkan rasio kompresi 10–14x, berbanding dengan Elasticsearch yang hanya 2–3x
• Pada skala 1 TB/hari, banyak stack masih bisa digunakan, tetapi saat naik ke 5 TB/hari dan 10 TB/hari, Elasticsearch·LGTM·Datadog mengalami perubahan besar pada arsitektur atau biaya, sementara ClickHouse umumnya cukup berkembang dengan menambah shard
• ClickHouse memang menuntut desain skema awal dan kompleksitas engine kueri, tetapi model operasionalnya tidak banyak terguncang meski data tumbuh berkali-kali lipat

---

Mengapa log sulit dalam observability

• Pengembang memiliki ekspektasi tinggi terhadap pencarian log karena terbiasa menangani log dengan cepat di sistem kecil menggunakan grep, jq, tail -f
• Pendekatan itu bekerja baik ketika sistem masih kecil, volume log sedikit, dan orang yang mengueri adalah orang yang menulis baris log tersebut
• Saat skala membesar, schema drift, ledakan cardinality, konsumen lintas tim, dan kebutuhan dashboard muncul secara bersamaan
• Penulis dan pengguna log bukan hanya pengembang
  • Tim dukungan pelanggan harus menemukan kejadian seperti pembayaran gagal milik pengguna tertentu
  • Tim data bisa membuat dashboard bisnis di atas baris log yang sewaktu-waktu dapat diubah oleh backend engineer
  • Penanggung jawab on-call berharap kotak pencarian langsung bekerja tanpa harus mempelajari bahasa kueri baru atau pola indeks
• Secara teknis, volume datanya besar, bentuknya tidak teratur, dan sulit memprediksi jenis kueri apa yang akan masuk
• Pengembang menginginkan respons instan, operasi ad hoc, dan skema longgar, sedangkan pengguna nonteknis menginginkan dashboard yang stabil dan UI yang toleran

Struktur ClickHouse yang cocok untuk log

• ClickHouse dibuat di Yandex untuk menangani kueri analitis berskala besar pada data clickstream
• Meski tidak dirancang khusus untuk observability, data clickstream dan data observability punya banyak kemiripan
  • data dalam jumlah besar
  • penulisan yang berpusat pada append
  • berfokus pada urutan waktu
  • pembacaan yang dominan berupa agregasi
  • sesekali perlu menemukan record tertentu
• Cara operasionalnya juga punya beberapa pilihan
  • Bisa dijalankan langsung dengan Helm chart
  • Bisa memakai plugin ClickHouse untuk Grafana, web UI bawaan, atau frontend buatan sendiri
  • Bisa memasukkan data OTLP langsung lewat ClickHouse exporter di OpenTelemetry Collector sekaligus menyerahkan pengelolaan skema awal
• Dirancang untuk memindai puluhan miliar baris dan mengumpulkan data dalam jumlah sangat besar
• Bahasa kuerinya bukan bahasa khusus baru, melainkan SQL

Perbedaan yang diciptakan oleh penyimpanan kolom dan kompresi

• Secara bentuk data, log sangat dekat dengan append-only
  • Baris log tidak diperbarui
  • Penghapusan individual hampir tidak pernah dilakukan, dan penghapusan biasanya dilakukan massal saat masa retensi berakhir
  • Umumnya datang dalam urutan waktu, tetapi tidak sepenuhnya terurut
• Pola pembacaannya berubah drastis saat insiden atau analisis terjadi
  • Bisa tidak dilihat siapa pun selama berhari-hari, lalu saat insiden ingin memindai miliaran entri dalam hitungan detik
  • Sering kali perlu melihat banyak field dalam rentang waktu sempit, atau melakukan agregasi dengan beberapa filter dalam rentang waktu luas
  • Pola seperti mencari satu baris berdasarkan ID tertentu, seperti pada DB transaksional, jarang terjadi
• DB berorientasi baris seperti Elasticsearch, Postgres, dan MySQL menyimpan semua field dari satu baris log bersama-sama
  • Meski hanya butuh 3 dari 40 field, disk tetap harus membaca 40 field itu
• ClickHouse menyimpan setiap kolom secara terpisah
  • Kueri yang hanya memakai timestamp, service, status_code akan membaca kolom-kolom itu saja
  • Pada data observability yang punya puluhan atribut tetapi kueri tertentu hanya memakai 3–4 kolom, perbedaan volume baca menjadi besar
• Data kolom mudah dikompresi karena nilai-nilai dalam kolom yang sama cenderung mirip
  • Kolom service_name bisa saja hanya memiliki ratusan string unik meski total barisnya miliaran
  • Pada data observability nyata, rasio kompresi 10–14x sering terlihat
  • Ini sangat kontras dengan Elasticsearch yang biasanya hanya 2–3x

Pada 1 TB/hari, sebagian besar stack masih memungkinkan

• Pada skala 1 TB/hari, stack observability modern umumnya masih layak dipakai; ada perbedaan, tetapi belum sampai terasa menyakitkan

• Elasticsearch

  • Dapat dioperasikan dengan cluster Elasticsearch yang relatif dasar dan buffer Logstash
  • Pencarian full-text adalah kekuatan Elasticsearch, dan pada skala ini masih bekerja baik
  • Pada data campuran, ada risiko mapping explosion sehingga dynamic mapping perlu dimatikan atau template harus disusun dengan hati-hati
  • Kebijakan ILM hot → warm → delete tetap penting bahkan pada skala ini
  • Biaya kira-kira berada di kisaran $6–9K per bulan

• LGTM

  • Alloy menyatukan pengumpulan data dalam satu daemon
  • Loki bekerja baik jika pengembang dididik untuk menambahkan label yang berguna
  • Mimir dan Tempo umumnya menjalankan perannya sesuai harapan
  • Biaya kira-kira berada di kisaran $3.5–5K per bulan

• Datadog

  • Pada 1 TB/hari, kegunaannya baik karena cukup memasang agent dan melihat dashboard
  • Isu seperti metered pipeline, pembedaan indexed-vs-ingested logs, dan biaya cardinality custom metrics mulai terlihat, tetapi masih bisa dikelola pada skala ini
  • Biaya kira-kira $45–75K per bulan, meski harga hasil negosiasi bisa sangat berbeda sehingga angka ini harus dilihat secara kasar
  • Logika harga Datadog pada dasarnya adalah menghemat satu engineer penuh waktu

• ClickHouse

  • Pada 1 TB/hari, ClickHouse tidak selalu lebih sederhana dibanding opsi lain
  • Ia memerlukan desain skema di awal, dan kunci ORDER BY sangat penting
  • Dengan ZSTD dan codec yang tepat, bisa mendapatkan kompresi 10–14x
  • Altinity Operator menangani keeper coordination, dan keseluruhan berjalan dalam sekitar 7 pod
  • Tidak ada PromQL native; alur kerja metrik melewati plugin Grafana atau chproxy dan adapter
  • Biaya kira-kira berada di kisaran $1.5–2.5K per bulan

Pada 5 TB/hari, perbedaan struktur mulai melebar

• Pada 5 TB/hari, kurva pertumbuhan pada sebagian besar stack menjadi lebih curam, dan jarak dengan ClickHouse mulai terlihat jelas

• Elasticsearch

  • Kafka praktis menjadi keharusan
  • Jika menulis langsung ke Elasticsearch, cluster bisa tumbang saat lonjakan trafik karena bulk reject dan backpressure
  • Dengan target shard 50GB, termasuk replica, akan terbentuk sekitar 200 shard per hari, dan ukuran cluster state sendiri menjadi masalah
  • Searchable snapshot dan frozen tier membuat lisensi komersial Elastic nyaris wajib
  • Biaya kira-kira $40–55K per bulan sebelum lisensi

• LGTM stack

  • Berubah menjadi mode microservices dengan lebih dari 65 pod dan tiga sistem terpisah yang harus dioperasikan
  • Masing-masing sistem memiliki compaction pipeline, hash ring, dan memcached tier sendiri
  • Gossip/memberlist ring menjadi perhatian operasional nyata
  • Rollout ingester memerlukan penyesuaian -ingester.autoforget-unhealthy, dan jika salah dapat menyebabkan kehilangan atau duplikasi data
  • Biaya kira-kira berada di kisaran $22–32K per bulan

• Datadog

  • Kompleksitas operasional rendah karena tidak perlu mengelola server sendiri
  • Sebagai gantinya, mulai dibutuhkan tim pipeline khusus untuk menekan biaya Datadog
  • Muncul mekanisme seperti exclusion filter, sampling rule, cardinality cap, dan tag allow-list
  • Biaya kira-kira berada di kisaran $180–350K per bulan, tergantung seberapa agresif tim pipeline bekerja
  • Hubungannya menjadi seperti harus meneliti dokumen tagihan penyedia SaaS untuk mengurangi biaya

• ClickHouse

  • Perubahan terbesarnya adalah menambah shard
  • Operator, engine kueri, bahasa kueri, dan mental model tetap sama
  • Redistribusi setelah penambahan shard dilakukan manual; kebanyakan tim mengakalinya dengan pre-provisioning atau weighting pada Distributed table
  • Materialized view untuk rollup dashboard berubah dari sekadar bagus untuk dimiliki menjadi nyaris wajib
  • Biaya kira-kira berada di kisaran $7–11K per bulan

Pada 10 TB/hari, model operasional mulai benar-benar bercabang

• 10 TB/hari adalah skala di mana banyak solusi mulai kesulitan menanggung beban operasional

• Elasticsearch

  • Biasanya akan mengoperasikan 3 cluster Elasticsearch terpisah untuk logs, metrics, dan APM, lalu menggabungkannya dengan Cross-Cluster Search
  • Biaya NVMe pada hot tier mendominasi tagihan
  • Pada skala ini tim mulai serius mengevaluasi alternatif, dan banyak migrasi ClickHouse belakangan juga muncul dari titik ini
  • Biaya kira-kira $95–140K per bulan di luar lisensi komersial
  • Mengoperasikan Elasticsearch pada skala ini benar-benar memerlukan ahli yang sesungguhnya

• LGTM

  • Membutuhkan sekitar 180+ pod, konfigurasi zone-aware, split-and-merge compaction, limit per tenant, dan shuffle sharding untuk mencegah noisy neighbor
  • Hampir pasti memerlukan tim platform observability khusus beranggotakan 3–5 orang
  • Biaya kira-kira berada di kisaran $55–85K per bulan

• Datadog

  • Masih mudah dalam arti tidak ada server yang harus dioperasikan sendiri, tetapi tagihan bulanan bisa mencapai angka 6 hingga 7 digit
  • Organisasi kemungkinan besar akan membentuk tim pipeline praproses untuk menekan tagihan
  • Banyak perusahaan pada skala ini memakai konfigurasi hibrida: Datadog untuk APM dan metrik bernilai tinggi, sementara log dipindahkan ke self-hosted
  • Target self-hosted itu makin sering adalah ClickHouse
  • Hasilnya adalah struktur di mana kesederhanaan Datadog, kompleksitas pipeline, dan stack self-hosted kedua hidup bersamaan
  • Biayanya sangat bervariasi dan bisa lebih dari $1M per bulan

• ClickHouse

  • Gambaran dasarnya tetap sama seperti konfigurasi 1 TB/hari; bedanya hanya shard-nya lebih banyak
  • Materialized view untuk rollup bukan lagi pilihan, melainkan keharusan
  • Kesalahan desain skema yang dibuat 2 tahun sebelumnya bisa terasa sangat menyakitkan pada skala ini
  • Redistribusi setelah penambahan shard tetap manual
  • Sebagian besar tim melakukan pre-provisioning atau menggunakan clickhouse-copier, dual-write migration
  • Untuk ingest yang sangat bursty, Kafka menjadi berguna sebagai buffer, tetapi tidak wajib
  • Biaya kira-kira berada di kisaran $18–28K per bulan

Kriteria pemilihan

• Pada 1 TB/hari, hampir semua stack umumnya bisa berjalan, jadi pilih saja yang sudah dikenal tim
• Pertanyaan pentingnya bukan apakah ia bekerja hari ini, tetapi apakah bentuknya masih sama 2 tahun lagi ketika data naik 5x, tim menjadi 2x, dan perancang awalnya sudah pergi
• Elasticsearch dan LGTM berubah struktur saat skala membesar
• Datadog sederhana dari sisi operasional, tetapi dari sisi biaya berubah menjadi model yang memerlukan tim akuntansi dan pipeline tersendiri
• ClickHouse melebar dengan cara menambah shard
• Harganya adalah harus menerima desain skema di awal dan kompleksitas engine kueri
• Jika harga itu dibayar, pengalaman pengembang dan operator umumnya tetap terjaga meski data tumbuh lebih dari satu digit lipat

[GN⁺]

Opini di Lobste.rs

• Startup tempat saya bekerja sebentar pada 2019 menghasilkan banyak hal yang cukup mengesankan, dan saat itu mereka sempat memperlihatkan ClickHouse kepada saya; kesannya benar-benar kuat
  Sebelumnya saya mengira jarang sekali akan ada kebutuhan akan sesuatu selain PostgreSQL, tetapi ClickHouse membuat saya ingin mencobanya
  Saya juga pernah memakai ElasticSearch, InfluxDB, dan lainnya, tetapi selalu terasa kurang enak, mungkin karena masing-masing membuat bahasa kuerinya sendiri dari nol. Sebaliknya, ClickHouse mengadopsi SQL yang familier dan hanya memperluas bagian yang diperlukan dengan tepat
  Seperti produk-produk sukses pada umumnya, ClickHouse terasa punya kualitas implementasi yang baik dan perhatian terhadap pengguna, dan bahkan detail-detail kecilnya sudah disetel dengan default yang tepat
  Di perusahaan saya sekarang kami memakai HyperDX; grafik metriknya agak merepotkan, tetapi tracing bekerja cukup baik. Saya tadinya mengira tracing akan cepat menjadi alat wajib dan meningkatkan produktivitas secara besar-besaran, tetapi melihat adopsinya tidak sebesar perkiraan, sepertinya fitur itu tidak sedemikian mengubah permainan seperti yang saya bayangkan. Meski begitu, menyenangkan bahwa ClickHouse menjadi pemain inti di area ini sehingga kita tidak perlu terlalu banyak berurusan dengan hal lain

  • Dari pengalaman saya, memperkenalkan tracing ke organisasi yang selama ini bertahan hanya dengan metrik dan log adalah tanjakan yang cukup curam
    Dibutuhkan banyak evangelisasi, mengumpulkan use case, dan kerja keras untuk menunjukkan secara langsung bahwa kini ada hal-hal yang dulu tidak bisa dilakukan, serta betapa hal-hal yang dulu sulit kini menjadi jauh lebih mudah
    Secara teknis, adopsinya juga harus dibuat semulus mungkin, tetapi bergantung pada stack dan situasi, hal itu sendiri bisa menjadi upaya besar, dan biasanya beban itu jatuh pada orang yang mendorong adopsinya
    Ini tidak berbeda dari inisiatif organisasi yang luas, jadi akan membantu jika ada satu atau dua penganut sejati di dalam perusahaan yang punya kredibilitas personal dan bisa menyebarkannya
  • Saya penasaran apakah yang dimaksud adalah bahasa kueri JSON milik ElasticSearch. ElasticSearch mendukung multiple query languages, termasuk dialek SQL
    Saya tidak tahu seperti apa kualitas dukungannya, tetapi yang pernah saya pakai langsung hanya bahasa kueri JSON, dan saya baru saja tahu soal yang lainnya
    SQL sebagai bahasa kueri tidak sempurna. Menyebalkan karena clause tidak bisa diduplikasi dan tidak bisa ditulis dalam urutan arbitrer, tetapi bagaimanapun SQL adalah bahasa yang sangat bagus

• Pengalaman saya mirip dengan penulis. Skalabilitas ClickHouse luar biasa bagus, dan bahkan jika dioperasikan sendiri, rasanya lebih seperti cukup menambahkan core saja
  Biaya setup awal mungkin sedikit lebih tinggi, tetapi skemanya pada dasarnya sudah cukup ditentukan oleh ekspor OTel, jadi bisa mulai dari sana, lalu ketika butuh performa kueri lebih tinggi, tinggal mengekstrak kolom dan materialized view
  Sebagai gantinya, kekhawatiran soal scaling berkurang, semua data bisa dipakai langsung untuk analisis, dan metrik juga bisa diturunkan dari tracing
  Namun bagian lain dari puzzle ini, yaitu visualisasi, masih sangat perlu ditingkatkan. Grafana bukan pilihan optimal untuk menampilkan dan menganalisis tracing jika dibandingkan dengan alat seperti Honeycomb. Saya berharap salah satu pemain yang sudah ada akan segera menyelesaikannya, mungkin HyperDX

• Tulisan ini awalnya terasa dimulai dengan kuat lewat pembuka yang meyakinkan, tetapi ketika masuk ke bagian yang menganalisis berbagai perusahaan, ia runtuh menjadi tulisan berbentuk daftar dengan gaya LLM berupaya rendah yang kentara
  Setelah membaca ulang pembukanya dengan lebih kritis, jejak-jejak itu juga makin terlihat
  Ini pola yang makin sering saya lihat di tulisan Lobsters belakangan ini, jadi saya ingin meninggalkannya sebagai pemikiran singkat tentang pengamatan yang lebih umum, bukan menyerang tulisan tertentu
  Secara pribadi, pengalaman saya dengan alat observability tidak banyak, jadi sebagian tulisannya tetap menarik terlepas dari cara penulisannya. Namun saya juga tidak ingin mengikuti kekeliruan: mempercayai LLM pada topik yang tidak saya kenal, lalu mengatakan tulisan LLM flawed pada topik yang saya kenal
  Jadi saya tidak yakin apakah tulisan ini, atau sebagian besar tulisan serupa, bisa dipercaya secara faktual. Tampaknya jelas bahwa penulis menyerahkan sebagian besar proses berpikirnya kepada mesin, tetapi gagasan awalnya sendiri sepertinya cukup jelas
  Saat memprogram pun, gagasan yang jelas di kepala saya baru membuat saya yakin bahwa ada sesuatu yang secara mendasar terlewat setelah saya benar-benar menulis programnya lalu gagal pada pengujian edge case atau tidak lolos pemeriksaan tipe
  Menulis juga sama; jika kita tidak membangun argumen sendiri, merakit keseluruhannya, lalu mempertimbangkan sanggahan dengan saksama, menurut saya nilai yang disampaikan tidak melebihi gagasan jelas semula
  Mungkin inilah yang ingin dikatakan orang-orang yang menyarankan menulis kode dengan hanya menyimpan prompt untuk LLM masa depan
  Namun jika pemrograman atau penulisan seluruhnya seperti itu, berarti kita menyerah bukan hanya pada pemikiran, tetapi juga pada ketelitian, kesungguhan, dan rasa hormat
  Saya tidak begitu tahu apa yang sebaiknya dilakukan Lobsters soal ini. Tag vibecoding sudah terlihat seperti solusi yang kelebihan beban. Namun mungkin akan membantu jika ada tag bau LLM sebagai sinyal untuk berhati-hati terhadap kurangnya ketelitian

  • Saya juga tidak ingin menulis ini sebagai komentar tingkat atas, tetapi ketika membuka isi artikelnya, ternyata itu hanya klise ala LLM, jadi waktu yang saya habiskan membaca bagian awal terasa agak sayang
  • Dari sudut pandang orang yang pernah cukup memakai alat observability, tulisan ini terlihat cukup jelas dan masuk akal
    Argumen utamanya adalah bahwa tiap produk melakukan scaling dengan cara berbeda, dan ia menunjukkan apa yang terjadi pada tiap skala dengan diagram serta penjelasan konkret
    Kalau ada bagian yang terasa jelas-jelas menyerah pada proses berpikir, saya penasaran contohnya
  • Matthew setidaknya adalah orang yang cukup paham soal observability. Ia pernah menjadi tech lead di Braintree dan sekarang Principal di SYBO, yang dikenal lewat Subway Surfers
    Bagian yang bercampur umpatan juga sedikit banyak memperlihatkan suara pribadinya
    Jika dimasukkan ke GPTZero, hasilnya memang 71% kemungkinan LLM dan 28% campuran. Namun karena batas jumlah karakter, pembuka yang terbaca paling manusiawi dipotong
    Saya paham rasa tidak sukanya, tetapi ini tampak lebih seperti tulisan yang benar-benar ditinjau dan direvisi berulang, hanya saja tidak menyaring ekspresi yang terasa LLM atau mengoptimalkan nadanya. Sekarang, sekadar tidak memakai em dash saja tidak cukup untuk menghindari bau itu

• Saya penasaran, bagi orang-orang yang punya pengalaman dengan Honeycomb, bagaimana ia cocok dalam konteks ini
  Setahu saya Honeycomb juga memakai format penyimpanan kolumnar, dan sangat bergantung pada kompresi serta bucketing untuk melewati banyak data saat membaca. Saya memahami bahwa ia tidak memakai indeks terbalik seperti Elastic atau Datadog, dan setahu saya Datadog juga secara internal menjalankan Elastic

  • Saya ingat beberapa tahun lalu co-founder Honeycomb, Charity Majors, pernah berkata di Twitter bahwa jika ClickHouse sudah ada saat ia memulai perusahaan, mungkin mereka akan memakai itu saja
    Namun saya tidak yakin seberapa besar dua sistem itu benar-benar tumpang tindih secara konseptual. Akan menarik untuk tahu apakah domain masalahnya secara alami mengarah ke pendekatan yang mirip, dan secara pribadi saya menduga demikian

• Beberapa orang mungkin merasa tidak nyaman, tetapi penggunaan kata-kata tertentu terasa terlalu mengganggu bagi saya, jadi saya cukup melakukan find and replace dengan kata-kata yang tidak mengganggu, dan tulisannya menjadi jauh lebih baik
  Saya tidak akan mengatakan kata-kata apa itu, tetapi ungkapan tersebut makin sering dipakai secara tidak akurat dan itu mengganggu saya. Senang rasanya bisa membaca tulisan itu dengan nyaman hanya lewat pencarian dan penggantian sederhana