SpacetimeDB、ベンチマークは不誠実 技術的評価
SpacetimeDB: A Short Technical Review
SpacetimeDBが先週公開したv2.0のベンチマークは、競合を揶揄する動画とともに「不誠実」だと評されている。同社のDBはアプリケーションコードをDB内で実行する独自設計で、インメモリで動作するため、ネットワーク越しにクエリを送る競合より高速なのは当然だ。ストレージは単一のグローバルロックで保護されたハッシュテーブルで、書き込みは直列化され、読み取りも書き込みと同時には実行できない。WALは非同期でディスクにフラッシュされるため、永続性も限定的だ。
「彼らは競合の涙を飲むのではなく、静かに顧客を奪っていくのです」
HNでの議論
50- Devont
Volt Active Dataと比較したベンチマークを見た人はいますか？
前提が似ていて、開発も進んでいるように見えます。SpacetimeDBについて知って以来、その前提には使い道があると思っていましたが、新しすぎることと、その背後にある奇妙なマーケティングをあまり信用していません。
- LarsDu88
友人がまだMMORPG路線を追求していた頃にこれを見せてくれたのを覚えていますが、その取り組みに費やされた不必要な過剰設計を考えると、この会社がまだ存続していることに驚いています。
ECSのようなロジックをコードとして置き、そのコードをすべてストアドプロシージャとして置くというモデルは、20年前にMMORPGが全盛でコンピュータが今より100倍から1000倍遅かった時代に、主要なMMORPGが実際には問題にしていなかったデータベーストランザクションの問題をいくつか解決します。多くのエンジニアリングが、20年前には問題ですらなく、今日ではさらに問題になっていないデータベースのラウンドトリップを解決し排除することに向けられています。
一方、ロールバック、物理、衝突など、マルチプレイヤーゲームを構築する際の実際の難しい部分については、これは実際には何の助けにもなりません。むしろ、それらをさらに難しくします。このゲームの開発者は、物理に似たものを動かすために、データベースの恩恵を受けなかったであろうかなり興味深いハックを考え出さなければならなかったのではないかと思います。
その上に、データベース内でストアドプロシージャを使用することに関する既知のアンチパターンが重なっていますが、SpacetimeDBはそれをまったく解決していません。アプリケーションロジックがクライアントとDBサーバーに分割されているため、クライアントだけでテストを実行することはできず、スパゲッティコードとゲームデザインの反復サイクルの悪化につながります。データベース自体も水平方向にスケールしません…
- nemothekid
SpacetimeDBのローンチビデオがYouTubeのフィードに表示されましたが、実装方法についてまったく触れていなかったのに驚きました。独自の魔法だと思っていましたが、オープンソースであることを知ってさらに驚きました。それでさらに混乱しました。彼らが話していたようなセマンティクスを実現するには、かなり斬新なものだと思っていたので、オープンソースならそれを前面に出すべきでしょう。
結局、Rustで書かれた2015年頃のReact Fluxをミューテックスで囲んだものだというのを見て、少しがっかりしました。
- cloutiertyler
私はSpacetimeDBの開発者ですが、この投稿には多くの不正確な点があります。実際にVicentに修正を依頼し、彼は対応することに同意しました。
これと他の批判に対する私たちの回答はこちらで読めます: https://spacetimedb.com/blog/benchmarking
- Escapado
技術的な観点からこの記事には感謝しています。ここで、批判に関係なく本番環境で使用した人はいますか？また、実際にどこがうまくいかないのか、パフォーマンスが大幅に低下する状況についての見解を共有できる人はいますか？彼らがMMOをこれで構築したという事実は、このパターンの技術的な制限が、特定のワークロードや実装が不十分なリデューサーにのみ影響することを示しているように思えます。そして、私の直感では、PostgresやSQLiteを使っても、非効率なクエリを書けばすぐにシステムが遅くなることもあります。実際の世界でどうだったのか興味があります。