Transcript
00:00:00コードにはGitがあるのに、データには何があるでしょうか。まさにそれが問題です。CSVが一つ、設定行が一行、
00:00:07スプレッドシートを一つ編集しただけで、アプリが壊れてしまう。きれいな差分も、ブランチも、プルリクエストも、
00:00:13ロールバックもありません。そこでDoltの出番です。これはGitのように動作するSQLデータベースです。テーブルを分岐させて、
00:00:20行を編集し、差分を確認してコミットし、マージする。まさにデータのための本物のバージョン管理です。
00:00:26この先数分で、その導入方法と使い方をお見せします。
00:00:35データベースは本来、データを保存し、SQLでクエリを実行するのに優れていますが、
00:00:41日常的に行うような、ブランチを切って、レビューし、差分を確認して、マージし、ロールバックして、
00:00:47誰が何を変更したかを正確に追跡するといったワークフローは得意ではありません。そのため、私たちはよく
00:00:54二つの悪い選択肢のどちらかを選んでいます。一つ目は、データを実際のデータベースに保持する方法です。SQLのインデックスや
00:01:00制約、構造は得られますが、データが変更された時のレビュープロセスが不十分になりがちです。
00:01:07二つ目は、データをCSV、JSON、YAMLに入れてGitで追跡する方法です。これで
00:01:13コミットやプルリクエストが可能になりますが、データベースが本来得意な機能を失います。SQLは使えず、スキーマの強制も弱く、
00:01:20差分やマージの確認は困難です。誰がこのレコードを変更したかと聞かれても、答えは
00:01:27結局、データベースにアクセスできる「誰か」という曖昧なものになります。これは真の
00:01:32ワークフローとは言えません。しかし、想像してみてください。ブランチコマンドを実行できたらどうでしょう。「dolt branch fix-this-data」
00:01:39「dolt diff」「dolt commit」「dolt merge」。これらは私たちが既に使っているコマンドですが、
00:01:46それを実際のデータベーステーブルに対して行えるのです。それがDoltの役割、データベースのバージョン管理です。
00:01:52ワークフローを高速化するコーディングツールに興味があれば、ぜひチャンネル登録してください。動画を
00:01:57どんどん公開していきます。前置きはこれくらいにして、DoltにはSQLiteやPostgresなどの選択肢があります。早速
00:02:04簡単なデモを行いましょう。ディレクトリを移動して、GitHubからDoltの入門用リポジトリをクローンします。
00:02:10フォルダに移動して、まずは公開されているDoltデータベースをクローンし、「dolt sql」を実行します。これで
00:02:18SQLの中に入れたので、ターミナル上で直接SQLコマンドを実行できます。いいですね、少し変更を加えてみましょう。
00:02:27そして「dolt diff」を実行します。これが最初の「え、今何が起きたの？」という瞬間です。
00:02:34Doltは単にファイルが変更されたとは言いません。どの行が変更され、どのカラムが
00:02:43変わったのか、旧値と新値が何なのかを、テーブルの差分として表示します。今すぐ確認できますね。ではコミットしましょう。「dolt add」
00:02:50次に「dolt commit -m」を実行してコメントを付けます。ブランチを作成するなら、
00:02:56「checkout」を使います。「checkout -b [ブランチ名]」を実行しましょう。さらに変更を加えて、
00:03:03もう一度「dolt diff」で確認し、再度コミットして追加できます。そして戻って
00:03:10メインブランチをチェックアウトし、「dolt merge」を実行します。これらはお馴染みのコマンドですね。それを
00:03:17SQLデータベースに対して行っているのです。最後に「dolt log」を実行すれば、データベースにコミット履歴が残ります。バックアップでも
00:03:24ダンプファイルでも、スプレッドシートの編集履歴でもなく、真のバージョン管理されたデータベースです。これが核心のアイデアです。
00:03:31Gitのワークフローをテーブルのために使う、ということです。では全体を振り返って、仕組みを見てみましょう。
00:03:37Doltが馴染み深く感じられるのには理由があります。「status」「diff」「add」「commit」「branch」「checkout」
00:03:44といったコマンドがあるからです。Gitを知っていれば、このワークフローは直感的に理解できるはずです。
00:03:48Doltはファイルを追跡するのではなく、リレーショナルテーブルを追跡します。コマンドラインから直接使うことも、
00:03:55「dolt sql-server」を起動して使うこともできます。そうすれば、MySQL互換の
00:04:01クライアントやORM、BIツール、アプリケーションコードから接続可能です。つまり、アプリからは通常のSQLデータベースのように扱いつつ、
00:04:09データに対するバージョン管理ができるのです。これが重要です。本物の
00:04:14データベースとGitワークフローのどちらかを選ぶ必要はなく、両方を一つの場所で利用できます。Doltは「Merkle Tree」という技術を使っています。
00:04:22簡単に言うと、通常のデータベースはツリー構造を使って読み書きを高速化しています。
00:04:29Doltは、そのツリー構造をバージョン管理にも適した形で利用しています。コミットのたびにデータベース全体を
00:04:36コピーするのではなく、変更のない部分は共有し、変更された部分のみを追跡します。
00:04:42これにより、「現在の値は何か？」という問いだけでなく、「何かが起きる前のこの行の状態はどうだったか？」
00:04:47といったことを実際に問い合わせることができます。これが大きなポイントです。
00:04:52何かが壊れたとき、推測する必要はもうありません。履歴を検証すればいいのです。
00:04:56差分を確認し、必要であればロールバックできる。これこそが、構造化データのための
00:05:02バージョン管理です。行やカラムに対するブランチ、コミット、差分、マージ、履歴が手に入ります。では、Doltは
00:05:10具体的にどういう位置づけになるのでしょうか。ここが少し混同しやすい点かもしれません。
00:05:15「データのためのGit」と聞くと、既存のツールがあるのではないかと思うかもしれません。
00:05:21確かに似たツールはありますが、解決する問題が異なります。CSVやJSONファイルを
00:05:28Gitに入れることはできますが、それはデータが小さくて単純な場合です。Gitはスキーマを理解せず、
00:05:35プライマリキーも知りませんし、制約も強制しません。CSV上でJOINを実行することも
00:05:41できません。Gitはバージョン管理を提供しますが、データベース用ではないのです。
00:05:47次にDVCがありますが、これはMLワークフロー、特に大規模データセットやモデル成果物には最適ですが、
00:05:53本番環境のライブリレーショナルデータベースを目指しているわけではありません。LakeFSもあります。これはオブジェクトストレージや
00:06:00データレイクにGitのようなアイデアを持ち込むもので、非常に便利ですが、やはり別レイヤーの話です。
00:06:07「SQLテーブルを分岐させ、行を変更し、差分を実行してマージする」というのとは違います。
00:06:13従来のデータベースにも一時テーブル、監査ログ、CDCなどの履歴ツールはありますが、
00:06:20通常の開発ワークフローのようには感じられません。ブランチ、変更、差分、マージ、ロールバックというきれいなループがありません。
00:06:27全ての本番システムに盲目的にDoltを導入すべきだとは言いません。ポイントはこれです。
00:06:33もしあなたの仕事で扱う構造化データが時間とともに変化し、その変更で問題が発生する可能性があるなら、
00:06:40Doltを試してみる価値はあります。一度でも、予期せぬ悪いデータの変更から救われれば、ワークフローが
00:06:46より明確に感じられるようになるはずです。Gitがあるのに、なぜデータ用がないのか？今や、それがあるのです。
00:06:52このようなコーディングツールに興味があれば、Better Stackチャンネルをぜひ登録してください。また次の
00:06:57動画でお会いしましょう。
Community Posts
No posts yet. Be the first to write about this video!
Write about this video