00:00:00新しいプロジェクトを立ち上げる際、データベースが必要になったら
00:00:03真っ先に思い浮かぶ選択肢は何でしょうか?SQLiteですか?おそらくそうですよね。
00:00:09SQLiteは信頼性が高く、設定も不要で業界標準です。しかし、ローカルデータが重くなり
00:00:14クエリが複雑になると、シングルスレッドのファイルロックエンジンの限界が見え始めます。
00:00:20ですが今、これらの問題を解決しようとする新たなプレーヤーが登場しました。
00:00:25それは「Stulab」です。Rustでゼロから書かれたデータベースエンジンで、
00:00:31先日リリースされたネイティブのNode.jsドライバーが、驚異的なパフォーマンスを見せています。
00:00:36このデータベースはSQLiteより138倍も高速だというのです。そこで今回は、
00:00:43Stulabの内部構造を探り、その仕組みを確認した上で、ライブベンチマークを実施して
00:00:50その主張が本当かどうかを検証します。面白い内容になるので、さっそく見ていきましょう。
00:01:00さて、Stulabとは一体何でしょうか?核心を言えば、組み込み型のOLAP、
00:01:06つまりオンライン分析処理データベースです。SQLiteやPostgresなどの
00:01:14標準的なデータベースは通常OLTP(オンライン事務処理)であり、
00:01:20トランザクションに最適化されています。しかしStulabは異なり、分析ワークロード向けに
00:01:27高速なデータ処理を追求してRustで構築されています。SQLiteファイルの
00:01:33ポータビリティを持ちつつ、DuckDBやBigQueryのような強力な分析力を備えていると考えてください。
00:01:39さらに素晴らしいのは、ネイティブドライバーによってNode.jsで利用できるようになった点です。
00:01:45ここで言う「ネイティブドライバー」は、単なるラッパーではありません。
00:01:49通常、RustやC++で書かれたデータベースをNode.jsから使うには「ブリッジ」が必要です。
00:01:56データをJSONなどに変換し、ローカルネットワーク経由で送信して、また戻すという手順です。
00:02:02これは「シリアライズのオーバーヘッド」と呼ばれ、パフォーマンスを著しく低下させます。
00:02:08しかしStulab Nodeは異なります。NAPI-RSというフレームワークを使用し、
00:02:15Rustエンジンをネイティブバイナリとしてコンパイルし、Node.jsプロセスに直接ロードします。
00:02:21そのため、間にブリッジや翻訳者は存在しません。クエリを送信する際、
00:02:27Node.jsとRustは実質的に同じメモリ空間を共有しているのです。Stulabが爆速な理由は3つあります。
00:02:331つ目は、MVCC(多版型同時実行制御)を採用していることです。
00:02:401つの書き込みがDB全体をロックするSQLiteとは違い、複数の読み書きを同時に行えます。
00:02:472つ目は、並列実行です。StulabはRayonというスケジューラを使用しています。
00:02:53大規模なクエリを実行する際、1つのCPUコアだけでなく、クエリを分割して
00:03:00マシンの全コアを活用します。そして3つ目は、コストベースのオプティマイザです。
00:03:06SQLを盲目的に実行するのではなく、データを分析して各ルートのコストを予測し、
00:03:13最短で結果を出す方法を選択します。これらがStulabをSQLiteより高速にしている理由です。
00:03:19では、実際にテストしてその真偽を確かめてみましょう。
00:03:25このテストでは、シンプルなNode.jsプロジェクトにStulabとSQLiteの両方を
00:03:30依存関係としてインストールします。Stulabが特に威力を発揮するのは「count distinct」です。
00:03:37本当にそうなのか非常に気になるところです。そこで、各DBの
00:03:43インメモリ版を起動し、シンプルな売上(sales)テーブルを作成するスクリプトを用意しました。
00:03:49次に、ユーザーID(0~1000)と特定のカテゴリを持つ1万件のランダムな売上データを
00:03:56テーブルに流し込みます。両方のデータベースにデータをバッチ挿入し、
00:04:03「特定のカテゴリにおける特定ユーザーのユニークな売上数」をカウントする
00:04:10ベンチマークを実行して性能を比較します。ただ1点、現時点では
00:04:16パッケージのインストールが正常に動作しないという不満な点があります。
00:04:22テストを走らせると「ネイティブバインディングが見つからない」というエラーが出ます。
00:04:28開発者がバイナリの追加やリンクを忘れたのでしょう。そのため、
00:04:34ソースからビルドする必要がありました。リポジトリをクローンしてビルドし、
00:04:39自分のプロジェクトにそのソースディレクトリをリンクさせました。これは少々手間なので、
00:04:44将来的に修正されることを期待します。ともあれ、これでようやくベンチマークを
00:04:49実行できるようになりました。さっそくやってみましょう。
00:04:54ご覧の通り、count distinct操作は確かにStulabの方がずっと高速ですが、
00:05:01宣伝ほどではありません。約4倍の速さです。では、データの末尾に
00:05:07ゼロを1つ追加して、100万行で再度テストしてみたらどうなるでしょうか。
00:05:12100万行でも、Stulabは6倍速いだけで138倍ではありませんでした。とはいえ、
00:05:20それでも素晴らしい結果です。これがcount distinctのテストです。次に、
00:05:26「distinct + order by」操作をテストする別のベンチマークも行いました。
00:05:33IPアドレスとステータスコードが異なるランダムなログを取り込み、
00:05:39IPアドレスとコードのペアでユニークなログを抽出し、IPの昇順と
00:05:47コードの降順で並べ替えます。実行結果を見ると、StulabはやはりSQLiteより
00:05:53高速ですが、14倍ではなく1倍から1.5倍程度の差でした。公式の数値は
00:06:01少し誇張されている印象ですが、StulabがSQLiteより速いのは事実です。
00:06:08公平を期すと、開発者もSQLiteの方が優れている点に言及しています。
00:06:13それは主に、単一の行を操作する場合です。つまりStulabは
00:06:19分析や複雑なクエリに特化しているのです。では、StulabはSQLiteキラーでしょうか?
00:06:26正直なところ、NOです。両者は用途が全く違います。SQLiteは今でも
00:06:32トランザクション用の信頼できる道具ですが、Stulabはデータ分析用の
00:06:38高性能なレーシングカーと言えます。しかし、NAPI-RSを通じてNode.jsで
00:06:45純粋なRust製分析エンジンを使えるのは非常に画期的です。あとは、ソースから
00:06:50ビルドせずに済むよう、NPMパッケージが修正されるのを待つだけです。以上がStulabの概要です。
00:06:55皆さんはどう思いますか?この性能向上のために乗り換える価値はありますか?
00:07:01それともSQLiteの信頼性を使い続けますか?コメント欄で教えてください。
00:07:06この動画が役に立ったら、ぜひ「いいね」ボタンをお願いします。
00:07:11チャンネル登録もお忘れなく。Better StackのAndrisでした。
00:07:17それではまた次回の動画でお会いしましょう。