Show HN: ScratchDB - ClickHouse पर Open-source Snowflake

 (github.com/scratchdata)
4 पॉइंट द्वारा GN⁺ 2023-10-29 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Scratch Data एक wrapper है जो analytics database में data को stream करके input/output करने और किसी भी JSON input पर analytics queries चलाने देता है
  • बिना configuration चलाने पर यह अपने-आप read और write कर सकने वाला local DuckDB database तैयार कर देता है
  • JSON data को POST /api/data/insert/events?api_key=local पर भेजने से events table और columns अपने-आप बन जाते हैं
  • डाले गए data को देखने के लिए SQL query को GET /api/data/query पर भेजने वाले HTTP API flow का उपयोग करता है
  • Query results को share या copy करने की सुविधा देता है
    • share API एक query ID बनाता है, तय किए गए seconds के duration के बाद expire होता है, और CSV या JSON link के जरिए data share कर सकता है
    • कई databases configure करने के बाद source database पर SQL query चलाता है, और target table creation तथा data insertion को अपने-आप handle करता है

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

1 टिप्पणियां

 
GN⁺ 2023-10-29
Hacker News की राय

  • अगर कोई यह समझा दे कि open-source Snowflake से क्या मतलब है, तो अच्छा होगा। विवरण, repository या साइट—कहीं भी इसका खुला हुआ अर्थ नहीं दिखता।
    जिज्ञासा है कि क्या लक्ष्य Snowflake की सभी features को स्पष्ट रूप से दोहराना है: https://docs.snowflake.com/en/user-guide/intro-supported-fea...

    • यह स्पष्ट messaging लिखने के लिए बहुत अच्छा feedback है, और मैं इसे आभार के साथ स्वीकार करता हूँ।
      इस project का लक्ष्य एक analytical database के ऊपर शानदार developer experience बनाना है। मेरा मानना है कि यह Snowflake की कई value propositions में से एक है। साथ ही, उपयोगकर्ताओं को अपने data और उसे process करने के तरीके पर पूरा control मिले, और वे computing resources का किफायती उपयोग कर सकें—यह भी लक्ष्य है।
      किसी दूसरे product की features को match करना लक्ष्य नहीं है, लेकिन project के बढ़ने के साथ हम enterprise के लिए महत्वपूर्ण features बनाते रहेंगे

  • मैं ClickHouse में काम करता हूँ।
    मेरा मानना है कि real-time OLAP database में यह क्षमता है कि वह उन workloads को, जो अभी Postgres या cloud data warehouses में चलते हैं, बेहतर support दे सके—खासकर जहाँ real-time ingestion और analytical queries की ज़रूरत होती है। अगर एक powerful database की सारी बारीकियाँ सीखे बिना developer experience को सरल बनाया जाए, तो development की speed भी काफी बढ़ जाती है।
    जानना चाहूँगा कि यह project GraphJSON(https://www.graphjson.com/) और Tinybird(https://www.tinybird.co/) से कैसे अलग है

    • GraphJSON को मैं पहली बार देख रहा हूँ, इसे देखूँगा। Tinybird भी मुझे पसंद है, और मुझे लगता है कि लोगों के लिए OLAP adoption आसान बनाना—यह लक्ष्य काफ़ी मिलता-जुलता है।
      तकनीकी तौर पर, हमने data ingestion और processing में अलग design decisions लिए हैं। उदाहरण के लिए, table बनने के बाद भी आप अलग columns वाला नया JSON भेज सकते हैं, और वह manual migration के बिना ingest हो जाएगा। JSON arrays को भी हम ClickHouse arrays इस्तेमाल करने के बजाय कई ClickHouse rows में split कर सकते हैं, यानी handling अलग है।
      दार्शनिक रूप से, मेरा मानना है कि शानदार UI और developer experience वाले open source software के लिए बहुत जगह है। मैं लंबे समय से open source लिखता आया हूँ, और मुझे लगता है कि successful developer tools बनाने का यह सबसे अच्छा तरीका है
    • मैं मूल पोस्ट का लेखक नहीं हूँ, लेकिन GraphJSON और Tinybird—दोनों open source नहीं लगते

  • अच्छा product है, और इसे साझा करने के लिए धन्यवाद।
    मुझे पता था कि ClickHouse पहले से JSON flattening को native तौर पर support करता है[1]। यह feature हाल की version 22.3.1 में आया था, तो जानना चाहूँगा कि क्या आपने इससे पहले इस पर काम शुरू किया था[2], या यह कोई अलग approach है। दोनों के फायदे-नुकसान भी जानना चाहूँगा।
    [1] https://clickhouse.com/docs/en/integrations/data-formats/jso...
    [2] https://scratchdb.com/blog/flatten-json/

    • यह काफ़ी अच्छा सवाल है। थोड़ा व्यंग्यात्मक जवाब यह होगा: “हम JSON को जिस तरह ingest करते हैं, उसे समझाने के लिए 50 pages और n config values की ज़रूरत नहीं पड़ती।”
      थोड़ा अधिक तथ्यात्मक रूप से कहूँ, तो nested JSON के लिए tuples का इस्तेमाल नहीं करते; keys में underscore के साथ parent_child relation दिखाते हैं। Arrays का भी इस्तेमाल नहीं करते, और उन्हें कई rows में split करना आसान बनाते हैं ताकि सामान्य SQL इस्तेमाल किया जा सके।
      मैंने ClickHouse की अलग-अलग JSON handling methods से इसका सीधा comparison नहीं किया है, लेकिन लक्ष्य था कुछ ऐसा बनाना जो चलाते ही बस उम्मीद के मुताबिक काम करे
    • nested JSON objects के लिए schema inference ClickHouse 23.9 की feature है। इस पर मैंने एक संबंधित video बनाया है: https://www.youtube.com/watch?v=yS8YU-rBpMM&t=1846s

  • जिन्हें जिज्ञासा हो, उनके लिए बता दूँ कि license AGPL-3.0 है

  • लॉन्च की बधाई। जानना चाहूँगा कि क्या इसे log data के लिए इस्तेमाल किया जा सकता है, और ingest किया गया data कितने समय तक रखा जाता है

    • इसे logs के लिए इस्तेमाल किया जा सकता है। एक default example यहाँ है: https://scratchdb.com/blog/fly-logs-to-clickhouse/
      यह बस database में store होता है, इसलिए जितनी देर चाहें उतनी देर रखा जा सकता है। Hosted version compressed data के प्रति GB के हिसाब से charge करता है, इसलिए बहुत सारे logs भी रखे जा सकते हैं; और disk space बचाने के लिए चाहें तो पुराना data delete भी कर सकते हैं

  • साझा करने के लिए धन्यवाद, यह बहुत साफ़-सुथरा और इस्तेमाल में आसान लगता है।
    जानना चाहूँगा कि insert के समय non-JSON data formats को support करने की भी कोई योजना है या नहीं। जैसे CSV files, Parquet files, Avro या Protobuf messages

    • हाँ, support करने की योजना है। इस पर एक related issue है: https://github.com/scratchdata/ScratchDB/issues/19
      जानना चाहूँगा कि आप इसे कैसा देखना चाहेंगे

  • Benchmark को ClickBench में submit करना अच्छा होगा

  • अगर दिए गए code में कोई बदलाव किए बिना इसका इस्तेमाल करके कोई public service दी जाए, तो license के हिसाब से उसका क्या मतलब होगा?
    उदाहरण के लिए, किसी forum में इसका इस्तेमाल हो, लेकिन ScratchDB में data डालने और निकालने के लिए अलग code snippets इस्तेमाल किए जाएँ

  • समझ नहीं आया कि storage BigQuery से 10 गुना महंगा क्यों है। Computing की pricing BigQuery की तुलना में कैसी है, यह भी जानना चाहूँगा।
    सुधार: Bigtable → BigQuery

    • Bigtable की तरह computing और storage का अलग-अलग charge नहीं किया जाता। Data के प्रति GB की कीमत में computing शामिल है। लक्ष्य DynamoDB जैसा pricing model है, जहाँ आप जितना इस्तेमाल करें उतना ही भुगतान करें। एक दूसरा charging तरीका queries के actual elapsed time पर आधारित है, इसलिए 30-second query, 500ms query से ज़्यादा महंगी होगी।
      मैंने Bigtable इस्तेमाल नहीं किया है, लेकिन ऐसा लगता है कि वहाँ data न होने पर भी minimum charge लगभग $300 है। ScratchDB में 30GB के लिए minimum $10 है।
      इसके अलावा, औसतन data compression ratio 25% है। अगर 1TB data सिर्फ 250GB जगह लेता है, तो आप उसी के लिए भुगतान करेंगे।
      Bigtable, OLAP नहीं है, इसलिए आप इसे उसी data के लिए इस्तेमाल नहीं करेंगे। यह GCP के BigQuery से अधिक सीधे तौर पर प्रतिस्पर्धा करता है।
      Pricing पर feedback में बहुत रुचि है। Development जारी रखने के लिए business टिकाऊ होना चाहिए, इसलिए एक उचित दिशा ढूँढ़ना चाहता हूँ

  • लॉन्च की बधाई, और यह अच्छा लग रहा है। तुरंत schema infer करना जल्दी शुरू करने के लिए शानदार है, लेकिन अगर कोई चाहे तो क्या schema को explicitly define करने का भी कोई तरीका है?
    उदाहरण के लिए, मैं per-column compression settings के बारे में सोच रहा हूँ

    • अभी ऐसा नहीं है, लेकिन इसे configurable बनाने के विचार के लिए मैं खुला हूँ।
      On-the-fly settings देना, या उससे भी बेहतर, वास्तविक data के आधार पर उपयोगकर्ता को यह बताना कि कौन-सा compression method इस्तेमाल करना चाहिए—ऐसी feature उपयोगी हो सकती है। GitHub issue में भी इस पर चर्चा करने में खुशी होगी