SpacetimeDB: 短い技術レビュー

← ホーム SpacetimeDB: 短い技術レビュー 2026-02-26 データベース市場は厳しく、特に新規参入者にとってはそうです。新しい製品を立ち上げ、既存の製品と差別化することは非常に困難です。長期的な定着を得ることはさらに困難です。 今週初め、SpacetimeDBはバージョン2.0をリリースしました。そのアプローチは、私の知る限り、これまで行われたことのない、ややシュール（ミーム的）なビデオで競合他社をからかい（「競合の涙」を飲む）、そして真実には見えない（実際、真実ではない）ベンチマークセットを提供し、他のデータベースもからかっています。そのベンチマークの大きな敗者の隣にあるかわいい虫眼鏡を見てください。どれほどひどいかを見るにはズームインする必要があります！素晴らしい。 率直に言って、私はこれが品がないと感じることを認めます。しかし、それでも、この製品には興味深いアイデアがあると思います。そして、できる限り公平に、短い技術レビューを行いたいと思います。 ベンチマーク データベース分野の新規参入者が犯す一般的な間違いの一つは、「最高のパフォーマンス」を持つことで勝てると信じることです。私はこれを実際には見たことがありません。持続可能なデータベース製品を構築した（ごく少数の）企業は、それ自体で通用する、誠実で優れた技術作業を提供することで勝利しています。もちろん、ベンチマークがあることはそれに役立ちます。しかし、そのベンチマークは、誠実で優れた技術作業でなければなりません。 SpacetimeDBが提供したものは、そのどちらでもありません。測定しているものには、かなりの技術的な欠陥があります。ここでは、SpacetimeDBが競合に対して非常に劣る結果を示す、別のベンチマークセットを見ることができます。それにもかかわらず、それらのベンチマークの大きな根本的な欠陥は、それらが誠実ではないということです。そして、私は彼らがどこから来ているのか理解しています。彼らは誠実ではありません。なぜなら、彼らのデータベース製品は競合製品とは非常に異なるものであり、そのようなベンチマークを書くことが非常に魅力的だからです。彼らの製品はデータベース空間の異なるセグメントにあり、彼らは異なるトレードオフを行っているデータベースと比較することを選択しています。魅力的な比較ですが、公平ではありません。 私が自分で経験した例を挙げましょう。数年前、私はPlanetScaleで働いており、ベクトル類似性検索のためのMySQL拡張機能をリリースしました。実装には非常に具体的な目標がありました。それは、他のすべてのものとは非常に異なっていました。なぜなら、それは完全にトランザクション対応であり、ベクトルデータはMySQLのバッファプールによって管理され、ディスクに保存されていたからです。これは、HNSWを使用し、類似性グラフがメモリに収まる必要があるpgvectorのような、より単純なアプローチとは対照的です。それは非常に異なる製品であり、非常に異なるトレードオフがありました。そして、32GBのRAMを搭載したEC2インスタンスに64GBのベクトルデータをデータベースに投入することは、非常に魅力的でした。次に、Postgresインスタンスとpgvectorでも同じことを行います。まったく同じマシン、まったく同じデータセットです！同じクエリを実行しています！しかし、PlanetScaleは毎秒数万件を処理し、pgvectorはHNSWグラフがディスクからページングされ続けるため、1つのクエリを完了するのに3秒以上かかります。 ベンチマークでそれを示すのは確かに非常に魅力的でした。「pgvectorの10000倍高速！」しかし、落ち着いてください。それは誠実ではありません。はい、同じマシン、同じデータセット、同じクエリですが、それは同じものではありません。私たちはそれらのベンチマークを公開しませんでした。代わりに、不公平な比較なしに、実装の技術的な詳細を公開しました。それは非常によく受け止められました。 これに勝つために「驚異的なベンチマーク」は必要ありません。堅実な技術作業と、製品のトレードオフと制限を説明する堅実な技術文書があれば十分です。Turbopufferの別の例を見ることができます。彼らのベンチマークは、特に競合他社と比較した場合、印象的ではありません。彼らのドキュメントには、データベースができることよりもできないことについて議論している行の方が多いです。しかし、あなたのユースケースが彼らの製品に合っていれば、彼らが市場で検索のための最高の製品を持っていることは誰もが知っています。競合他社を圧倒するほどです。彼らは競合の涙を飲みません。ただ静かに顧客を獲得するだけです。 anyway: SpacetimeDBとそのベンチマークに戻りましょう。彼らは競合他社とは非常に異なる製品を提供しています！それは、データベースとアプリケーションサーバーのオールインワンであり、データベースインスタンスをデプロイすると、アプリケーションのコードがデータベース自体の中で実行されます。それは非常に興味深いアイデアだと思います。リレーショナルデータベースのストアドプロシージャのようなものだと言うこともできますが、開発者体験は優れています。公平です。しかし、それから実行可能な製品を完全に構築できます！ しかし、それがベンチマークを行っているマルチリージョンで高可用性の分散データベースとはほとんど関係がないことを認めなければなりません。アプリケーションコードがデータベース内で実行されており、競合他社が各クエリに対して個別のネットワークリクエストを実行する必要がある別のアプリケーションを持っている場合、QPSを測定するベンチマークでは確かに先行するでしょう。しかし、それらは誠実なベンチマークですか？それは、技術的な提供を評価している潜在的な顧客に見せたい比較ですか？ 私は、それを強調するのはあまり良いことではないと言います。インメモリのデータにアクセスすることは、ネットワーク経由でデータにアクセスすることよりも高速であり、それを証明するためにベンチマークハーネスを構築しました。潜在的なユーザーとして、私はあまり感銘を受けていません。マーケティングの観点からは、インメモリでデータにアクセスできる速さを示し、その速度を得るために行ったトレードオフを説明する方がはるかに興味深いと思います。 私が把握している限り、ウェブサイトにはこれを説明する明確な技術的な内訳はありません。ここで試してみましょう。 ストレージ SpacetimeDBが公開した合成ベンチマークで、これほど優れた書き込みパフォーマンスを示すのにはいくつかの理由があります。明らかに、最も明白な理由は、アプリケーションロジックがデータベースの隣でローカルに実行され、そのようにデータストアに書き込む際に非常に効率的であることです。彼らは他のトリック（書き込みのバッチ処理など）でこの効率をさらに高めていますが、彼らが示しているパフォーマンス数値を達成するには、どこかで手抜きをする必要があります。データストアはインメモリであり、これは従来のRDBMSとは大きく異なります。 さて：良いニュースは、インメモリストアへの書き込みは線形化可能であるということです。しかし、悪いニュースもあります。システムの線形可能性を証明することは通常、困難な作業です。私はここでそれを証明するためにTLA+を取り出す必要はありませんでした。それはここに簡単に証明できます。なぜなら、システムは、まあ、ロックの前にハッシュテーブルがあるからです。 これは誇張のように聞こえるかもしれませんが、信じてください。これはストレージエンジンの設計方法の非常に正確な説明です。SpacetimeDBインスタンス内のデータベース全体のコミット済み状態は、単一のRead-Write Mutexでラップされています。すべての書き込み操作はシーケンシャルに発生するため、線形化可能性の証明は確かに簡単です。2つの書き込みが同時に発生することはできないため、競合したりレースしたりすることはありません。しかし、読み取りと書き込みも同時に発生することはできません！ 書き込みが多すぎるとどうなりますか？読み取り側は飢餓状態になりますか？読み書きセマンティクスを持つ単一のグローバルロックの上にデータストアを構築することは、有効な技術的選択です。おそらく、それを「データベース」としてマーケティングするのは少し疑問ですが。しかし、このアプローチにすべてを賭けるなら、そのロックがデータベース全体の同時実行制御を提供するのであれば、サーバーがワークロードに関係なく応答性を維持することを保証するために、読み取り側と書き込み側の優先順位付けのための非常に明確でカスタマイズ可能なセマンティクスが必要だと思います。 この場合、動作は実装の詳細であり、どこにも特に定義も説明もされていません。ミューテックスは、parking_lotクレートの市販のparking_lot::RWMutexです。これは最終的な公平性を持っており、高い書き込みスループットのシナリオでも、読み取り側は最終的にロックを取得します。ただし、ランダムに遅延する可能性があり、最大0.5ミリ秒です。parking_lotクレートはWのRustポートです。