SpacetimeDBは、あらゆるインフラ企業がいずれ直面する「スケールするのか？」という問いへの回答を試みる長編の技術論考を公開した。

「Ok, but does it scale?（分かった、でもスケールするのか？）」と題されたこの投稿は、「スケール」という言葉は、計算、ストレージ、ネットワークという3つの異なる側面に分けなければ、有用と言えるには曖昧すぎると論じている。この枠組みが、SpacetimeDB自体について同論考が示す回答の基盤となっている。同社によると、ストレージは比較的すっきりと水平スケーリングできるが、計算とネットワークは別の問題であり、特にトランザクション同士が競合する場合はそうだという。

同論考は、マシンを増やすことでより多くの処理ができるシステムと、単に調整のオーバーヘッドを増やすだけのシステムを明確に区別している。一部の汎用水平分散データベースはスケールをうたっているものの、多数のトランザクションが同じデータにアクセスすると性能が大きく低下するとしている。そうした場合、調整のコストが、処理をクラスター全体に分散する利点を上回り得る。この投稿は、Postgres、Neon、Spanner、CockroachDBといったよく知られた例を使ってトレードオフを説明する一方、これらのシステムはいずれも優れたエンジニアリング上の成果であることも強調している。

中心的な主張の一つは、競合が素朴な水平スケーリングの敵だということだ。多数のクライアントが同じ行または同じ論理オブジェクトを更新する必要がある場合、システムは、何を誰が所有し、どのバージョンが有効なのかを調整しなければならない。同論考によれば、そのため、机上では並列に見える処理が、実際には逐次処理になり得る。だからこそ、その説明によれば、データベースのスケーリングは単にノードを追加することではない。ワークロードを、異なるコンピューターが同時に処理できる部分へ実際に分割できるかを理解することなのである。

記事はアーキテクチャー上の事例にも時間を割いている。Neonの設計では、データをオブジェクトストレージに置けるため、ユーザーは事実上無限のストレージを利用できる一方、書き込みは依然としてプライマリーを経由すると論じている。また、Spannerのテーブル・インターリービングは関連データを同じ場所に配置するのに役立つ一方、同じ手法を以前サポートしていたCockroachDBでは、得られる利点に比べて複雑すぎるとして最終的に削除されたという。要点は、あらゆる場合に一方のデータベースが「勝ち」、もう一方が「負ける」ということではない。各システムは異なる形でスケールし、適切な選択はワークロードの性質によって決まるということだ。

SpacetimeDBによれば、同社の手法は、並列化可能なOLTPワークロードをスケールしやすくしながら、競合時にも性能を維持するというものだ。これは、一部の分散データベースが掲げるものより限定的な約束だが、現実のソフトウェアに何ができ、何ができないのかについて、より率直でもある。同論考は、スケーラビリティはほとんど魔法のような特性として売り込まれることが多いが、実際にはそれぞれにコストを伴うエンジニアリング上の妥協の集まりだと論じている。

開発者にとって有用な要点はそこにある。ワークロードの大半が互いに独立した読み取りや書き込みであれば、ストレージと計算は多くの場合、分散できる。ワークロードが共有オブジェクト、カウンター、アクセスの集中する行に偏っている場合、多額の費用を投じても、より小規模で単純なシステムより悪い結果になる可能性がある。同論考の主張は、そうしたトレードオフは本番運用の請求書が届いてから発覚するのではなく、あらかじめ明示されるべきだというものだ。

結果として、これは製品論の一部であると同時に、データベースの入門解説でもある。「スケールするのか？」という問いだけではなぜ不適切なのか、そして真剣に取り組むチームは、具体的に何がスケールするのか、つまりストレージ、計算、ネットワーク、あるいはその3つすべてなのかを問うべき理由を説明している。SpacetimeDBの答えは、大半のシステムは均等にはスケールせず、そうでないふりをすることでアーキテクチャー上の負債が高くつくため、この区別は重要だというものだ。