Show HN : ScratchDB — un Snowflake open source sur ClickHouse

• Scratch Data est un wrapper qui permet d’ingérer et d’extraire des données en streaming avec une base de données analytique, et d’exécuter des requêtes analytiques sur des entrées JSON arbitraires
• Lancé sans configuration, il prépare automatiquement une base de données locale DuckDB lisible et inscriptible
• Si vous envoyez des données JSON via POST /api/data/insert/events?api_key=local, il crée automatiquement la table events et ses colonnes
• Flux d’utilisation de l’API HTTP : transmettre une requête SQL à GET /api/data/query pour consulter les données insérées
• Propose des fonctions pour partager ou copier les résultats de requête
  • L’API share crée un ID de requête, expire après la duration indiquée en secondes, et permet de partager les données via un lien CSV ou JSON
  • Après configuration de plusieurs bases de données, il exécute une requête SQL sur la base source, puis gère automatiquement la création de la table cible et l’insertion des données

[GN⁺]

Avis sur Hacker News

• Ce serait bien d’expliquer ce que signifie open-source Snowflake. Je ne vois d’explication développée ni dans la description, ni dans le dépôt, ni sur le site.
  Je me demande si l’objectif est de reproduire explicitement toutes les fonctionnalités de Snowflake : https://docs.snowflake.com/en/user-guide/intro-supported-fea...

  • C’est un bon retour pour formuler un message plus clair, et je le prends volontiers.
    L’objectif de ce projet est de créer une excellente expérience développeur au-dessus d’une base de données analytique. Je considère que c’est l’une des nombreuses propositions de valeur de Snowflake. L’objectif est aussi de permettre aux utilisateurs de garder un contrôle total sur leurs données et sur la façon dont elles sont traitées, et d’utiliser les ressources de calcul de manière économique.
    Notre but n’est pas de cocher les fonctionnalités d’un autre produit, mais, en grandissant, nous construirons des fonctionnalités importantes pour les entreprises.

• Je travaille chez ClickHouse.
  Je pense que les bases de données OLAP temps réel ont le potentiel de mieux prendre en charge une partie des usages actuellement traités par Postgres ou les data warehouses cloud, lorsqu’ils nécessitent de l’ingestion en temps réel et des requêtes analytiques. Simplifier l’expérience développeur, sans avoir à apprendre tous les détails d’une base de données puissante, accélère aussi fortement le développement.
  Je me demande en quoi ce projet diffère de GraphJSON (https://www.graphjson.com/) et de Tinybird (https://www.tinybird.co/).

  • Je découvre GraphJSON et je vais regarder. J’aime aussi Tinybird, et je pense que l’objectif de rendre l’adoption de l’OLAP plus simple est similaire.
    Techniquement, nous avons fait des choix de conception différents pour l’ingestion et le traitement des données. Par exemple, après avoir créé une table, vous pouvez toujours envoyer de nouveaux JSON avec des colonnes différentes, et ils sont ingérés sans migration manuelle. Nous traitons aussi les tableaux JSON différemment, en permettant de les découper en plusieurs lignes ClickHouse plutôt que d’utiliser les tableaux ClickHouse.
    Philosophiquement, je pense qu’il y a beaucoup de place pour un logiciel open source doté d’une excellente UI et d’une bonne expérience développeur. J’écris de l’open source depuis longtemps, et je pense que c’est la meilleure façon de créer des outils développeur qui réussissent.
  • Je ne suis pas l’auteur du post, mais GraphJSON comme Tinybird ne semblent pas être open source.

• Beau produit, merci de l’avoir partagé.
  Je pensais que ClickHouse prenait déjà en charge nativement l’aplatissement de JSON[1]. C’est vrai que la fonctionnalité est apparue récemment, en version 22.3.1, mais je me demande si vous avez commencé à travailler dessus avant[2], ou s’il s’agit d’une approche différente. J’aimerais aussi connaître les avantages et inconvénients de chacune.
  [1] https://clickhouse.com/docs/en/integrations/data-formats/jso...
  [2] https://scratchdb.com/blog/flatten-json/

  • Très bonne question. La réponse un peu sarcastique serait : « notre façon d’ingérer du JSON ne nécessite pas 50 pages d’explications ni n paramètres de configuration ».
    Plus factuellement, nous n’utilisons pas de tuples pour les JSON imbriqués ; nous représentons la relation parent_child dans les clés avec des underscores. Nous n’utilisons pas non plus de tableaux, et nous facilitons leur découpage en plusieurs lignes afin de pouvoir utiliser du SQL ordinaire.
    Je n’ai pas fait de comparaison directe avec les différentes façons dont ClickHouse traite le JSON, mais l’objectif était de construire quelque chose qui, une fois lancé, fonctionne simplement comme prévu.
  • L’inférence de schéma pour les objets JSON imbriqués est une fonctionnalité de ClickHouse 23.9. J’ai réalisé une vidéo à ce sujet : https://www.youtube.com/watch?v=yS8YU-rBpMM&t=1846s

• Pour celles et ceux que ça intéresse, la licence est AGPL-3.0.

  • https://github.com/scratchdata/ScratchDB/blob/main/LICENSE

• Félicitations pour le lancement. Je me demande si on peut l’utiliser pour des données de logs, et combien de temps les données ingérées sont conservées.

  • Oui, on peut l’utiliser pour des logs. Il y a un exemple de base ici : https://scratchdb.com/blog/fly-logs-to-clickhouse/
    Comme elles sont simplement stockées dans la base de données, elles sont conservées aussi longtemps que vous le souhaitez. La version hébergée facture au Go de données compressées, donc vous pouvez conserver beaucoup de logs, et vous pouvez aussi supprimer les anciennes données si vous voulez économiser de l’espace disque.

• Merci pour le partage, ça a l’air très propre et facile à utiliser.
  Je me demande si vous prévoyez de prendre en charge des formats de données autres que JSON à l’insertion. Par exemple des fichiers CSV, des fichiers Parquet, ou des messages Avro ou Protobuf.

  • C’est prévu. Il y a une issue à ce sujet : https://github.com/scratchdata/ScratchDB/issues/19
    Je serais curieux de savoir à quoi vous voudriez que cela ressemble.

• Ce serait bien de soumettre les benchmarks à ClickBench.

• Je me demande ce que cela implique du point de vue de la licence si l’on utilise ceci pour fournir un service public, sans modifier le code fourni.
  Par exemple, l’utiliser pour un forum, avec un morceau de code séparé qui insère et récupère les données dans ScratchDB.

• Je me demande pourquoi le stockage est 10 fois plus cher que BigQuery. J’aimerais aussi savoir comment le prix du calcul se compare à BigQuery.
  Modification : Bigtable → BigQuery

  • Nous ne facturons pas séparément le calcul et le stockage comme Bigtable. Le calcul est inclus dans le prix par Go de données. L’objectif est d’avoir un modèle tarifaire à l’usage, similaire à DynamoDB. Une autre partie de la facturation est basée sur le temps réellement écoulé des requêtes : une requête de 30 secondes coûte donc plus cher qu’une requête de 500 ms.
    Je n’ai jamais utilisé Bigtable, mais il semble que le tarif minimum soit d’environ 300 dollars même sans données. ScratchDB a un minimum de 10 dollars pour 30 Go.
    Par ailleurs, le taux de compression moyen des données est de 25 %. Si 1 To de données n’occupe que 250 Go, vous ne payez que pour cela.
    Bigtable n’étant pas de l’OLAP, on ne l’utiliserait pas pour les mêmes données. Le concurrent plus direct sur GCP est BigQuery.
    Les retours sur les prix m’intéressent beaucoup. Nous devons pouvoir continuer à développer le produit, donc nous voulons trouver une approche raisonnable.

• Félicitations pour le lancement, ça a l’air bien. Inférer un schéma à la volée est excellent pour démarrer rapidement, mais je me demande s’il existe aussi un moyen de définir explicitement le schéma si on le souhaite.
  Je pense par exemple à des réglages de compression par colonne.

  • Pas pour le moment, mais je suis ouvert à l’idée de permettre de le configurer.
    Pouvoir le définir à la volée, ou mieux encore informer l’utilisateur, à partir des données réelles, du mode de compression qu’il devrait utiliser, pourrait être utile. Je serais ravi d’en discuter aussi dans une issue GitHub.