ClickHouse ओपन सोर्स के 10 साल

 (clickhouse.com)
2 पॉइंट द्वारा GN⁺ 5 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • ClickHouse को 15 जून 2016 को सार्वजनिक किया गया था, और उसके बाद 10 वर्षों में 2,000 से अधिक लोगों ने इसमें योगदान दिया, जिससे यह ओपन सोर्स analytics database परियोजनाओं में एक प्रमुख प्रोजेक्ट बन गया
  • इसका लक्ष्य सिर्फ code सार्वजनिक करना नहीं, बल्कि contribution guide, code review, roadmap, CI, release, और documentation तक को खुला रखने वाला Level 3 open source बनना है
  • इसकी शुरुआत MySQL आधारित web analytics system की सीमाओं से हुई, और OLAPServer व Metrage के अनुभव ने column-oriented processing और MergeTree डिज़ाइन तक पहुंचाया
  • ClickHouse किसी मौजूदा DBMS पर बना extension नहीं, बल्कि 2009 से column representation, aggregate functions, table engines, compression, SQL parser, server-client, और ReplicatedMergeTree को चरणबद्ध तरीके से बनाकर तैयार किया गया शुरुआत से लागू किया गया DBMS है
  • 2014 में आंतरिक production में हर दिन सैकड़ों अरब records प्रोसेस करने के बाद, 2015 की सार्वजनिक पोस्ट और आंतरिक approval प्रक्रिया के जरिए इसे 2016 में दुनिया के सामने जारी किया गया

ओपन सोर्स रिलीज़ के 10 साल

  • ClickHouse को 15 जून 2016 को ओपन सोर्स के रूप में जारी किया गया
  • इसके बाद 2,000 से अधिक लोगों ने योगदान दिया, और यह “सबसे लोकप्रिय ओपन सोर्स analytics database” बन गया
  • प्रोजेक्ट का मुख्य लक्ष्य सिर्फ code खोलना नहीं, बल्कि development process और contribution process को भी जितना संभव हो उतना सार्वजनिक रखना है

ClickHouse जिस ओपन सोर्स स्तर को लक्ष्य बनाता है

  • ओपन सोर्स के कई स्तर होते हैं
    • Level 0: code पढ़ने के लिए सार्वजनिक होता है, लेकिन उससे आगे कुछ नहीं। Doom और MS-DOS जैसे archive या museum-style release इसके उदाहरण हैं
    • Level 1: public repository में commits के जरिए updates होते हैं, लेकिन ज़रूरी नहीं कि contributions स्वीकार किए जाएँ। SQLite और Ladybird इसके उदाहरण हैं
    • Level 2: contributions स्वीकार किए जाते हैं, लेकिन development process पारदर्शी और खुला नहीं होता। ज़्यादातर सक्रिय ओपन सोर्स प्रोजेक्ट इसी श्रेणी में आते हैं
    • Level 3: इसमें contribution guide, task tracking, code review, development roadmap, tests और CI, release cycle, user support, और documentation मौजूद होते हैं
  • ClickHouse का लक्ष्य Level 3 open source है
  • इसका एक उद्देश्य यह भी है कि नया database बनाने वाले developers के लिए यह code और development practices का संदर्भ उदाहरण बने
    • code को modular, orthogonal, और documented रूप में रखने का लक्ष्य है
    • जब जटिल concepts की ज़रूरत होती है, तो comments में उन्हें शुरुआत से समझाया जाता है ताकि पाठक को textbook, Wikipedia, या AI का सहारा न लेना पड़े

C++ development और performance experiments का मंच

  • ClickHouse लोकप्रिय C++ open source repositories में से एक है, और इसका लक्ष्य ऐसा स्थान बनना है जहाँ C++23 जैसे आधुनिक language features, build systems, continuous integration/testing, और code review practices जैसी बुनियादी चीज़ें भी सीखी जा सकें
  • data structures और performance optimization पर प्रयोग करना भी इसका एक महत्वपूर्ण उपयोग है
    • ऐसे experimental Pull Requests भी, जिनका merge होना लक्ष्य नहीं है, production releases के समान स्तर पर test किए जाते हैं
    • नए memory allocators, compression libraries, hash tables, data formats, और sorting algorithms जैसे प्रयोग ClickHouse में validate किए जा सकते हैं
  • roadmap में experimental, अजीब, और यहाँ तक कि कुछ मज़ाकिया items भी शामिल हैं
  • सभी contributors को CHANGELOG और database के अंदर की system.contributors table में credit दिया जाता है
  • कई बार शुरुआती implementation अधूरी होने पर भी feature बाद में मिलकर पूरा किया जाता है, और अगर पूरा codebase दोबारा लिखना पड़े तब भी शुरुआती लेखक की मंशा और use case को मान्यता दी जाती है

ClickHouse से पहले की समस्याएँ और prototypes

  • ClickHouse का पहला commit 29 मई 2009 को बनाया गया था, और यह localtime, mktime, gmtime जैसी libc functions के बहुत धीमे होने की समस्या को कम करने वाली performance optimization थी, जो profiler में दिखाई देती थी
  • इसकी शुरुआत web analytics system के data processing experiments से हुई
    • यह system Google Analytics की तरह websites से भेजे गए pageview logs प्राप्त करता था
    • इसमें MySQL, C++ data processing, और उन हिस्सों के लिए custom C++ data structures का उपयोग होता था जिन्हें MySQL पर्याप्त रूप से संभाल नहीं पाता था
    • MySQL database ग्राहकों के लिए pre-aggregated reports संग्रहीत करता था, जबकि custom data structures का उपयोग user sessions और user history की गणना में होता था
  • data लगातार बढ़ रहा था और नए logs real time में आ रहे थे; अगर 5 मिनट के logs को 5 मिनट के अंदर process नहीं किया जाता, तो delay लगातार जमा होता रहता था
  • कई databases और libraries भी आज़माए गए
    • TokuDB, LMDB, Judy Arrays, Hadoop, LZO, QuickLZ, HyperLogLog, data compression material, और event-loop servers के documentation की समीक्षा की गई
  • जब users को arbitrary reports बनाने देने की ज़रूरत सामने आई, तब pre-aggregated reports की सीमाएँ स्पष्ट हुईं, और इससे column-oriented databases की जाँच शुरू हुई

OLAPServer और Metrage

  • column-oriented approach का मतलब था non-aggregated structured logs को संग्रहीत करना, और फिर जब ग्राहक page load का इंतज़ार कर रहा हो, उसी समय on-the-fly aggregation करना
  • MySQL extensions Infobright, InfiniDB और standalone analytics databases Vertica, MonetDB, LucidDB का परीक्षण किया गया, लेकिन वे रोज़ 100 अरब records और 500 columns के loading conditions में काम नहीं कर सके
  • पहला custom prototype OLAPServer था
    • इसे दिसंबर 2008 में implement किया गया और जनवरी 2009 में deploy किया गया
    • इसमें सभी columns को प्रति दिन और प्रति website एक single binary file में संग्रहीत किया जाता था
    • strings की जगह hashes का उपयोग होता था, और केवल integer types समर्थित थे
    • इसमें हल्का compression इस्तेमाल होता था, और यह दिन में एक बार कुछ घंटों की देरी के साथ update होता था
    • यह grouping columns, aggregate functions, filters, और sorting बताने वाला API देता था, और queries XML में निर्दिष्ट होती थीं
    • पुराने MySQL aggregated data को “de-aggregate” करके वही परिणाम देने के लिए भरने का काम Evgenii Gatov ने हल किया
  • OLAPServer पूरे कंपनी के internet data का विश्लेषण करने वाले endpoint में भी काम करता था, जहाँ single website के बजाय समग्र विश्लेषण होता था, और यह इतना तेज़ response देता था कि आंतरिक analysts इसे internal MapReduce की जगह इस्तेमाल करते थे
  • दूसरा prototype Metrage था
    • MySQL में लगभग 50TB data 50 shards में जमा था, और कई custom data structures BLOB के रूप में संग्रहीत थे
    • aggregation के समय program को BLOB पढ़ना, custom code लागू करना, और फिर दोबारा insert करना पड़ता था
    • MySQL data compressed नहीं था, और arrival order व query range order मेल न खाने की वजह से reading भी धीमी थी
    • Metrage background merges का उपयोग करने वाला incremental aggregation के लिए custom data structure था, और हर record को add, update, merge, serializeText/Binary, deserializeText/Binary methods वाले C++ struct के रूप में परिभाषित किया जाता था
  • OLAPServer non-aggregated column-oriented structure था, जबकि Metrage arbitrary CRDTs वाला real-time row-oriented structure था
  • ClickHouse की शुरुआत column-oriented aggregation speed और merge tree आधारित real-time updates व data locality को जोड़ने से हुई, और इसे आगे बढ़ाकर वास्तविक query language और data types के समर्थन के साथ सामान्यीकृत किया गया

शुरुआत से बनाया गया DBMS

  • ClickHouse उन दुर्लभ DBMS उदाहरणों में से है जो किसी मौजूदा database पर आधारित नहीं, बल्कि शुरुआत से implement किए गए हैं
  • 2009 के शुरुआती commits उसी monorepository के अंदर अन्य data structure optimizations से जुड़े थे, और open source release के समय history को सुरक्षित रखते हुए repository अलग करने के कारण वे वैसे ही बने रहे
  • नए DBMS implementation का पहला चरण in-memory columns को implement करना था, और आज भी परिचित IColumn और Field classes वहीं सामने आईं
    • यह Apache Arrow जैसा लग सकता है, लेकिन उस समय Apache Arrow मौजूद ही नहीं था
    • RCFile, Trevni, ORC, Parquet जैसे दूसरे column-oriented formats भी उस समय मौजूद नहीं थे
  • इसके बाद aggregate functions जोड़े गए, और आज भी वे ClickHouse के सबसे महत्वपूर्ण हिस्सों में से एक हैं
  • table engines भी जोड़े गए
    • शुरुआत में कुछ दिनों तक इसका नाम “primary key” रखा गया था
    • इससे disk पर columns को पढ़ना और लिखना संभव हुआ
    • पहला table engine आज भी मौजूद TinyLog जैसा था
  • compression में शुरुआत में QuickLZ का उपयोग हुआ, लेकिन Yann Collet का blog पढ़ने के बाद इसे LZ4 से बदल दिया गया

query pipeline और SQL implementation

  • block streams ऐसे data processing pipeline components थे जो column chunks को streaming रूप में produce, consume, और transform करते थे
    • अब उनकी जगह Processors ने ले ली है
    • यही result formatting और table query implementation की नींव बने
  • उसी commit में testing के लिए StorageSystemNumbers जोड़ा गया, जो आज के system.numbers table के रूप में मौजूद है
  • पहली query pipeline TSV में numbers output करने की थी, और पहला relational operator LIMIT था
  • SQL parser के लिए पहले boost::spirit आज़माया गया, लेकिन वह असफल रहा, और बाद में recursive descent parser बनाया गया
  • कुछ ideas ऐसे भी थे जिन्हें शुरुआत में जोड़ा गया, फिर हटाया गया, और बाद में दोबारा लाया गया
    • variable-length encoded numeric columns धीमे होने के कारण हटा दिए गए, और बहुत बाद में columns से स्वतंत्र custom compression codecs जोड़े गए
    • arbitrary field values रखने वाला Variant column type भी धीमा था, इसलिए हटा दिया गया; बाद में बेहतर Variant 2025 में जोड़ा गया
    • fixed-size array type कम ज़रूरत के कारण हटा दिया गया, और अब इसे फिर से जोड़ने पर विचार हो रहा है
  • इससे यह development principle सामने आता है कि अनावश्यक code हटाना, नया code जोड़ने से अधिक महत्वपूर्ण है

production deployment और ReplicatedMergeTree

  • ClickHouse में test किया गया पहला वास्तविक table structure hits table था, जिसे आज ClickBench में भी देखा जा सकता है
  • इस table को पढ़ने और लिखने की प्रक्रिया में पता चला कि C++ iostreams धीमे हैं, इसलिए WriteBuffer और ReadBuffer जोड़े गए, और वे आज भी उपयोग में हैं
  • SQL का पहला function arithmetic operators था, और इनके जरिए पहला SELECT query interpreter implement किया गया
  • ClickHouse server को 9 मार्च 2012 और clickhouse-client को 25 मार्च 2012 को पेश किया गया
  • Log, TinyLog, Merge, Distributed, Memory table engines के साथ production deployment संभव हो गया
    • पहला production उपयोग आगे की processing के लिए log chunks को store करना और raw logs पर global queries चलाना था
    • इसका उपयोग SQL queries वाले persistent log queue की तरह किया गया
  • इसके बाद MergeTree जोड़ा गया
    • data समयक्रम में आने पर भी यह background में incremental sorting करता था
    • इससे single website पर range queries तेज़ी से चल सकीं
    • और OLAPServer व Metrage को बदलने वाली production deployment संभव हुई
  • 2012 में Michael Kolupaev टीम के दूसरे कर्मचारी के रूप में जुड़े और ReplicatedMergeTree implementation में शामिल हुए
  • production को कई regional data centers में deploy किया गया था, और infrastructure team हर महीने एक बार एक घंटे के लिए data center बंद करने वाले “drills” चलाती थी
    • सभी production services में multi-data-center replication होना ज़रूरी था
    • शुरुआत में simple double-write और downtime के बाद backfill का उपयोग किया गया
    • 100% consistency और automatic recovery के लिए distributed consensus की ज़रूरत थी
    • metadata layer के रूप में ZooKeeper का उपयोग करते हुए ReplicatedMergeTree implement किया गया
  • ReplicatedMergeTree ने 2014 में user-facing queries के लिए ClickHouse की production deployment को संभव बनाया

ओपन सोर्स रिलीज़ तक की यात्रा

  • 2014 में ClickHouse production में हर दिन सैकड़ों अरब records store कर रहा था और ग्राहकों की real-time queries का जवाब दे रहा था
  • कंपनी के अंदर data scientists ClickHouse से internet trends की गणना कर रहे थे, और साधारण usage documentation भी सार्वजनिक की गई थी
  • advertising, ecommerce, infrastructure, और business analytics जैसे दूसरे विभागों ने भी ClickHouse को आज़माया, और कुछ use cases को internal MapReduce, MySQL, और Postgres से migrate किया
  • 2014 के अंत तक ClickHouse एक कंपनी के अंदर व्यापक रूप से इस्तेमाल हो रहा था, और अपवादस्वरूप CERN ने भी LHCb experiment सहयोग के दौरान इसे deploy किया
  • यह भी स्पष्ट हुआ कि दूसरी कंपनियों के engineers, क्योंकि मौजूदा databases उनके use cases को अच्छे से संभाल नहीं पा रहे थे, OLAPServer या Metrage जैसी चीज़ें खुद बना रहे थे
  • 2015 में ClickHouse पर लेख और उसका translation सार्वजनिक होने के बाद रुचि और स्पष्ट हुई
  • public release से पहले कंपनी management को मनाने के लिए संभावित फ़ायदों और जोखिमों की सूची तैयार की गई
  • approval मिलने के बाद release plan, पहला logo, पहली website, blog post, और Debian repository तैयार किए गए, और 15 जून 2016 को ClickHouse को दुनिया के सामने जारी किया गया
  • आज ClickHouse दुनिया भर की बड़ी कंपनियों द्वारा उपयोग किया जाने वाला एक लोकप्रिय analytics database बन चुका है

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

1 टिप्पणियां

 
GN⁺ 5 시간 전
Hacker News की राय

  • मैंने 2017~2018 के आसपास ClickHouse खोजा था और Elasticsearch को बदलने के लिए एक proof of concept बनाया था, जिसमें कुछ ही हफ्तों में storage space और queries per second 5 गुना बेहतर हो गए
    लेकिन admins ने इसे यह कहकर ठुकरा दिया कि यह ज़्यादा जाना-पहचाना नहीं है और “रूसियों द्वारा बनाया गया कोई database” लगता है
    निजी तौर पर, इतनी जल्दी ट्रेन आती देखकर भी उस पर न चढ़ पाना आज भी काफ़ी खलता है

    • हाल ही में मेरे साथ भी कुछ ऐसा ही हुआ। ClickHouse पर स्विच करने से database operations 60% कम हो जाते, अलग time-series database की ज़रूरत नहीं रहती, और query time लगभग 300~500ms से घटकर करीब 75ms रह जाता
      compression ratio भी हैरान कर देने वाला था, और storage cost benchmark तो S3 cost के स्तर तक नीचे आ गया था
      हर महीने लाखों डॉलर वाला storage tier घटकर हर महीने कुछ हज़ार डॉलर तक आ जाता
      ClickHouse कोई जादुई इलाज नहीं है, लेकिन अगर आप समझते हैं कि data कैसे access होता है और उसी के हिसाब से उसे arrange कर सकते हैं, तो जबरदस्त efficiency मिल सकती है
    • हम भी Elasticsearch में फँसे हुए हैं, इसलिए ClickHouse पर जाना चाहते हैं, लेकिन मौजूदा load की वजह से अभी कर नहीं पा रहे
    • जिज्ञासा है कि क्या इसे सिर्फ़ simple grep-जैसी search के लिए इस्तेमाल किया गया था, या BM25 जैसी advanced search की ज़रूरत थी
      मेरी समझ से ClickHouse सिर्फ़ grep-जैसी search में ही मददगार है
    • supply chain risk है
    • मुझे जिज्ञासा है कि ClickHouse search कर भी सकता है या नहीं। अगर नहीं, तो Elasticsearch को बदलने की कोशिश क्यों की गई, यह समझ नहीं आता

  • TimescaleDB लंबे समय तक इस्तेमाल करने वाले के नज़रिए से ClickHouse सच में ताज़गी भरा लगा। psql बेहतरीन है, और एक ही database system पर सब कुछ निर्भर कर पाना भी अच्छा था, लेकिन migration maintenance और deployment चरणों में काफ़ी दर्द हुआ
    TimescaleDB में हर version के साथ structure बदलता हुआ-सा लगता है, और उसकी development direction भी कुछ अस्थिर लगती है, इसलिए कभी-कभी वह alpha-quality product जैसा महसूस होता है

    • मैंने TimescaleDB बहुत पहले इस्तेमाल किया था, और लगता है तब से यह काफ़ी बदल गया है। मौजूदा setup में मैं PostgreSQL को TimescaleDB तक बढ़ाकर पुराने data को रखने और साथ ही ClickHouse को parallel deploy करने के बारे में सोच रहा हूँ
      अभी तय नहीं कर पाया हूँ कि PeerDB के ज़रिए ClickHouse mirror को बड़े पैमाने पर ले जाऊँ या किसी अतिरिक्त fragile layer के बिना अलग से deploy करूँ
      जानना चाहूँगा कि क्या आप TimescaleDB को बिल्कुल recommend नहीं करते। PostgreSQL अभी हमारे stack का सबसे मज़बूत हिस्सा है, इसलिए alpha-quality software का दर्द मैं निश्चित रूप से टालना चाहूँगा
    • PostgreSQL ecosystem में भी “एक ही system पर सब कुछ चलाने” को संभव बनाने के लिए बहुत काम हो रहा है। ParadeDB उन systems में से एक है जो index स्तर पर full-text search, vector search और हल्के aggregation को आगे बढ़ा रहा है
      DuckDB की तरफ़ भी pg_duckdb पर काम हो रहा है, और Xata जैसी जगहें भी हैं
      जानकारी के लिए, मैं ParadeDB में काम करता हूँ

  • Cloud 66 का metrics और auto-scaling engine ClickHouse पर टिकने से पहले 5 iterations से गुज़रा: Redis, Cassandra, Ruby+RabbitMQ का custom implementation, Go+RabbitMQ का custom implementation, और फिर ClickHouse
    हर बार किसी न किसी सीमा या असहनीय optimization burden से टकराना पड़ा, लेकिन पिछले 4 सालों से ClickHouse बहुत stable रहा है

    • मैं ठीक से समझ नहीं पा रहा कि किस समस्या को हल किया जा रहा था। Redis, Cassandra, RabbitMQ, ClickHouse के इस mix में RabbitMQ कुछ अलग-सा लगता है

  • Loki को ClickHouse से बदलने के बाद ही हमारा observability stack पहली बार सही लगा। logs और general analytics queries में यह बेहद ताकतवर है

    • हम भी LGTM को पूरी तरह इस्तेमाल कर रहे हैं, इसलिए यह दिलचस्प है। हालांकि Loki भी हमारे लिए अच्छा काम कर रहा है, तो SQL के LogQL से ज़्यादा expressive होने के अलावा ClickHouse कहाँ बेहतर है, यह जानना चाहूँगा
    • visualization आप कैसे करते हैं, यह जानना चाहूँगा। क्या आप ClickStack इस्तेमाल करते हैं, या कुछ और?

  • एक अच्छे OLAP database होने के अलावा, remote sources से data लाने वाले built-in connectors game changer साबित हुए
    S3 folder में रखी Parquet/JSON files को नियमित रूप से auto-import किया जा सकता है, और Postgres से सीधे connect भी किया जा सकता है
    एक मध्यम आकार के newspaper के data warehouse में हमने Druid+Postgres+Trino के संयोजन को एक बड़े ClickHouse node से बदल दिया, और फिर पीछे मुड़कर देखने की ज़रूरत नहीं पड़ी
    यह कहीं ज़्यादा तेज़, व्यावहारिक और maintenance में बहुत हल्का है

  • ClickHouse मुझे सच में बहुत पसंद है और इसकी performance शानदार है। performance की वजह से इधर-उधर कुछ queries को tune करना पड़ा, लेकिन कुल मिलाकर यह उम्मीद से बेहतर रहा
    शुरू में हमने बड़े incremental loads संभालने के लिए real-time pipeline ingestion सेट किया था, क्योंकि पहले इस्तेमाल किया गया Redshift महँगा और तुलनात्मक रूप से धीमा था
    अब तक ClickHouse ने इतना data और बड़े transformations आराम से संभाल लिए कि उस pipeline की ज़रूरत ही नहीं पड़ी
    एकमात्र समस्या यह थी कि default settings में कोई काफ़ी heavy tracing feature enabled था, जिसने अपेक्षाकृत छोटे hardware पर performance को बुरी तरह गिरा दिया
    बाद में हमने scale बढ़ाया, और अब यह data stack का core बन चुका है
    बहुत बड़े scale पर शायद मैं कुछ और चुनूँ, लेकिन जब तक बात कुछ nodes तक सीमित है, complexity manageable रहती है और इसे इस्तेमाल करना आनंददायक है

    • जिज्ञासा है कि default में enabled वह heavy tracing feature कौन-सा था

  • “भले ही merge होना लक्ष्य न हो, आप experiment के तौर पर pull request खोल सकते हैं, और उसे production release जितनी ही सख़्त जांच मिलती है। कोई नया memory allocator, compression library, hash table, data format, sorting algorithm मिला? उसे ClickHouse में डालिए, वह उसकी पूरी परीक्षा ले लेगा” — यह काफ़ी प्रभावशाली है

    • मैं ClickHouse developer हूँ, और यह बात सच है। ClickHouse ने कई third-party libraries में bugs खोजने में योगदान दिया है, और जिन पर मैंने सीधे काम किया उनमें jemalloc और librdkafka शामिल हैं
      Linux kernel समेत लगभग हर जगह यह bugs ढूँढ निकालता है
      हमारे पास बहुत सख़्त fuzzer है, कई स्तरों पर कई fuzzers चलते हैं, और बेहिसाब configuration combinations के साथ tests चलाए जाते हैं
      करीब एक साल पहले मैंने आख़िरी बार जो आँकड़ा सुना था, उसके मुताबिक़ एक single commit के लिए full CI run में लगभग 400 घंटे लगते थे
      इसलिए अच्छे अर्थ में यह काफ़ी पागलपन वाला स्तर है

  • यह दिलचस्प है कि blog post ने SQLite और Ladybird को spectrum पर रखा, लेकिन core open source competitor DuckDB को छोड़ दिया
    मैं इस बात से सहमत हूँ कि trust तीसरे stage पर आता है
    लेकिन vibe-coded databases के दौर में टिकाऊ बने रहने के लिए कोई नया business model ईजाद करना होगा

    • मुझे लगता है ClickHouse की DuckDB पर मुख्य बढ़त MergeTree family है। यह background में data sort कर सकता है, और सही इस्तेमाल पर बेहिसाब compression ratio और performance दे सकता है
      unindexed columns पर query करते समय ClickHouse, Parquet पर query करने वाले DuckDB से आसानी से 10 गुना तेज़ हो सकता है, और primary key छूते ही तो तुलना लगभग बेमानी हो जाती है
      दोनों की तुलना करने वाले लेख बहुत हैं, लेकिन व्यवहारिक रूप से ClickHouse और DuckDB बिल्कुल अलग क्षेत्रों में हैं
      DuckDB एक शक्तिशाली analytics engine है, जबकि ClickHouse replication, MergeTree engine आदि के साथ एक पूर्ण database management system है
    • ClickHouse छोटे स्तर तक नीचे आकर DuckDB से प्रतिस्पर्धा कर सकता है, लेकिन DuckDB ClickHouse की तरह बड़े स्तर तक scale कर सकता है या नहीं, यह मुझे नहीं पता
      ज़्यादातर लोगों को उस scale की समस्या नहीं होती, लेकिन जब होती है, तब फ़र्क बहुत बड़ा होता है

  • अफ़सोस है कि पेज पर “Google Analytics जैसे web analytics system के लिए data processing” कहते हुए यह बताने से बचा गया कि वह वास्तव में Yandex में इस्तेमाल होता था

    • लगता है पेज के दूसरे हिस्सों में भी Yandex का ज़िक्र टाला गया है। पता नहीं वह कहीं Yandex का नाम एक बार भी लेता है या नहीं
      शायद मंशा उस कंपनी का प्रचार न करना हो, लेकिन यह दुखद क्यों है, मैं पूरी तरह नहीं समझता

  • ClickHouse कुछ कंपनियों में, जहाँ मैंने पहले काम किया, सचमुच game changer था। इससे Rust in Production podcast का Rust adoption वाला episode याद आ गया
    https://open.spotify.com/episode/0TBKDUhO0KihBxEzZqnQx1