【PCDBE】WEB問題集:スケーラブルなDBソリューション設計編

正解：A

正解の根拠

Spanner のマルチリージョン構成は複数のリージョンに read-write レプリカを配置し、TrueTime が与えるグローバルに一貫したタイムスタンプで全トランザクションを順序付けます。これによりリージョンを跨いだ読み書きでも外部整合性を保った ACID トランザクションが成立します。書き込みは Paxos による多数決でコミットされるため、1 リージョンが失われても残りのレプリカで処理を継続でき、99.999% の可用性 SLA が適用されます。データはキー範囲のスプリット単位で自動的に再分散され、処理ユニットの追加で水平にスケールします。

不正解の理由

• B: クロスリージョンのリードレプリカは非同期複製のため常に遅れた状態を読み、書き込みを 1 リージョンに集約するとそのリージョン障害で書き込み自体が止まります。
• C: Bigtable で原子性が保証されるのは単一行の更新までで、複数行にまたがる ACID トランザクションを提供しません。
• D: リージョナル構成の AlloyDB はゾーン冗長にとどまり、リージョン全体の障害では可用性を失うため 99.999% には届きません。

参考：Spanner Instance Configurations

正解：B

正解の根拠

Bigtable は行キーの辞書順に行を並べ、キー範囲でタブレットに分割して各ノードへ割り当てます。行キーの先頭にハッシュを置くと書き込み先のキーが散らばるため、時刻を先頭にしたときのように直近のタブレットへ書き込みが集中しません。続くデバイス ID で同じデバイスの行が連続して並び、最後に逆順タイムスタンプ（長整数の最大値からエポック値を引いた値）を置くことで新しい行ほど手前に来るため、直近区間の取得が 1 回のレンジ スキャンで完了します。SSD クラスタは読み取りレイテンシが小さく、ノードを足せばスループットをほぼ線形に伸ばせます。Bigtable は行キーを 1 つしか持たずセカンダリ インデックスも無いため、書き込みの分散と読み取りの局所性を同じ行キーで両立させるこの設計が要点になります。

不正解の理由

• A: Cloud SQL は書き込みを単一のプライマリで受けるため、パーティションを切ってもシャードを並べても 1 台あたりの上限が積み上がるだけで、毎秒 80 万件を継続的に取り込む構成にはなりません。
• C: Firestore は同一ドキュメントへの更新頻度に制約があり、サブコレクションで分けても時間範囲の取得は多数のドキュメント読み取りになって費用とレイテンシが積み上がります。
• D: Spanner はインターリーブで局所性を確保できますが、5 年分を保持しつつ毎秒 80 万件を捌くには相応のコンピュート容量が必要で、同じ要件を満たす費用は Bigtable より大きくなります。

参考：Bigtable 時系列スキーマ設計

正解：C

正解の根拠

AlloyDB for PostgreSQL のカラムナ エンジンは、対象の表やマテリアライズド ビューの列をメモリ上の列形式で保持し、専用のプランナと実行エンジンでスキャン・結合・集計を処理します。同じデータを行形式のまま更新して OLTP を継続しながら、分析クエリだけを列形式の経路で処理できるため、別システムへ ETL することなく単一インスタンスで HTAP が成立します。PostgreSQL 互換なので既存のアプリと SQL もそのまま利用できます。

サービス比較

不正解の理由

• A: リードレプリカを増やしても各レプリカは行形式のまま同じスキャンを行うため、分析クエリの処理方式が変わらず大幅な高速化になりません。
• B: 定期 ETL は取り込み間隔の分だけデータが古くなり、同じデータをその場で分析するという HTAP の要件を満たせません。
• D: Bigtable は行キー中心のキー値ストアで、PostgreSQL 互換の SQL や結合を伴う分析をそのまま実行できません。

参考：AlloyDB Columnar Engine

正解：B, C

正解の根拠

Spanner は行を主キーの順序で並べて保存し、キー空間をスプリットに分けて複数のサーバーへ割り当てます。そのためキーの先頭が単調に増えると、新しい行がすべて同じ末尾のスプリットに集まり、そのスプリットを担当するサーバーだけが書込を受け続けます。主キーの先頭にキーのハッシュ値やバージョン 4 の UUID を置けば、書込先がキー空間全体に散り、スプリットの分割に応じて複数のサーバーへ負荷が分かれます。インターリーブは子行を親行と同じスプリットに配置する仕組みで、子行の配置が親キーの分布に従うため、親キーが散っていれば子行の書込も散り、親子への読み書きが 1 か所で完結します。

不正解の理由

• A: タイムスタンプを主キーの先頭に置くと、直近の書込がキー空間の末尾に並び、1 つのスプリットに挿入が集まります。スプリットを分割しても新しい行は常に末尾側へ入るため、負荷が広がりません。
• D: 自動採番のシーケンス ID も値が単調に増えるため、末尾のスプリットに書込が集中します。全テーブルに一律で付与すると、この集中がテーブルの数だけ発生します。

参考：Spanner Schema Design

正解：A

正解の根拠

Firestore の Native モードは、ドキュメントの変更をクライアントが購読して即座に受け取るリアルタイム リスナと、通信が切れている間の読み書きを端末側にキャッシュして復旧時に同期するオフライン永続化を標準で備えます。データ モデルはドキュメント指向で、マルチリージョンのロケーションを選べば複数リージョンへ複製されるため、世界各地の利用者が近いレプリカに対して低レイテンシで読み書きできます。同期処理を自前で実装せずに、要件の3点をマネージドのまま満たせます。

不正解の理由

• B はリレーショナル モデルの管理型データベースで、クライアントへの変更通知や端末側のオフライン同期を提供せず、同等の仕組みを自前で作る必要があります。
• C はワイドカラム型で大量データの高スループット処理に向く一方、変更を購読するリスナやクライアント SDK のオフライン同期を備えません。
• D はインメモリ主体のデータストアで、主データストアに据えると恒久的な保存の要件を満たせません。

参考：Firestore 公式ドキュメント