世界を動かす技術を、日本語で。

RustにおけるDatalog

概要

  • frankmcsherry のブログに関する概要
  • Public Notifications の設定方法について説明
  • ForkStar の数に関する情報
  • ユーザーがサインインして行える操作
  • GitHubリポジトリの基本的なナビゲーション

frankmcsherry / blog の概要

  • frankmcsherry / blog は、GitHubで公開されている技術ブログリポジトリ
  • Public Notifications 機能により、新着情報の通知を受け取ることが可能
  • 通知設定の変更には サインイン が必要
  • Fork 数は179、 Star 数は2,000と高い人気を誇るリポジトリ
  • リポジトリのフォークやスター付与によるコミュニティ参加

Public Notificationsの設定方法

  • GitHubアカウントへの サインイン が前提条件
  • リポジトリページ右上の Notifications ボタンから設定画面へアクセス
  • WatchingNot watchingIgnore の3つの通知レベル選択肢
  • 必要に応じて カスタム通知設定 の利用も可能
  • 変更内容は即時反映される仕組み

ForkとStarの役割

  • Fork はリポジトリの独自コピー作成を意味
  • Star はリポジトリへの評価やお気に入り登録を示す
  • 多くの ForkStar はリポジトリの人気や信頼性の指標
  • コントリビューター増加や議論活性化への貢献
  • 技術ブログやプロジェクトの広がりを促進

Hackerたちの意見

これがトップストーリーになってるのを見ると面白いね。今、Differential Datalogを使ってリアルタイムストラテジーゲームを作ってるところなんだ。Rustで、DDLがゲームのロジックを管理してる。新しいアイデアに触れたり、無駄なことをやりまくる口実みたいなもんだよ。

おお、いいね!これがどうなるのか読むのが楽しみだよ!

すごく面白いね、その実装の状態がどうなってるのか、どこまで進むのか気になるよ。DDLogはもうアクティブにメンテナンスされてないからね。

新しいマクシャリーの投稿だ!素晴らしい!前に見たとき、VMWareはDifferential Datalogから離れたって聞いたけど?

Differential DatalogチームがFelderaを立ち上げたんだって。https://www.feldera.com/ 彼らはDifferential DatalogからDifferential SQLに切り替えたみたい。Datalogは売りにくいって気づいたからかな。

1日前に投稿されたやつだね。https://news.ycombinator.com/item?id=44274592

「私は悪名高い悪党で、長らく待たされていた報いを受けるために招待された。」— 今年読んだ技術ブログの中で最高のオープニングラインだね。ナレーターの突っ込みがいい感じだった。技術的に深い内容なのに、読むのが楽しい投稿って珍しいよ。エイリアスのクエリを最適化する過程は、まるで探偵小説みたいだった。読者の私たちも一緒に、50GBのメモリ使用量にうめき、5GBに減ったときには応援してたよ。コードも文章も素晴らしい仕事だね。

DatalogとRustを使いたいなら、cozodbはRustで書かれていて、Datalogのクエリ構文があるよ。

Cozodbはクールだけど、ちょっと活動が鈍いね。2024年11月にちょっと調べてみたら、sqliteストレージバックエンドにいくつか簡単に手に入るものがあったよ。https://github.com/cozodb/cozo/issues/285

Datalogの熱心なコアグループが続いているのを見るのは嬉しいけど、今のDatalogの復活はちょっと下降気味みたいだね。最近のDatalog 2.0カンファレンスは、過去の年に比べてかなり小規模だったし、第二回HYTRADBOIカンファレンスもDatalogに関してはあまり内容がなかった。一回目はDatalogに関連する投稿が四分の一あったのに。最近のDatalogプロジェクトを共有している他のコメント者に励まされてるよ。今、巨大なソフトウェア移行の準備として、レガシーSQLデータベースのためのデータ品質パイプラインを構築中なんだ。Datalogは、クエリがしっかり構造化されていると非常に読みやすいから、SQLよりもデータ品質の問題を特定したり探したりするのにずっと役立つよ。

失礼だけど、Datalog 2.0の参加者が少なかったからってDatalogの衰退の証拠にはならないと思うよ。確かにその高レベルなポイントには同意するけど。Datalog 2.0はLPNMRのサテライトワークショップで、ダラスでランダムに開催されたあまり知られていないヨーロッパのカンファレンスなんだ。私もDatalog 2.0に参加したけど、イベントが少し寂しいと感じたよ。ワークショップでは論文も発表したけど(私の主な仕事じゃなくて、第一著者が本当の天才だからね :-))、その分野に参加している人はあまりいなかったと思う。特にヨーロッパの人たち(例えば、Nemoソルバーを紹介していた人たち)を除いてね。つまり、Datalog 2.0の参加者が少なかったのは、すでにあまり権威のないカンファレンスのサテライトワークショップだからであって、Datalogの実装に対する興奮がないわけじゃないと思う。私が言っていることは、あなたの高レベルなポイントを反論するつもりじゃないよ。生のDatalogエンジンの実装にはあまり新しさがないのは同意するし、研究の領域はずっと先に進んでいる(おそらくずっと前から)し、ストリーミング(HydroFlow)や選択(Dusa)、一般的なチェイスに近い問題(例えば、Egglogのチェイスエンジン)など、もっとエキゾチックな問題に移っていると思う。バニラDatalogが退屈だということには誰も異論はないと思うけど、単調でチェインフォワードの飽和(ホーン節!)は、もっと面白い理論(半環、Z-集合など)を構築するためのよく理解されたエンジニアリングの基盤として、豊かなんだよね。

mangle datalogをRustに移植するのが少し進んだよ。https://github.com/google/mangle/tree/main/rust - golangの実装と同じリポジトリにあるんだ。進みは遅いけど、優先順位が低いのと、セカンドシステム症候群に悩まされているからだね。Mangle Rustは、メモリマッピングを通じてディスクに事実を取得・書き込むことで、どんなサイズのデータにも対応できるはず。golangの実装はメモリ内で動作するんだ。この投稿は、datalogを解析してLSMツリーに触れていて、データフロッグの内容よりもずっと分かりやすいよ。Rustにはproc-macrosを使ったdatalogの実装がたくさんある(ascent、crepeなど)。欠点は、ランタイムでクエリを取得するのに対応していないことだね。クエリやプログラムが固定されている静的解析のユースケースでは、procマクロのアプローチが良いかもしれない。

著者のdatalogの仕事は一般的に好きだけど、導入資料でバイナリ結合を使うことを教えているのは残念だな。理想的なケースから離れると、内部がすごくごちゃごちゃになっちゃうから。一般的な結合スタイルのメソッドの方が、頭の中で一般化するのがずっと簡単だと思ったよ(https://en.wikipedia.org/wiki/Worst-case_optimal_join_algori...を見てみて)。

関連情報:McSherryの前のブログ投稿は、バイナリ結合が適切なクエリプランの調整によって最悪の場合の最適なランタイムを達成できることを示すことに関するものだったよ。- https://github.com/frankmcsherry/blog/blob/master/posts/2025...

以前、Clojureファンの人たちが、datalogの方がSQLよりも優れていると思っていて、リレーショナルDBが全部SQLを使っているのは残念だと言っていたことがあるんだ。彼らがどうしてそう思っているのか、詳しく調べることはなかったけどね。