Observability की जंग में ClickHouse क्यों आगे निकल रहा है

 (matduggan.com)
3 पॉइंट द्वारा GN⁺ 6 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • छोटे सिस्टम में grep जैसा अनुभव लॉग्स के साथ मिलता है, लेकिन services और consumers बढ़ने पर बड़े पैमाने, अनस्ट्रक्चर्ड और unpredictable queries एक साथ आ जाती हैं, जिससे logs Observability में संभालने के लिए सबसे कठिन डेटा बन जाते हैं
  • ClickHouse की शुरुआत clickstream analytics के लिए DB के रूप में हुई थी, लेकिन logs के usage patterns—high-volume, append-heavy, time-ordered, aggregate reads—से यह अच्छी तरह मेल खाता है
  • column-oriented storage केवल जरूरी columns पढ़ने देता है, और वास्तविक Observability डेटा में 10–14x compression ratio दिखाता है, जो Elasticsearch के 2–3x से अलग दिखता है
  • 1 TB/day के scale पर कई stacks संभव हैं, लेकिन 5 TB/day और 10 TB/day तक बढ़ने पर Elasticsearch, LGTM और Datadog की architecture या cost काफी बदल जाती है, जबकि ClickHouse मुख्यतः shards जोड़कर scale होता है
  • ClickHouse शुरुआत में schema design और query engine की complexity मांगता है, लेकिन डेटा एक या दो orders of magnitude बढ़ने पर भी operating model ज्यादा नहीं डगमगाता

Observability में logs कठिन क्यों होते हैं

  • Developers को छोटे systems में grep, jq, tail -f से logs जल्दी संभालने का अनुभव होता है, इसलिए वे log search से बहुत ज्यादा उम्मीद रखते हैं
  • वह तरीका तब अच्छा काम करता है जब system छोटा हो, logs की मात्रा कम हो, और query करने वाला व्यक्ति खुद log line लिखता हो
  • Scale बढ़ने पर schema drift, cardinality explosion, teams के बीच consumers, और dashboard requirements एक साथ पैदा होते हैं
  • Logs का इस्तेमाल सिर्फ developers नहीं करते
    • Customer support team को किसी खास user की failed payment जैसी घटनाएं ढूंढनी होती हैं
    • Data team backend engineer द्वारा बदली जा सकने वाली log lines के ऊपर business dashboards बना सकती है
    • On-call owner उम्मीद करता है कि कोई नई query language या index pattern सीखे बिना search box तुरंत काम करे
  • Technical रूप से डेटा की मात्रा बड़ी होती है, उसका format irregular होता है, और कौन-सी query आएगी यह predict करना मुश्किल होता है
  • Developers immediacy, arbitrary operations और loose schema चाहते हैं, जबकि non-technical users stable dashboards और forgiving UI चाहते हैं

ClickHouse की structure logs के लिए उपयुक्त क्यों है

  • ClickHouse को Yandex ने clickstream data पर बड़े-scale की analytical queries handle करने के लिए बनाया था
  • इसे खास तौर पर Observability के लिए design नहीं किया गया था, लेकिन clickstream और Observability data में कई समानताएं हैं
    • भारी मात्रा में data
    • append-heavy writes
    • time-order centric
    • mainly aggregate reads
    • कभी-कभी किसी specific record को खोजने वाला usage pattern
  • Operations के लिए भी कई choices हैं
    • Helm chart से सीधे run किया जा सकता है
    • Grafana का ClickHouse plugin, अपना web UI, या custom frontend इस्तेमाल किया जा सकता है
    • OpenTelemetry Collector के ClickHouse exporter से OTLP data सीधे डालकर initial schema management सौंपा जा सकता है
  • इसे अरबों rows scan करने और बहुत बड़े data volumes ingest करने के लिए design किया गया है
  • Query language कोई नई dedicated language नहीं, बल्कि SQL है

Column-oriented storage और compression से बनने वाला फर्क

  • Logs अपने data shape में append-only के करीब होते हैं
    • Log lines update नहीं की जातीं
    • Individual deletes लगभग नहीं होते, और retention period खत्म होने पर bulk delete होता है
    • आम तौर पर ये time order में आते हैं, लेकिन पूरी तरह sorted नहीं होते
  • Read pattern incidents या analysis के समय explosively बदल जाता है
    • कई दिनों तक कोई उन्हें न देखे, लेकिन incident के दौरान लोग अरबों entries को कुछ seconds में scan करना चाहते हैं
    • छोटे time range में कई fields देखना, या बड़े time range में कुछ filters के साथ aggregate करना आम है
    • Transaction DB की तरह किसी specific ID की एक row ढूंढने वाला pattern rare है
  • Elasticsearch, Postgres, MySQL जैसे row-oriented DB एक log line के सभी fields साथ में store करते हैं
    • 40 fields में से केवल 3 की जरूरत हो, फिर भी disk से 40 fields पढ़े जाते हैं
  • ClickHouse हर column को अलग store करता है
    • timestamp, service, status_code ही इस्तेमाल करने वाली query सिर्फ वही columns पढ़ती है
    • Observability data में, जहां दर्जनों attributes हो सकते हैं लेकिन कोई specific query केवल 3–4 columns इस्तेमाल करती है, read volume में फर्क बड़ा हो जाता है
  • Column data अच्छी तरह compress होता है क्योंकि एक ही column के values अक्सर एक-दूसरे से मिलते-जुलते होते हैं
    • service_name column में अरबों rows में भी unique strings कुछ सौ ही हो सकती हैं
    • वास्तविक Observability data में 10–14x compression ratio अक्सर देखने को मिलता है
    • यह Elasticsearch के 2–3x से साफ तौर पर अलग है

1 TB/day पर ज्यादातर stacks संभव हैं

  • 1 TB/day scale पर modern Observability stacks आम तौर पर usable होते हैं; फर्क होते हैं, लेकिन अभी तक दर्दनाक स्तर पर नहीं

  • Elasticsearch

    • अपेक्षाकृत basic Elasticsearch cluster और Logstash buffer से operate किया जा सकता है
    • Full-text search Elasticsearch की ताकत है, और इस scale पर यह अच्छी तरह काम करता है
    • Mixed data में mapping explosion का risk होता है, इसलिए dynamic mapping बंद करनी पड़ती है या templates सावधानी से सेट करने पड़ते हैं
    • ILM policy hot → warm → delete इस scale पर भी जरूरी है
    • Cost roughly $6–9K/month के स्तर पर है

  • LGTM

    • Alloy collection को एक single daemon में consolidate करता है
    • Loki तभी अच्छा काम करता है जब developers को useful labels लगाने के लिए train किया जाए
    • Mimir और Tempo आम तौर पर अपनी expected roles निभाते हैं
    • Cost roughly $3.5–5K/month के स्तर पर है

  • Datadog

    • 1 TB/day पर usage आसान है: agents install करें और dashboards देखें
    • metered pipeline, indexed-vs-ingested logs का distinction, और custom metrics cardinality cost के मुद्दे दिखते हैं, लेकिन इस scale पर manageable रहते हैं
    • Cost roughly $45–75K/month है, और negotiated pricing में बहुत फर्क होने से numbers को broad range की तरह देखना चाहिए
    • Datadog की pricing logic कुछ ऐसी है कि यह एक dedicated engineer बचाता है

  • ClickHouse

    • 1 TB/day पर ClickHouse दूसरे options से कम complex नहीं है
    • शुरुआत में schema design चाहिए, और ORDER BY key बहुत महत्वपूर्ण है
    • ZSTD और सही codecs से 10–14x compression मिल सकता है
    • Altinity Operator keeper coordination handle करता है, और पूरा setup लगभग 7 pods में चलता है
    • Native PromQL नहीं है, और metrics workflow Grafana plugin या chproxy और adapter से होकर जाता है
    • Cost roughly $1.5–2.5K/month के स्तर पर है

5 TB/day पर architectural फर्क दिखने लगता है

  • 5 TB/day पर ज्यादातर stacks में growth curve steep हो जाता है, और ClickHouse से gap ज्यादा स्पष्ट दिखता है

  • Elasticsearch

    • Kafka लगभग mandatory हो जाता है
    • सीधे Elasticsearch में लिखने पर traffic spikes के दौरान bulk reject और backpressure से cluster down हो सकता है
    • 50GB target shard के आधार पर, replica तक मिलाकर रोज लगभग 200 shards बनते हैं, और cluster state size खुद समस्या बन जाती है
    • searchable snapshot और frozen tier की वजह से Elastic commercial license लगभग जरूरी हो जाता है
    • Cost license से पहले $40–55K/month के स्तर पर है

  • LGTM stack

    • यह microservices mode बन जाता है, जहां 65+ pods और तीन अलग-अलग systems operate होते हैं
    • हर system में compaction pipeline, hash ring, और memcached tier होता है
    • gossip/memberlist ring वास्तविक operational concern बन जाती है
    • ingester rollout के लिए -ingester.autoforget-unhealthy tuning चाहिए, और गलती होने पर data loss या duplication हो सकता है
    • Cost roughly $22–32K/month के स्तर पर है

  • Datadog

    • Servers खुद operate नहीं करने पड़ते, इसलिए operational complexity कम रहती है
    • लेकिन Datadog cost घटाने के लिए dedicated pipeline team की जरूरत पड़ने लगती है
    • exclusion filter, sampling rule, cardinality cap, tag allow-list जैसी mechanisms आती हैं
    • Cost pipeline team की aggressiveness पर निर्भर करते हुए roughly $180–350K/month के स्तर पर है
    • रिश्ता ऐसा बन जाता है कि SaaS provider की billing documentation देखते हुए cost कम करनी पड़ती है

  • ClickHouse

    • सबसे बड़ा बदलाव shards जोड़ना है
    • operator, query engine, query language और mental model वैसे ही रहते हैं
    • Shards जोड़ने के बाद rebalancing manual है; ज्यादातर teams pre-provisioning या Distributed table की weighting से workaround करती हैं
    • dashboard rollup के लिए materialized view “nice to have” से लगभग mandatory बन जाती है
    • Cost roughly $7–11K/month के स्तर पर है

10 TB/day पर operating models अलग हो जाते हैं

  • 10 TB/day वह scale है जहां कई solutions के लिए operational load संभालना मुश्किल होने लगता है

  • Elasticsearch

    • logs, metrics और APM के लिए तीन अलग Elasticsearch clusters operate करने पड़ते हैं और उन्हें Cross-Cluster Search से जोड़ा जाता है
    • hot-tier NVMe cost bill पर हावी हो जाती है
    • इस scale पर teams alternatives को गंभीरता से evaluate करना शुरू करती हैं, और हाल के ClickHouse migrations भी काफी हद तक यहीं से आते हैं
    • Cost commercial license के अलावा roughly $95–140K/month के स्तर पर है
    • इस scale पर Elasticsearch operate करने के लिए सचमुच expert चाहिए

  • LGTM

    • लगभग 180+ pods, zone-aware configuration, split-and-merge compaction, per-tenant limits, और noisy neighbor prevention के लिए shuffle sharding चाहिए
    • 3–5 लोगों की dedicated Observability platform team लगभग जरूरी हो जाती है
    • Cost roughly $55–85K/month के स्तर पर है

  • Datadog

    • इस अर्थ में अब भी आसान है कि operate करने के लिए servers नहीं हैं, लेकिन monthly bill 6–7 digit figure बन सकता है
    • Organization billing कम करने के लिए preprocessing pipeline team बनाने की काफी संभावना रखता है
    • इस scale की कई companies Datadog को APM और high-value metrics के लिए इस्तेमाल करती हैं, और logs को self-hosted setup में ले जाती हैं
    • Self-hosted target increasingly ClickHouse बनता है
    • Structure ऐसा हो जाता है जिसमें Datadog की simplicity, pipeline complexity और दूसरा self-hosted stack साथ-साथ मौजूद होते हैं
    • Cost बहुत अलग-अलग हो सकती है और $1M+/month हो सकती है

  • ClickHouse

    • 1 TB/day setup जैसा ही basic picture रहता है; फर्क इतना है कि shards ज्यादा होते हैं
    • Rollup के लिए materialized view option नहीं, requirement बन जाती है
    • दो साल पहले की गई schema design की गलती इस scale पर दर्दनाक रूप से सामने आ सकती है
    • Shards जोड़ने के बाद rebalancing अब भी manual है
    • ज्यादातर teams pre-provisioning करती हैं या clickhouse-copier, dual-write migration इस्तेमाल करती हैं
    • बहुत bursty ingest के लिए Kafka buffer के रूप में उपयोगी हो जाता है, लेकिन mandatory नहीं है
    • Cost roughly $18–28K/month के स्तर पर है

चुनने के मानदंड

  • 1 TB/day पर कोई भी stack आम तौर पर काम कर जाता है, इसलिए team जिसे पहले से जानती है उसे चुनना ठीक है
  • अहम सवाल यह नहीं है कि आज काम करता है या नहीं, बल्कि यह है कि 2 साल बाद data 5x, team 2x हो जाए और original designer जा चुका हो, तब भी क्या वही shape बना रहेगा
  • Elasticsearch और LGTM में scale बढ़ने पर architecture बदल जाती है
  • Datadog operationally simple है, लेकिन cost के लिहाज से यह अलग accounting और pipeline team की जरूरत वाली shape में बदल जाता है
  • ClickHouse और shards जोड़ने के तरीके से फैलता है
  • इसकी कीमत यह है कि शुरुआत में schema design और query engine complexity स्वीकार करनी पड़ती है
  • यह कीमत चुकाने पर data एक order of magnitude से ज्यादा बढ़ने पर भी developers और operators का experience काफी हद तक वही रहता है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 6 시간 전
Lobste.rs की राय

  • 2019 में जिस startup में मैंने थोड़े समय काम किया था, उसने काफ़ी impressive चीज़ें बनाई थीं, और उसी दौरान उन्होंने ClickHouse थोड़ा दिखाया था—उसने सच में गहरा असर छोड़ा
    उससे पहले मुझे लगता था कि PostgreSQL के अलावा किसी और चीज़ की ज़रूरत शायद ही कभी पड़ेगी, लेकिन ClickHouse को देखकर उसे इस्तेमाल करने का मन हुआ
    ElasticSearch, InfluxDB वगैरह भी इस्तेमाल किए थे, लेकिन हमेशा कुछ ख़ास नहीं लगे; शायद इसलिए कि हर एक ने अपनी query language शुरू से नई बनाई थी। इसके उलट ClickHouse ने परिचित SQL अपनाया और जहाँ ज़रूरत थी वहीं ठीक से विस्तार किया
    सफल products की तरह ClickHouse में implementation quality और user के प्रति सोच साफ़ दिखती है, और छोटी-छोटी details तक default में सही बैठी लगती हैं
    अभी हमारी company में हम HyperDX इस्तेमाल करते हैं; metrics graph थोड़े झंझट वाले हैं, लेकिन tracing काफ़ी अच्छी चलती है। मुझे लगा था tracing जल्दी ही ज़रूरी tool बनकर productivity बहुत बढ़ा देगी, लेकिन जिस तरह adoption उम्मीद जितना नहीं हुआ, उससे लगता है कि यह उतनी game-changing capability नहीं है जितनी सोची थी। फिर भी इस क्षेत्र में ClickHouse का core player बनना अच्छा है, ताकि बाकी चीज़ों से कम जूझना पड़े

    • जिन organizations में अब तक सिर्फ़ metrics और logs से काम चल रहा था, वहाँ tracing लाना मेरे अनुभव में काफ़ी कठिन चढ़ाई है
      बहुत evangelism चाहिए, use cases इकट्ठे करने पड़ते हैं, और यह मेहनत करके खुद दिखाना पड़ता है कि अब वे काम हो सकते हैं जो पहले नहीं हो पाते थे, और मुश्किल चीज़ें कितनी आसान हो गई हैं
      तकनीकी तौर पर adoption को जितना हो सके seamless होना चाहिए, लेकिन stack और situation के हिसाब से वही अपने-आप में बड़ा effort हो सकता है, और आम तौर पर उसका बोझ adoption push करने वाले व्यक्ति पर ही आता है
      यह एक व्यापक organizational initiative से अलग नहीं है, इसलिए अगर company के अंदर personal credibility वाले एक-दो सच्चे believers हों जो इसे फैलाएँ, तो मदद मिलती है
    • क्या आप ElasticSearch की JSON query language की बात कर रहे हैं, यह जानना चाहूँगा। ElasticSearch multiple query languages support करता है, जिनमें SQL dialect भी शामिल है
      उस support की quality कैसी है, यह मुझे नहीं पता, लेकिन मैंने खुद सिर्फ़ JSON query language इस्तेमाल की है और बाकी चीज़ों के बारे में अभी-अभी पता चला
      Query language के रूप में SQL perfect नहीं है। clauses को duplicate न कर पाना और arbitrary order में न लिख पाना irritate करता है, लेकिन फिर भी SQL बहुत अच्छी language है

  • मेरा अनुभव भी लेखक जैसा ही है। ClickHouse की scalability चौंकाने वाली हद तक अच्छी है, और खुद operate करने पर भी यह लगभग बस और cores जोड़ने जैसा है
    शुरुआती setup cost थोड़ी ज़्यादा हो सकती है, लेकिन schema असल में OTel export काफ़ी हद तक तय कर देता है, इसलिए वहीं से शुरू किया जा सकता है; और जब query performance की ज़्यादा ज़रूरत पड़े, तब columns और materialized views निकालते जाएँ
    इसके बदले scaling की चिंता कम हो जाती है, सारा data सीधे analysis में इस्तेमाल किया जा सकता है, और tracing से metrics derive करना भी संभव है
    हालांकि puzzle का दूसरा टुकड़ा, यानी visualization, अभी बहुत बेहतर होने की ज़रूरत रखता है। Grafana tracing दिखाने और analyze करने के लिए Honeycomb जैसे tools की तुलना में ideal नहीं है। उम्मीद है मौजूदा players में से कोई जल्द इसे solve करेगा—शायद HyperDX ही हो

  • यह लेख शुरू में एक persuasive introduction के साथ मज़बूती से शुरू होता लगा, लेकिन जैसे ही यह कई companies का analysis करने वाले हिस्से में गया, यह साफ़ तौर पर low-effort LLM style वाली listicle में टूट गया
    Introduction को भी दोबारा ज़्यादा critical नज़र से पढ़ा तो ऐसे संकेत और दिखने लगे
    यह pattern हाल के Lobsters posts में मुझे अधिक बार दिख रहा है, इसलिए इसे किसी specific लेख पर हमला करने के बजाय एक सामान्य observation पर छोटी टिप्पणी के तौर पर छोड़ना चाहता हूँ
    Personally मेरा observability tools का अनुभव बहुत ज़्यादा नहीं है, इसलिए लेख के कुछ हिस्से लिखने के तरीके से अलग होकर भी interesting लगे। लेकिन मैं यह गलती नहीं करना चाहता कि unfamiliar topics पर LLM पर भरोसा कर लूँ और familiar topics पर कहूँ कि LLM लेख flawed है
    इसलिए मुझे पक्का नहीं है कि इस लेख या ऐसे अधिकांश लेखों पर facts के तौर पर भरोसा किया जा सकता है या नहीं। यह साफ़ लगता है कि लेखक ने बड़े हिस्से में thinking machine को सौंप दी, लेकिन शुरुआत का मूल विचार शायद काफ़ी स्पष्ट था
    Programming करते समय भी मेरे दिमाग़ में कोई विचार साफ़ हो सकता है, लेकिन जब तक सच में program लिखकर edge cases के tests में fail न हो या type checking pass न करे, तब तक यह स्वीकार नहीं होता कि कुछ बुनियादी कमी रह गई है
    Writing भी वैसी ही है: अगर आप claim खुद नहीं बनाते, पूरे argument को assemble नहीं करते और objections को सावधानी से consider नहीं करते, तो आप मूल स्पष्ट विचार से आगे कोई value deliver नहीं करते
    शायद future LLMs के लिए prompts ही store करके code लिखने की बात करने वाले लोग भी इसी point की ओर इशारा कर रहे होते हैं
    लेकिन अगर programming या writing पूरी की पूरी इसी तरह हो, तो यह सिर्फ़ thinking नहीं, बल्कि rigor, sincerity, respect भी छोड़ देना है
    Lobsters को इस बारे में क्या करना चाहिए, मुझे ठीक से नहीं पता। vibecoding tag पहले से overloaded solution जैसा लगता है। हाँ, rigor की कमी पर ध्यान दिलाने के संकेत के रूप में LLM smell tag मददगार हो सकता है

    • मैं भी इसे top-level comment के रूप में नहीं डालना चाहता था, लेकिन article में गया तो वह बस LLM-style clichés निकला, इसलिए शुरुआत पढ़ने में लगाया समय थोड़ा बेकार लगा
    • Observability tools थोड़ा इस्तेमाल करने वाले व्यक्ति के रूप में यह मुझे काफ़ी स्पष्ट और reasonable लेख लगा
      मुख्य तर्क यह है कि अलग-अलग products अलग तरह से scale करते हैं, और charts व concrete explanation के ज़रिए दिखाता है कि हर scale पर क्या होता है
      अगर कोई हिस्सा ऐसा लगा जहाँ thinking साफ़ तौर पर छोड़ दी गई है, तो examples जानना चाहूँगा
    • Matthew कम से कम observability में काफ़ी knowledgeable व्यक्ति हैं। वे Braintree में tech lead थे और अब Subway Surfers के लिए जाने जाने वाले SYBO में Principal हैं
      गालियों वाले हिस्से भी कुछ हद तक उनकी अपनी आवाज़ दिखाते हैं
      GPTZero में डालने पर LLM probability 71% और mixed 28% आती है। हालांकि character limit की वजह से सबसे human लगने वाला introduction काटना पड़ा
      आपकी असहजता समझ में आती है, लेकिन यह actually review और कई iterations से गुज़रा हुआ लेख लगता है, और ज़्यादा ऐसा है कि LLM-like phrasing को छाँटा नहीं गया या tone optimize नहीं की गई। अब सिर्फ़ em dash न इस्तेमाल करने से smell बचाना काफ़ी नहीं है

  • जिन लोगों को Honeycomb का अनुभव है, उनसे जानना चाहूँगा कि इस context में यह कैसे fit होता है
    मेरी जानकारी में Honeycomb भी columnar storage format इस्तेमाल करता है और read के समय बहुत सा data skip करने के लिए compression और bucketing पर काफ़ी निर्भर करता है। मेरी समझ से यह Elastic या Datadog की तरह inverted index वाला तरीका नहीं है, और Datadog भी internally Elastic चलाता है

    • मुझे याद है कि कुछ साल पहले Honeycomb की co-founder Charity Majors ने Twitter पर कहा था कि company शुरू करते समय अगर ClickHouse मौजूद होता, तो शायद वे बस वही इस्तेमाल करतीं
      हालांकि दोनों systems conceptually सच में कितने overlap करते हैं, यह मुझे पक्का नहीं है। यह जानना interesting होगा कि problem domain ने naturally समान approach की ओर धकेला या नहीं, और personally मुझे लगता है कि शायद ऐसा ही हुआ होगा

  • कुछ लोगों को यह असहज लग सकता है, लेकिन कुछ specific शब्दों का इस्तेमाल इतना distracting लगा कि मैंने बस उन शब्दों को कम चुभने वाले शब्दों से find-and-replace कर दिया, और लेख बहुत बेहतर हो गया
    कौन से शब्द थे, यह नहीं कहूँगा, लेकिन वे expressions increasingly inaccurate तरीके से इस्तेमाल हो रहे हैं और मुझे परेशान करते हैं। अच्छा लगा कि सिर्फ़ simple search-and-replace से लेख आराम से पढ़ा जा सका