eXtreme Scale のスケーラブル・データ・モデル

Microsoft Northwind サンプルは、Order Detail 表を使用して多対多のアソシエーションを Order と Product の間で確立します。

ADO.NET Entity Framework および Java Persistence API (JPA) などのオブジェクト・リレーショナル・マッピング仕様 (ORMs) は、エンティティーを使用する表やリレーションシップをマップすることができます。 ただし、このアーキテクチャーは拡張されません。すべてが同一マシン上、あるいはうまく機能するような高価なマシンのクラスター上に存在していなければなりません。

図 1. Microsoft SQL Server Northwind サンプルのスキーマ図
Microsoft SQL Server Northwind サンプルのスキーマ図: お客様が 1 つ以上のオーダーを作成します。オーダーには製品が含まれており、その製品はカテゴリーに属している場合があります。

拡張が容易な種類のサンプルを作成するためには、各エンティティーまたは関連エンティティーのグループが単一キーを基にして区画に分割できるように、エンティティーをモデル化する必要があります。単一キーに基づいて区画を作成することで、複数の独立したサーバーに要求を分散させることができます。 この構成を実現させるために、エンティティーを 2 つのツリーに分割しました。Customer および Order のツリーと、Product および Category のツリーです。このモデルでは、各ツリーは個別に区画に分割することができるため、異なる速度で、スケーラビリティーを高めながら成長できます。

図 2. Customer および Order エンティティーのスキーマ図
Customer および Order エンティティーのスキーマ図: お客様がオーダーを作成します。それぞれのオーダーには詳細なオーダー情報が含まれています。

例えば、Order と Product はいずれも固有な、別の整数をキーとして持っています。 つまり、Order 表と Product 表は本当にお互いに独立しています。 例えば、カタログのサイズや販売する製品数の、オーダー総数への影響を考えてみます。 直感的に、多くの製品を持てば多くのオーダーを受けることを意味するようにも思えますが、これは必ずしもそうとは限りません。これが真実であれば、カタログにより多くの製品を追加するだけで、簡単に売り上げを伸ばすことができるでしょう。 オーダーと製品には、それぞれ独自の独立した表があります。 オーダーと製品がそれぞれ独自に別々のデータ・グリッドを持つように、この概念をさらに拡張することができます。独立したデータ・グリッドを使用すると、アプリケーションが拡張できるように、各データ・グリッドの個別のサイズの他に、区画数およびサーバー数を制御することができます。 カタログのサイズを 2 倍にすると、製品グリッドを 2 倍にする必要がありますが、オーダー・データ・グリッドはおそらく変わりません。 オーダーの急増、または予測されるオーダーの急増に関しては、その逆が真実となります。

スキーマでは、Customer にはゼロ以上の Order があり、Order は 1 つの特定製品それぞれに明細行 (OrderDetail) があります。 Product は、各 OrderDetail で ID (製品キー) によって識別されます。単一データ・グリッドは、Customer をデータ・グリッドのルート・エンティティーとして使用し、Customer、Order、および OrderDetails を保管します。Customer を ID で取得することができますが、Customer ID から始めて Order を取得しなければなりません。そのため、Customer ID は Order にそのキーの一部として追加されます。同様に、カスタマー ID およびオーダー ID は OrderDetail ID の一部です。

図 3. Category および Product エンティティーのスキーマ図
Category および Product エンティティーのスキーマ図: 各製品は、それぞれカテゴリーに属しています。

Category および Product スキーマでは、Category がスキーマ・ルートです。 このスキーマにより、カスタマーはカテゴリーごとに製品を照会することができます。 キー・アソシエーションおよびその重要性のさらに詳細な情報については、REST を使用したデータの取得および更新 を参照してください。