Show HN: ScratchDB - ClickHouse 上のオープンソース版 Snowflake

(github.com/scratchdata)

4 ポイント投稿者 GN⁺ 2023-10-29 | 1件のコメント | WhatsAppで共有

Scratch Data は、分析データベースとしてデータをストリーミング入出力し、任意の JSON 入力に対して分析クエリを実行できるようにするラッパー
設定なしで実行すると、読み書き可能なローカル DuckDB データベースを自動で用意する
JSON データを POST /api/data/insert/events?api_key=local に投入すると、events テーブルとカラムを自動生成する
GET /api/data/query に SQL クエリを渡して、挿入済みデータを照会する方式の HTTP API 利用フロー
クエリ結果を共有またはコピーする機能を提供
- share API はクエリ ID を作成し、指定した秒数の duration 後に期限切れとなり、CSV または JSON リンクでデータを共有可能
- 複数のデータベースを設定した後、ソースデータベースで SQL クエリを実行し、対象テーブルの作成とデータ挿入を自動処理する

1件のコメント

GN⁺ 2023-10-29

Hacker Newsの意見

open-source Snowflakeが何を意味するのか説明してくれるとありがたい。説明文、リポジトリ、サイトのどこにも詳しく書かれていないように見える
目的がSnowflakeの全機能を明示的に再現することなのか気になっている: https://docs.snowflake.com/en/user-guide/intro-supported-fea...
- 明確なメッセージを書くための良いフィードバックで、ありがたく受け止める
  このプロジェクトの目的は、分析データベースの上で優れた開発者体験を作ることだ。それがSnowflakeの複数の価値提案の1つだと見ている。また、ユーザーが自分のデータと処理方法を完全にコントロールし、コンピューティングリソースを経済的に使えるようにすることも目標だ
  他製品の機能に合わせることが目標ではないが、成長するにつれて企業にとって重要な機能を作ることになるだろう
ClickHouseで働いている
リアルタイムOLAPデータベースには、現在Postgresやクラウドデータウェアハウスで処理している作業のうち、リアルタイム取り込みと分析クエリが必要なケースをよりよく支援できる可能性があると思う。強力なデータベースの細部をすべて学ぶ必要がないよう開発者体験を単純化すれば、開発速度も大きく上がる
このプロジェクトがGraphJSON(https://www.graphjson.com/)およびTinybird(https://www.tinybird.co/)とどう違うのか気になる
- GraphJSONは初めて見たので確認してみる。Tinybirdも好きで、人々がOLAP導入をより簡単にするという目標は似ていると思う
  技術的には、データ取り込みと処理で異なる設計判断をしている。例えば、テーブル作成後でも別のカラムを持つ新しいJSONを送ることができ、手動マイグレーションなしで取り込める。JSON配列もClickHouse配列を使う代わりに、複数のClickHouse行に分割できるよう異なる扱いにしている
  哲学的には、優れたUIと開発者体験を備えたオープンソースソフトウェアが入り込む余地は大きいと見ている。長い間オープンソースを書いてきており、成功する開発者ツールを作る最良の方法だと思う
- 元投稿者ではないが、GraphJSONとTinybirdはいずれもオープンソースには見えない
良い製品で、共有してくれてうれしい
ClickHouseはすでにJSONのフラット化をネイティブにサポートしていると理解していた[1]。最近のバージョン22.3.1で出た機能ではあるが、それより前に作業を始めていたのか[2]、それとも別のアプローチなのか気になる。それぞれの長所と短所も知りたい
[1] https://clickhouse.com/docs/en/integrations/data-formats/jso...
[2] https://scratchdb.com/blog/flatten-json/
- かなり良い質問だ。少し皮肉っぽい答えをすると、「私たちのJSON取り込み方法は、説明に50ページとn個の設定値を必要としない」ということになる
  もう少し事実ベースで言うと、ネストしたJSONにタプルは使わず、キーにアンダースコアでparent_child関係を表す。配列も使わず、複数行に分割しやすくして、通常のSQLを使えるようにしている
  ClickHouseのさまざまなJSON処理方法と直接比較したことはないが、目標は実行すればそのまま期待どおりに動くものを作ることだった
- ネストしたJSONオブジェクトに対するスキーマ推論はClickHouse 23.9の機能だ。関連動画を作った: https://www.youtube.com/watch?v=yS8YU-rBpMM&t=1846s
気になる人のために言うと、ライセンスはAGPL-3.0だ
- https://github.com/scratchdata/ScratchDB/blob/main/LICENSE
リリースおめでとう。これをログデータに使えるのか、取り込まれたデータはどれくらい長く保存されるのか気になる
- ログに使える。基本例はこちら: https://scratchdb.com/blog/fly-logs-to-clickhouse/
  単にデータベースに保存するので、好きなだけ保持される。ホスティング版は圧縮データ1GBあたりで課金するため、ログが多くても保存でき、ディスク容量を節約したければ古いデータを削除することもできる
共有ありがとう。とてもすっきりしていて使いやすそうだ
挿入時にJSON以外のデータ形式もサポートする予定があるのか気になる。例えばCSVファイル、Parquetファイル、AvroやProtobufメッセージのようなものだ
- サポートする予定だ。関連Issueがある: https://github.com/scratchdata/ScratchDB/issues/19
  どんな形を望んでいるのか気になる
ベンチマークをClickBenchに提出するとよさそうだ
提供されたコードを修正せずに、これを使って公開サービスを提供すると、ライセンス上どのような意味になるのか気になる
例えばフォーラムで使うが、ScratchDBにデータを出し入れする別のコード片を使う場合がそれに当たる
ストレージがなぜBigQueryより10倍高いのか気になる。コンピューティング価格はBigQueryと比べてどうなのか知りたい
修正: Bigtable → BigQuery
- Bigtableのようにコンピューティングとストレージを別々に課金しない。データ1GBあたりの価格にコンピューティングが含まれている。目標はDynamoDBに近い、使った分だけ支払う価格モデルだ。もう1つの課金方式はクエリの実際の経過時間ベースなので、30秒のクエリは500msのものより高くなる
  Bigtableは使ったことがないが、データがなくても最低料金が約300ドル程度に見える。ScratchDBは30GBで最低10ドルだ
  さらに平均的にはデータ圧縮率は25%だ。1TBのデータが250GBしか占有しないなら、その分だけ費用を払う
  BigtableはOLAPではないので、同じデータに使うことはないだろう。これはGCPのBigQueryとより直接的に競合する
  価格に関するフィードバックにはとても関心がある。開発を継続できる必要があるので、合理的な方向を見つけたい
リリースおめでとう、良さそうだ。その場でスキーマを推論するのは素早く始めるには素晴らしいが、望むならスキーマを明示的に定義する方法もあるのか気になる
例えばカラムごとの圧縮設定を考えている
- 現時点ではないが、設定できるようにするアイデアには前向きだ
  その場で設定するか、さらに良いのは実データをもとにどの圧縮方式を使うべきかをユーザーに知らせる機能が有用かもしれない。GitHub Issueでも喜んで議論したい

Show HN: ScratchDB - ClickHouse 上のオープンソース版 Snowflake

関連記事

1件のコメント

Hacker Newsの意見