Show HN: ScratchDB – Open-Source-Snowflake auf ClickHouse

 (github.com/scratchdata)
4 Punkte von GN⁺ 2023-10-29 | 1 Kommentare | Auf WhatsApp teilen
  • Scratch Data ist ein Wrapper, der Daten in eine analytische Datenbank hinein- und herausstreamt und Analyseabfragen auf beliebigen JSON-Eingaben ermöglicht
  • Bei Ausführung ohne Konfiguration wird automatisch eine lokale DuckDB-Datenbank vorbereitet, die Lese- und Schreibzugriffe unterstützt
  • Wenn JSON-Daten über POST /api/data/insert/events?api_key=local eingefügt werden, werden die Tabelle events und ihre Spalten automatisch erstellt
  • Nutzungsablauf der HTTP API: SQL-Abfragen an GET /api/data/query übergeben, um die eingefügten Daten abzufragen
  • Bietet Funktionen zum Teilen oder Kopieren von Abfrageergebnissen
    • Die share-API erstellt eine Abfrage-ID, läuft nach der angegebenen duration in Sekunden ab und ermöglicht das Teilen von Daten per CSV- oder JSON-Link
    • Nach der Konfiguration mehrerer Datenbanken wird eine SQL-Abfrage in der Quelldatenbank ausgeführt; Erstellung der Zieltabelle und Einfügen der Daten erfolgen automatisch

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-10-29
Hacker-News-Meinungen

  • Es wäre hilfreich, zu erklären, was Open-Source Snowflake bedeutet. Weder in der Beschreibung noch im Repository oder auf der Website scheint es eine ausgeschriebene Erklärung zu geben.
    Ich frage mich, ob das Ziel darin besteht, explizit alle Funktionen von Snowflake nachzubilden: https://docs.snowflake.com/en/user-guide/intro-supported-fea...

    • Das ist gutes Feedback für eine klarere Botschaft, danke dafür.
      Ziel dieses Projekts ist es, eine hervorragende Developer Experience auf einer Analysedatenbank zu schaffen. Das sehe ich als eines der zentralen Wertversprechen von Snowflake. Außerdem sollen Nutzer die volle Kontrolle über ihre Daten und deren Verarbeitung behalten und Compute-Ressourcen wirtschaftlich nutzen können.
      Es ist nicht das Ziel, die Funktionen eines anderen Produkts nachzubauen, aber mit dem Wachstum werden wir Funktionen entwickeln, die für Unternehmen wichtig sind.

  • Ich arbeite bei ClickHouse.
    Ich denke, Echtzeit-OLAP-Datenbanken haben das Potenzial, bestimmte Aufgaben besser zu unterstützen, die derzeit in Postgres oder Cloud-Data-Warehouses erledigt werden, wenn Echtzeit-Ingestion und analytische Abfragen erforderlich sind. Wenn man die Developer Experience vereinfacht, ohne alle Details einer leistungsfähigen Datenbank lernen zu müssen, beschleunigt das auch die Entwicklung erheblich.
    Ich frage mich, wie sich dieses Projekt von GraphJSON(https://www.graphjson.com/) und Tinybird(https://www.tinybird.co/) unterscheidet.

    • GraphJSON sehe ich zum ersten Mal, das schaue ich mir an. Tinybird gefällt mir ebenfalls, und ich denke, das Ziel, Menschen den Einstieg in OLAP zu erleichtern, ist ähnlich.
      Technisch haben wir bei Daten-Ingestion und -Verarbeitung andere Designentscheidungen getroffen. Zum Beispiel kann man auch nach dem Erstellen einer Tabelle neues JSON mit anderen Spalten senden, und es wird ohne manuelle Migration ingestiert. Auch JSON-Arrays behandeln wir anders: Statt ClickHouse-Arrays zu verwenden, können wir sie in mehrere ClickHouse-Zeilen aufteilen.
      Philosophisch gesehen glaube ich, dass es viel Raum für Open-Source-Software mit einer hervorragenden UI und Developer Experience gibt. Ich schreibe seit Langem Open Source und halte das für den besten Weg, erfolgreiche Entwicklertools zu bauen.
    • Ich bin nicht der Autor des ursprünglichen Beitrags, aber weder GraphJSON noch Tinybird scheinen Open Source zu sein.

  • Gutes Produkt, danke fürs Teilen.
    Ich hatte verstanden, dass ClickHouse das Flattening von JSON bereits nativ unterstützt[1]. Das ist zwar ein Feature aus der relativ neuen Version 22.3.1, aber ich frage mich, ob ihr schon davor damit begonnen habt[2] oder ob das ein anderer Ansatz ist. Ich würde auch gern die jeweiligen Vor- und Nachteile kennen.
    [1] https://clickhouse.com/docs/en/integrations/data-formats/jso...
    [2] https://scratchdb.com/blog/flatten-json/

    • Ziemlich gute Frage. Die leicht sarkastische Antwort wäre: „Unsere Art, JSON zu ingestieren, braucht keine 50 Seiten Erklärung und n Konfigurationswerte.“
      Etwas sachlicher: Wir verwenden für verschachteltes JSON keine Tupel, sondern markieren parent_child-Beziehungen in Keys mit Unterstrichen. Arrays verwenden wir ebenfalls nicht; stattdessen machen wir es einfach, sie in mehrere Zeilen aufzuteilen, sodass normales SQL genutzt werden kann.
      Ich habe keinen direkten Vergleich mit den verschiedenen JSON-Verarbeitungsarten in ClickHouse gemacht, aber das Ziel war, etwas zu bauen, das nach dem Start einfach wie erwartet funktioniert.
    • Schema-Inferenz für verschachtelte JSON-Objekte ist ein Feature von ClickHouse 23.9. Ich habe dazu ein Video gemacht: https://www.youtube.com/watch?v=yS8YU-rBpMM&t=1846s

  • Für alle, die es interessiert: Die Lizenz ist AGPL-3.0.

  • Glückwunsch zum Launch. Ich frage mich, ob man das für Logdaten verwenden kann und wie lange ingestierte Daten aufbewahrt werden.

    • Für Logs kann man es verwenden. Ein einfaches Beispiel gibt es hier: https://scratchdb.com/blog/fly-logs-to-clickhouse/
      Da es einfach in der Datenbank gespeichert wird, bleibt es so lange erhalten, wie du möchtest. Die gehostete Version rechnet pro GB komprimierter Daten ab, daher kannst du auch viele Logs aufbewahren und alte Daten löschen, wenn du Speicherplatz sparen willst.

  • Danke fürs Teilen, das sieht sehr aufgeräumt und einfach zu benutzen aus.
    Ich frage mich, ob geplant ist, beim Einfügen auch Datenformate außer JSON zu unterstützen. Zum Beispiel CSV-Dateien, Parquet-Dateien, Avro- oder Protobuf-Nachrichten.

  • Es wäre gut, Benchmarks bei ClickBench einzureichen.

  • Ich frage mich, was das lizenzrechtlich bedeutet, wenn man den bereitgestellten Code nicht verändert, ihn aber nutzt, um einen öffentlichen Dienst anzubieten.
    Zum Beispiel, wenn man ihn für ein Forum verwendet, aber ein separates Stück Code nutzt, das Daten in ScratchDB schreibt und daraus liest.

  • Ich frage mich, warum Storage 10-mal teurer ist als bei BigQuery. Außerdem würde ich gern wissen, wie die Compute-Preise im Vergleich zu BigQuery aussehen.
    Korrektur: Bigtable → BigQuery

    • Wir rechnen Compute und Storage nicht getrennt ab wie Bigtable. Im Preis pro GB Daten ist Compute enthalten. Ziel ist ein Preismodell ähnlich wie bei DynamoDB, bei dem man nur für die Nutzung zahlt. Eine weitere Abrechnungsart basiert auf der tatsächlichen verstrichenen Zeit einer Abfrage, sodass eine 30-Sekunden-Abfrage teurer ist als eine mit 500 ms.
      Ich habe Bigtable nicht genutzt, aber es sieht so aus, als läge die Mindestgebühr bei etwa 300 Dollar, selbst ohne Daten. Bei ScratchDB beträgt das Minimum 10 Dollar für 30 GB.
      Außerdem liegt die Datenkompression im Durchschnitt bei 25 %. Wenn 1 TB Daten nur 250 GB belegt, zahlst du auch nur dafür.
      Bigtable ist kein OLAP, daher würde man es nicht für dieselben Daten verwenden. Das hier konkurriert direkter mit BigQuery auf GCP.
      Preisfeedback interessiert mich sehr. Wir müssen die Entwicklung weiterführen können, daher möchte ich eine vernünftige Richtung finden.

  • Glückwunsch zum Launch, sieht gut aus. Schemas on the fly zu inferieren ist großartig, um schnell loszulegen, aber gibt es auch eine Möglichkeit, ein Schema explizit zu definieren, wenn man das möchte?
    Ich denke zum Beispiel an Kompressionseinstellungen pro Spalte.

    • Aktuell nicht, aber ich bin offen für die Idee, das konfigurierbar zu machen.
      Es könnte nützlich sein, das ad hoc einstellen zu können – oder noch besser: dem Nutzer auf Basis der tatsächlichen Daten mitzuteilen, welches Kompressionsverfahren verwendet werden sollte. Ich diskutiere das gern auch in einem GitHub-Issue.