ClickHouse’un Observability Savaşlarında Öne Geçmesinin Nedenleri

• Loglar, küçük sistemlerdeki grep deneyiminden farklı olarak, servisler ve tüketiciler arttıkça yüksek hacimli, düzensiz ve öngörülemez sorguların üst üste binmesiyle Observability’de yönetilmesi en zor veri türlerinden biri haline gelir
• ClickHouse, clickstream analizi için bir DB olarak başlamış olsa da logların yüksek hacimli, ekleme ağırlıklı, zaman sıralı ve agregasyon okuma kullanım kalıplarıyla iyi örtüşür
• Sütun odaklı depolama, yalnızca gerekli sütunların okunmasını sağlar; gerçek Observability verilerinde 10–14x sıkıştırma oranı göstererek Elasticsearch’ün 2–3x oranıyla karşıtlık oluşturur
• 1 TB/gün ölçeğinde birden fazla stack çalışabilir; ancak 5 TB/gün ve 10 TB/gün seviyelerine çıkıldıkça Elasticsearch, LGTM ve Datadog’un mimarisi ya da maliyeti ciddi biçimde değişirken ClickHouse çoğunlukla shard ekleyerek ölçeklenir
• ClickHouse başlangıçta şema tasarımı ve sorgu motoru karmaşıklığı gerektirir; ancak veri hacmi bir veya iki basamak büyüse bile operasyon modeli büyük ölçüde sarsılmaz

---

Logların Observability’de zor olmasının nedeni

• Geliştiriciler küçük sistemlerde grep, jq, tail -f ile logları hızlıca ele aldıkları deneyimden dolayı log aramadan yüksek beklentiye sahiptir
• Bu yaklaşım, sistem küçükken, log hacmi azken ve sorgulayan kişi log satırlarını bizzat yazmışken iyi çalışır
• Ölçek büyüdüğünde şema drift’i, kardinalite patlaması, ekipler arası tüketiciler ve dashboard gereksinimleri aynı anda ortaya çıkar
• Logları kullananlar yalnızca geliştiriciler değildir
  • Müşteri destek ekibi, belirli bir kullanıcının başarısız ödemesi gibi olayları bulmak zorundadır
  • Veri ekibi, backend mühendisinin değiştirebileceği log satırlarının üzerine iş dashboard’ları kurabilir
  • On-call sorumlusu, yeni bir sorgu dili veya indeks pattern’i öğrenmeden arama kutusunun hemen çalışmasını bekler
• Teknik olarak veri hacmi büyüktür, biçimi düzensizdir ve hangi sorguların geleceğini öngörmek zordur
• Geliştiriciler anındalık, keyfi işlemler ve gevşek şema ister; teknik olmayan kullanıcılar ise kararlı dashboard’lar ve toleranslı bir UI ister

ClickHouse’un loglara uygun yapısı

• ClickHouse, Yandex’te clickstream verileri üzerinde büyük ölçekli analitik sorguları işlemek için geliştirildi
• Observability’ye özel olarak tasarlanmış değildir; ancak clickstream ve Observability verilerinin birçok benzer yönü vardır
  • Büyük veri hacmi
  • Ekleme ağırlıklı yazma
  • Zaman sırası merkezli yapı
  • Agregasyon okumaları ağırlıklı kullanım
  • Zaman zaman belirli bir kaydı bulma ihtiyacı olan kullanım kalıbı
• Operasyon tarafında da çeşitli seçenekler vardır
  • Helm chart ile doğrudan çalıştırılabilir
  • Grafana’nın ClickHouse eklentisi, kendi web UI’ı veya kendi geliştirdiğiniz frontend kullanılabilir
  • OpenTelemetry Collector’ın ClickHouse exporter’ı ile OTLP verileri doğrudan aktarılabilir ve ilk şema yönetimi ona bırakılabilir
• Milyarlarca satırı taramak ve çok büyük miktarda veri toplamak üzere tasarlanmıştır
• Sorgu dili yeni ve özel bir dil değil, SQL’dir

Sütun odaklı depolama ve sıkıştırmanın yarattığı fark

• Loglar veri yapısı gereği append-only’ye yakındır
  • Log satırları güncellenmez
  • Tekil silme neredeyse yoktur; saklama süresi dolduğunda toplu silme yapılır
  • Genellikle zaman sırasıyla gelirler, ancak tamamen sıralı değildirler
• Okuma kalıpları, arıza veya analiz anlarında patlayıcı biçimde değişir
  • Günlerce kimse bakmayabilir; ancak bir arıza sırasında milyarlarcasını birkaç saniye içinde taramak istenir
  • Dar bir zaman aralığında birden çok alanı incelemek veya geniş bir zaman aralığında birkaç filtreyle agregasyon yapmak sık görülür
  • Transaction DB’lerdeki gibi belirli bir ID’ye ait tek bir satırı bulma kalıbı nadirdir
• Elasticsearch, Postgres, MySQL gibi satır odaklı DB’ler bir log satırındaki tüm alanları birlikte saklar
  • 40 alanın yalnızca 3’ü gerekse bile diskten 40 alan okunur
• ClickHouse her sütunu ayrı saklar
  • Yalnızca timestamp, service, status_code kullanan bir sorgu sadece bu sütunları okur
  • Onlarca özellik olsa da belirli bir sorgunun yalnızca 3–4 sütun kullandığı Observability verilerinde okuma miktarı farkı büyür
• Sütun verileri, aynı sütundaki değerler birbirine benzediği için iyi sıkıştırılır
  • service_name sütununda milyarlarca satırda bile benzersiz string sayısı birkaç yüz olabilir
  • Gerçek Observability verilerinde 10–14x sıkıştırma oranı sık görülür
  • Bu, Elasticsearch’ün 2–3x oranıyla belirgin biçimde ayrışır

1 TB/gün seviyesinde çoğu stack mümkündür

• 1 TB/gün ölçeğinde modern Observability stack’leri genel olarak kullanılabilir durumdadır; farklar olsa da henüz acı verici düzeyde değildir

• Elasticsearch

  • Görece temel bir Elasticsearch cluster’ı ve Logstash buffer’ı ile işletilebilir
  • Full-text search Elasticsearch’ün güçlü yanıdır ve bu ölçekte iyi çalışır
  • Karma verilerde mapping explosion riski vardır; bu yüzden dynamic mapping’i kapatmak veya template’leri dikkatli ayarlamak gerekir
  • ILM politikası olan hot → warm → delete bu ölçekte de zorunludur
  • Maliyet yaklaşık aylık $6–9K seviyesindedir

• LGTM

  • Alloy, toplama işini tek bir daemon altında birleştirir
  • Loki, geliştiriciler faydalı label’lar ekleyecek şekilde eğitildiğinde iyi çalışır
  • Mimir ve Tempo genel olarak beklenen rolleri yerine getirir
  • Maliyet yaklaşık aylık $3.5–5K seviyesindedir

• Datadog

  • 1 TB/gün seviyesinde agent’ı kurup dashboard’a bakmak kadar kullanımı kolaydır
  • Metered pipeline, indexed-vs-ingested logs ayrımı ve custom metrics cardinality maliyeti gibi sorunlar görünür; ancak bu ölçekte yönetilebilir
  • Maliyet yaklaşık aylık $45–75K seviyesindedir; pazarlık fiyatları çok değiştiği için bu rakamlara geniş bir aralık olarak bakmak gerekir
  • Datadog’un fiyatlandırma mantığı, bir tam zamanlı mühendisten tasarruf ettirdiği şeklindedir

• ClickHouse

  • 1 TB/gün seviyesinde ClickHouse diğer seçeneklerden daha az karmaşık değildir
  • Başlangıçta şema tasarımı gerekir ve ORDER BY anahtarı çok önemlidir
  • ZSTD ve uygun codec’lerle 10–14x sıkıştırma elde edilebilir
  • Altinity Operator keeper coordination’ı yönetir ve tamamı yaklaşık 7 pod ile çalışır
  • Native PromQL yoktur; metrik workflow’u Grafana eklentisi veya chproxy ve adapter üzerinden geçer
  • Maliyet yaklaşık aylık $1.5–2.5K seviyesindedir

5 TB/gün seviyesinde mimari fark açılır

• 5 TB/gün seviyesinde çoğu stack’te büyüme eğrisi dikleşir ve ClickHouse ile aradaki fark daha görünür hale gelir

• Elasticsearch

  • Kafka fiilen zorunlu hale gelir
  • Doğrudan Elasticsearch’e yazıldığında trafik spike’ları sırasında bulk reject ve backpressure nedeniyle cluster düşebilir
  • 50GB target shard bazında replica’lar dahil günde yaklaşık 200 shard oluşur ve cluster state boyutunun kendisi sorun haline gelir
  • Searchable snapshot ve frozen tier nedeniyle Elastic ticari lisansı neredeyse gerekli olur
  • Maliyet lisans hariç yaklaşık aylık $40–55K seviyesindedir

• LGTM stack

  • 65’ten fazla pod ve üç ayrı sistemi işleten mikroservis moduna dönüşür
  • Her sistemin kendi compaction pipeline’ı, hash ring’i ve memcached tier’ı vardır
  • gossip/memberlist ring gerçek bir operasyon konusu haline gelir
  • ingester rollout için -ingester.autoforget-unhealthy ayarı gerekir; yanlış yapılırsa veri kaybı veya tekrarlar oluşabilir
  • Maliyet yaklaşık aylık $22–32K seviyesindedir

• Datadog

  • Sunucuları doğrudan işletmediğiniz için operasyonel karmaşıklık düşüktür
  • Buna karşılık Datadog maliyetini azaltmaya adanmış bir pipeline ekibine ihtiyaç duyulur
  • exclusion filter, sampling rule, cardinality cap, tag allow-list gibi mekanizmalar ortaya çıkar
  • Maliyet, pipeline ekibinin ne kadar agresif olduğuna bağlı olarak yaklaşık aylık $180–350K seviyesindedir
  • SaaS sağlayıcısının faturalama belgelerine bakarak maliyeti düşürmeye çalışılan bir ilişkiye dönüşür

• ClickHouse

  • En büyük değişiklik shard eklemektir
  • Operator, query engine, query language ve mental model aynı kalır
  • Shard ekledikten sonra yeniden dağıtım manueldir; çoğu ekip bunu önceden provisioning yaparak veya Distributed table weighting ile aşar
  • Dashboard rollup’ları için materialized view, olsa iyi olur seviyesinden neredeyse zorunlu hale gelir
  • Maliyet yaklaşık aylık $7–11K seviyesindedir

10 TB/gün seviyesinde operasyon modeli ayrışır

• 10 TB/gün, birçok çözümün operasyon yükünü taşımakta zorlanmaya başladığı bir ölçektir

• Elasticsearch

  • logs, metrics ve APM için üç ayrı Elasticsearch cluster’ı işletilir ve bunlar Cross-Cluster Search ile birleştirilir
  • hot-tier NVMe maliyeti faturaya hâkim olur
  • Bu ölçekte ekipler alternatifleri ciddi biçimde değerlendirmeye başlar; son dönemdeki ClickHouse migration’larının çoğu da buradan gelir
  • Maliyet ticari lisans hariç yaklaşık aylık $95–140K seviyesindedir
  • Bu ölçekte Elasticsearch işletmek için gerçek uzman gerekir

• LGTM

  • Yaklaşık 180’den fazla pod, zone-aware yapılandırma, split-and-merge compaction, tenant bazlı limitler ve noisy neighbor’ı önlemek için shuffle sharding gerekir
  • 3–5 kişilik özel bir Observability platform ekibi neredeyse zorunlu hale gelir
  • Maliyet yaklaşık aylık $55–85K seviyesindedir

• Datadog

  • İşletilecek sunucu olmaması anlamında hâlâ kolaydır; ancak aylık fatura 6–7 haneli rakamlara çıkabilir
  • Organizasyonun faturayı düşürmek için preprocessing pipeline ekibi kurma olasılığı yüksektir
  • Bu ölçekte birçok şirket Datadog’u APM ve yüksek değerli metrikler için kullanır, logları ise self-hosted yapıya taşır
  • Self-hosted hedef giderek ClickHouse olur
  • Datadog’un basitliği, pipeline karmaşıklığı ve ikinci bir self-hosted stack aynı anda var olan bir yapıya dönüşür
  • Maliyet çok değişkendir ve aylık $1M+ olabilir

• ClickHouse

  • 1 TB/gün konfigürasyonuyla temel resim aynıdır; fark daha fazla shard olmasıdır
  • Rollup için materialized view artık seçenek değil, zorunluluktur
  • 2 yıl önce yapılmış şema tasarımı hataları bu ölçekte acı biçimde ortaya çıkabilir
  • Shard ekledikten sonra yeniden dağıtım hâlâ manueldir
  • Çoğu ekip önceden provisioning yapar veya clickhouse-copier, dual-write migration kullanır
  • Çok bursty ingest için Kafka buffer olarak faydalı hale gelir; ancak zorunlu değildir
  • Maliyet yaklaşık aylık $18–28K seviyesindedir

Seçim kriterleri

• 1 TB/gün seviyesinde herhangi bir stack genel olarak çalışacağından, ekibin zaten bildiği şey seçilebilir
• Önemli soru bugün çalışıp çalışmadığı değil; 2 yıl sonra veri 5 katına, ekip 2 katına çıktığında ve ilk tasarımcı ayrıldığında da aynı formu koruyup korumadığıdır
• Elasticsearch ve LGTM, ölçek büyüdükçe mimari olarak değişir
• Datadog operasyonel olarak basittir; ancak maliyet açısından ayrı bir muhasebe ve pipeline ekibi gerektiren bir şekle dönüşür
• ClickHouse daha fazla shard ekleme yöntemiyle genişler
• Bunun bedeli, başlangıçta şema tasarımı ve sorgu motoru karmaşıklığını kabul etmektir
• Bu bedel ödendiğinde, veri bir basamak veya daha fazla büyüse bile geliştirici ve operasyon ekiplerinin deneyimi genel olarak korunur

[GN⁺]

Lobste.rs yorumları

• 2019'da kısa bir süre çalıştığım startup oldukça etkileyici şeyler üretmişti ve o sırada bana biraz ClickHouse göstermişlerdi; gerçekten güçlü bir izlenim bırakmıştı
  O zamana kadar PostgreSQL dışında bir şeye ihtiyaç duymanın nadir olacağını düşünüyordum ama ClickHouse'u denemek istedim
  ElasticSearch, InfluxDB gibi şeyleri de kullandım ama hep pek iyi gelmediler; muhtemelen her birinin sorgu dilini sıfırdan yeniden icat etmeye çalışmasındandı. ClickHouse ise tanıdık SQL'i benimsiyor ve sadece gerekli yerlerde uygun genişletmeler yapıyor
  Başarılı ürünlerde olduğu gibi ClickHouse'ta da uygulama kalitesi ve kullanıcıya özen hissediliyor; küçük ayrıntılara kadar varsayılanlar iyi ayarlanmış
  Şu anki şirkette HyperDX kullanıyoruz; metrik grafikleri biraz uğraştırıcı ama tracing oldukça iyi çalışıyor. Tracing'in hızla vazgeçilmez bir araç olup verimliliği ciddi biçimde artıracağını sanmıştım ama beklediğim kadar benimsenmemesine bakılırsa düşündüğüm kadar oyunun kurallarını değiştiren bir özellik değil galiba. Yine de ClickHouse'un bu alanda temel oyuncu hâline gelip başka şeylerle daha az uğraşmamızı sağlaması sevindirici

  • Yalnızca metrikler ve loglarla idare eden bir organizasyona tracing getirmek, deneyimime göre oldukça dik bir yokuş
    Çok fazla iç iletişim gerekir; kullanım senaryolarını toplamak ve artık daha önce yapılamayan şeylerin yapılabildiğini, zor olan işlerin ne kadar kolaylaştığını bizzat göstermek gibi zahmetli bir çaba ister
    Teknik tarafta da geçişin olabildiğince sorunsuz olması gerekir; ama stack ve duruma göre bu başlı başına büyük bir emek olabilir ve bu yük genelde benimsenmeyi iten kişinin üstüne kalır
    Geniş kapsamlı bir şirket inisiyatifinden çok da farklı değil; bu yüzden kişisel güvenilirliği olan ve şirket içinde bunu yayacak bir iki gerçek inanmış kişi olması yardımcı olur
  • ElasticSearch'ün JSON sorgu dilinden mi bahsettiğini merak ediyorum. ElasticSearch multiple query languages destekliyor; buna bir SQL lehçesi de dahil
    Bu desteğin kalitesi nasıldır bilmiyorum ama benim bizzat kullandığım tek şey JSON sorgu diliydi; diğerlerini de az önce öğrendim
    Sorgu dili olarak SQL kusursuz değil. Clause'ları tekrar edememek ve istediğin sırada yazamamak can sıkıcı ama yine de SQL çok iyi bir dil

• Benim deneyimim de yazara benziyor. ClickHouse'un ölçeklenebilirliği şaşırtıcı derecede iyi ve kendi başına işletildiğinde de daha çok çekirdek eklemek yeterli olan tarafa daha yakın
  Başlangıç kurulum maliyeti biraz daha yüksek olabilir ama şema pratikte neredeyse OTel export'u tarafından belirleniyor; oradan başlayıp, daha fazla sorgu performansına ihtiyaç duydukça kolonlar ve materialized view'lar çıkarabilirsiniz
  Karşılığında ölçek kaygınız azalıyor, tüm veriyi doğrudan analiz için kullanabiliyor ve tracing'den metrik türetmek de mümkün oluyor
  Yalnız bulmacanın diğer parçası olan görselleştirme tarafının çok daha fazla gelişmesi gerekiyor. Grafana, tracing'i göstermek ve analiz etmek için Honeycomb gibi araçlarla kıyaslandığında ideal değil. Mevcut oyunculardan birinin bunu yakında çözmesini umuyorum; belki HyperDX olabilir

• Bu yazı ilk başta ikna edici bir girişle güçlü başlıyor gibiydi ama birkaç şirketi analiz ettiği bölüme gelince belirgin biçimde düşük emekli LLM üslubu taşıyan, listevari bir metne dönüştü
  Giriş kısmını da sonra daha eleştirel okuyunca bu izler gittikçe daha görünür geldi
  Son zamanlarda Lobsters yazılarında giderek daha sık gördüğüm bir örüntü bu; tek bir yazıyı hedef almaktan çok, daha genel bir gözleme dair kısa bir not düşmek istedim
  Şahsen observability araçları konusunda çok deneyimli değilim; bu yüzden yazının bazı kısımları, yazılma biçiminden bağımsız olarak ilginç geldi. Ama aşina olmadığım konularda LLM'lere güvenip, bildiğim konularda LLM yazılarının flawed olduğunu söyleme hatasına da düşmek istemiyorum
  Bu yüzden bu yazının ya da benzerlerinin çoğunun olgusal olarak ne kadar güvenilir olduğunu gerçekten bilmiyorum. Yazarın düşünmenin büyük bir bölümünü makineye bıraktığı açıkça hissediliyor ama çıkış noktasındaki düşüncenin kendisi muhtemelen epey netti
  Programlama yaparken de kafamdaki net fikir, ancak gerçekten programı yazıp sınır durum testlerinde çuvalladığında ya da type check'ten geçemediğinde temelde eksik bir şey olduğunu bana kabul ettiriyor
  Yazı yazmak da benzer; iddiaları bizzat kurup bütünü birleştirmeden ve karşı argümanları dikkatle değerlendirmeden, başlangıçtaki net düşünceden fazlasını aktardığını düşünmüyorum
  Gelecekteki LLM'ler için sadece prompt'ları saklayarak kod yazmayı önerenlerin asıl demek istediği de herhalde burası
  Ama programlama ya da yazmanın tamamı böyle olacaksa, sadece düşünceden değil titizlikten, özenlilikten, saygıdan da vazgeçilmiş olur
  Lobsters bununla ilgili ne yapmalı bilmiyorum. vibecoding etiketi zaten aşırı yüklenmiş bir çözüm gibi görünüyor. Ama en azından titizlik eksikliğine dikkat çeken bir işaret olarak LLM kokusu etiketi faydalı olabilir

  • Ben de bunu en üst seviye yorum olarak yazmak istemezdim ama asıl yazıya girince düpedüz LLM tarzı klişeler olduğunu gördüm; bu yüzden ilk kısmı okumaya harcadığım zamana biraz üzüldüm
  • Observability araçlarını biraz kullanmış biri olarak bana oldukça açık ve makul bir yazı gibi geldi
    Ana argüman, ürünlerin farklı şekillerde ölçeklendiği ve her ölçekte neler olduğunun grafikler ve somut açıklamalarla gösterildiği yönünde
    Düşünmenin açıkça terk edildiğini hissettiğin bir yer varsa örnek duymak isterim
  • Matthew en azından observability konusunda epey bilgili biri. Braintree'de teknik liderlik yaptı, şu anda da Subway Surfers ile bilinen SYBO'da Principal
    Araya serpiştirilen küfürler de bir ölçüde kendi sesini yansıtıyor
    GPTZero'ya atınca %71 LLM olasılığı, %28 karma sonucu veriyor. Ama karakter sınırı yüzünden en insani okunan giriş kısmını kesmek zorunda kaldım
    Rahatsızlığını anlıyorum ama bu gerçekten gözden geçirilmiş ve yinelemeli biçimde düzeltilmiş bir yazı gibi duruyor; LLM benzeri ifadeleri ayıklamaktan ya da tonu optimize etmekten özellikle kaçınılmış gibiydi. Artık sadece em dash kullanmamak bu kokudan kaçmak için yetmiyor

• Honeycomb deneyimi olanların bu bağlamda onu nasıl konumlandırdığını merak ediyorum
  Bildiğim kadarıyla Honeycomb da kolon bazlı bir depolama biçimi kullanıyor ve okumada çok veriyi atlamak için sıkıştırma ile bucketing'e büyük ölçüde dayanıyor. Elastic ya da Datadog gibi ters indeks kullanan bir yaklaşım değil diye biliyorum; Datadog'un da içeride Elastic çalıştırdığını sanıyordum

  • Birkaç yıl önce Honeycomb'un kurucu ortaklarından Charity Majors'ın Twitter'da, şirketi kurdukları sırada ClickHouse olsaydı muhtemelen gidip onu kullanacaklarını söylediğini hatırlıyorum
    Yine de iki sistemin kavramsal olarak gerçekte ne kadar örtüştüğünden emin değilim. Problem alanının doğal olarak benzer bir yaklaşıma mı yönelttiğini bilmek ilginç olurdu; kişisel tahminim evet olduğu yönünde

• Bazı kişiler buna alınabilir ama belirli bazı kelimelerin kullanımı bana o kadar dikkat dağıtıcı geldi ki onları gözüme batmayan kelimelerle bul ve değiştir yapınca yazı çok daha iyi oldu
  Hangi kelimeler olduğunu söylemeyeceğim ama gittikçe daha da belirsiz kullanılan ifadeler oldukları için beni rahatsız ediyorlar. Basit bir arama-değiştirme ile yazıyı rahat okuyabilmek hoşuma gitti