区画化を使用して、アプリケーションをスケールアウトします。区画の数は、デプロイメント・ポリシーで定義できます。
区画化は、新磁気ディスク制御機構 (RAID) ストライピングと同様のものではありませんが、各インスタンスをすべてのストライプ間でスライスします。各区画により、個別エントリーの完全なデータがホスティングされます。区画化は、非常に有効なスケーリング手段ですが、すべてのアプリケーションに適用できるわけではありません。複数の大規模なデータ集合にわたってトランザクションの保証を 必要とするアプリケーションをスケールアウトすることはできず、効果的に区画化することも できません。WebSphere® eXtreme Scale は、区画をまたがる 2 フェーズ・コミットを現在のところサポートしていません。
1 つのデータ・グリッドに、最大数千個の区画を作成することができます。データ・グリッドは、区画の数に区画ごとの断片の数を掛けた結果の大きさまで拡張できます。例えば、16 個の区画があり、各区画にはプライマリーとレプリカがそれぞれ 1 つずつ、つまり 2 つの断片があるとすれば、潜在的には 32 個の Java 仮想マシンまで拡張できることになります。この場合、JVM ごとに 1 つの断片が定義されます。使用する可能性が高い Java 仮想マシンの予定数に基づいて、適切な区画数を選択する必要があります。断片が 1 つ増すごとにシステムのためのプロセッサーおよびメモリーの使用量が増加します。 システムは、使用可能な Java 仮想マシンの数に応じてこのオーバーヘッドを処理するように拡張される設計になっています。
アプリケーションが 4 つのコンテナー・サーバー Java 仮想マシンのデータ・グリッドで実行される場合は、アプリケーションが数千もの区画を使用しないようにしてください。アプリケーションは、それぞれのコンテナー・サーバー JVM について、適切な数の断片を持つよう構成する必要があります。例えば、2 つの断片を持つ 2000 の区画が 4 つのコンテナー Java 仮想マシンで稼働するという構成は適切ではありません。このような構成では、4 つのコンテナー Java 仮想マシンに 4000 個の断片が配置されるか、またはコンテナー JVM ごとに 1000 個の断片が配置されることになります。
予定される各コンテナー JVM の断片を 10 未満に構成することをお勧めします。それでもなお、この構成では、コンテナー JVM ごとの断片の数を適切に保ちながら、初期構成の 10 倍の柔軟性のある拡張を行える可能性があります。
次のような拡張例を検討してください。現在、6 台の物理サーバーがあり、物理サーバーごとに 2 つのコンテナー Java 仮想マシンがあるとします。今後 3 年間で、物理サーバーを 20 台まで増やす予定です。物理サーバーが 20 台ある場合、コンテナー・サーバー Java 仮想マシンは 40 になりますが、余裕を持って 60 を選択することにします。コンテナー JVM ごとに 4 つの断片が必要です。60 のコンテナーでは、断片は合計 240 になります。区画ごとにプライマリーとレプリカがあるとすると、120 の区画が必要になります。この例は、240 を 12 のコンテナー Java 仮想マシンで除算すること、つまり後でコンピューターを 20 台まで拡張できるようにするため、初期デプロイメント時にコンテナー JVM ごとに 20 の断片を想定することを示しています。
@Entity(schemaRoot=true)このエンティティーを使用してオブジェクト・グラフのルートを検出することができます。オブジェクト・グラフは、1 つ以上のエンティティー間のリレーションシップを定義します。 リンクされた各エンティティーは同じ区画に解決される必要があります。 すべての子エンティティーはルートと同一の区画にあると仮定されます。オブジェクト・グラフ内の子エンティティーへのアクセスは、ルート・エンティティーのクライアントからのみ可能です。 区画化環境で は、eXtreme Scale クライアントを使用してサーバーと通信するときに、常にルート・エンティティーが 必要です。クライアントごとに定義できるルート・エンティティー・タイプは、1 つのみです。Extreme Transaction Processing (XTP) スタイルの ObjectGrid を使用している場合は、区画とのすべての通信が、クライアントおよびサーバー機構ではなく、直接のローカル・アクセスによって実行されるため、ルート・エンティティーは必要ありません。