今日のデータベースにはACID特性だけでなく、スケーラビリティーが求められる。従来のRDBだけではデータ量の増減に対応するためのスケールイン／アウトは難しい。PostgreSQLの機能拡張である米マイクロソフトの「Hyperscale」の活用が考えられる。
DX（デジタルトランスフォーメーション）において、データ量の増減に柔軟に対応することは避けて通れません。そのため今日のデータベース（DB）には従来のACID（Atomicity、Consistency、Isolation、Durability）特性だけでなく、スケーラビリティーが求められます。しかし、従来のリレーショナルデータベース（RDB）だけではデータ量の増減に対応するためのスケールアウト／スケールインの実現は困難です。そうしたニーズに対して一般的には非リレーショナルデータベースであるNoSQL（Not Only SQL）が選択されます。
ただし、NoSQLには次のような問題があります。「完全なACID特性を提供しない」「エンジニアの追加学習コストがかかる」「既存のRDBとのデータ連係が難しい」――などです。一口にNoSQLといっても様々な製品が存在し、その性質や得意分野は異なります。そのためサービスに最適な製品を選ぶには、その製品とアプリケーションの性質を熟知する必要があります。さらにサービスの特性によっては複数種のNoSQL製品を利用する必要があり、各製品間でのデータ同期の難しさといった問題も発生します。
「Hyperscale（Citus）」は米マイクロソフトの「Azure Database for PostgreSQL（Azure PostgreSQL）」で提供される「デプロイオプション」です。PostgreSQLのフォーク（派生）ではなく機能拡張です。Hyperscaleを利用すれば、従来のRDBのメリットを維持したまま高いスケーラビリティーを享受できます。従来のPostgreSQLで利用できるコマンドもそのまま使えます。既にPostgreSQLのスキルを持つエンジニアであればHyperscaleの利用に対する学習コストはあまりかかりません。以下ではHyperscaleのアーキテクチャーや特徴、PostgreSQLとの違い、注意点について説明します。そして、それらを踏まえてどのようなサービスにフィットするかを解説します。
アーキテクチャーとその特徴
Hyperscaleは1台のコーディネーターノードと2台以上のワーカーノードで構成します。コーディネーターノードの役割はどのデータがどのワーカーノードに存在するのかというメタデータを適切に管理し、アプリケーション（クライアント）からリクエストを受け取り、その内容に従ってクエリーを適切なワーカーノードにプッシュダウンすることです。
プッシュダウンとは一般的に検索条件による絞り込みをサーバー本体ではなく別のサーバーにさせることです。一方ワーカーノードの役割はコーディネーターノードからプッシュされたクエリーを実行し、その結果をコーディネーターノードに返すことです。最終的な結果はコーディネーターノードを通してクライアントに返されます。
例えば対象となるデータがワーカーノード＃1に存在する場合、コーディネーターノードはワーカーノード＃1にのみクエリーをプッシュし、その結果をアプリケーションに返します。必要なデータが存在するワーカーノードにのみアクセスすればよいため、1台のDBと比べて並列性が向上します。
一方で分析クエリーのようにすべてのデータを集計するクエリーに対しては、コーディネーターノードはすべてのワーカーノードにクエリーをプッシュし、個々のワーカーノードがそれぞれ集計します。これにより1台のサーバーで集計処理をするより高速なレスポンスが期待できます。
アプリケーションから見るとコーディネーターノード1台だけでクエリーが完結しているため、まるで1台のPostgreSQLサーバーに接続しているかのように見えます。なお、アプリケーションはコーディネーターノードにのみ接続可能で、ワーカーノードには直接アクセスできません。
