この章では、データ・アフィニティを使用して、データが指定のパーティションに確実に存在するようにするための手順を説明し、デフォルトのパーティション分散方針の変更手順についても示します。
この章の内容は次のとおりです。
データ・アフィニティは、関連するキャッシュ・エントリ・グループが単一のキャッシュ・パーティションに含まれることを保証する概念を表します。これにより、フォルト・トレランスを犠牲にすることなく、すべての関連データが単一のプライマリ・キャッシュ・ノードで管理されます。
アフィニティは、(同じキャッシュ・サービスで管理されている通常のケースでは)複数のキャッシュにまたがります。たとえば、Order-LineItemのようなマスター/ディテール・パターンでは、Order
オブジェクトが、関連付けられているLineItem
オブジェクトのコレクション全体と共存する場合があります。
データ・アフィニティを使用する利点は2つあります。まず、一連の関連項目に対する問合せおよびトランザクションを、単一のキャッシュ・ノードのみで管理できます。また、すべての並行操作はローカルで管理可能であり、クラスタ化された同期処理は不要です。
アフィニティにより、キャッシュ問合せ、InvocableMap
の操作、およびgetAll
、putAll
、removeAll
などのメソッドを含むCoherenceのいくつかの標準的な操作を効率的に実行できます。
注意: データ・アフィニティは、値ではなくエントリ・キーに関して指定されます。その結果、対応付け情報がキー・クラスに存在している必要があります。同様に、対応付けロジックは、値クラスではなくキー・クラスに適用されます。 |
アフィニティは、パーティション・キーとの関係で指定されます。前述のOrder
-LineItem
の例では、Order
オブジェクトが正常にパーティション化され、LineItem
オブジェクトは適切なOrder
オブジェクトと関連付けられます。
この関連付けは実際の親キーに対して直接実行する必要はなく、親キーの機能マッピングになるだけで十分です。親キーの単一フィールド(一意でない場合でも可能)、または親キーの整数ハッシュとなる場合もあります。重要なのは、すべての子キーで同じ関連キーが返されることだけです。関連キーが実際のキーであるかどうかは重要ではありません(このキーは、単なるグループID)。これにより、親キーの情報を含まない子キー・クラスのサイズの影響を最小限に抑えることができます(導出データであるため、データ・サイズを明示的に決定できるほか、キー動作への影響もありません)。対応付けを汎用化しすぎると(同じグループIDに関連付けられたキーが多すぎる場合)、均一に分散されないことがあります(親キーに関係なく、すべての子キーが同じ対応付けキーを返した場合、子キーはすべて単一パーティションに割り当てられ、クラスタ全体には分散されない)。
一連のキャッシュ・エントリが共存していることを確認するには、2つの方法があります。対応付けが、値ではなくキャッシュ・キーに基づいていることを確認します(そうでない場合、キャッシュ・エントリを更新するとパーティションが変更される可能性がある)。また、Order
が子LineItems
と同じ場所にある場合、Coherenceは現在、複数のキャッシュにまたがる複合操作(単一の呼び出しリクエストcom.tangosol.util.InvocableMap.EntryProcessor
内でのOrder
およびLineItems
のコレクションの更新など)をサポートしていないことに注意してください。
アプリケーション定義のキーでは、キャッシュ・キーのクラスは次のようにcom.tangosol.net.cache.KeyAssociation
を実装できます。
アプリケーションでは、カスタムのKeyAssociator
も指定できます。
例28-2 カスタムのKeyAssociator
import com.tangosol.net.partition.KeyAssociator; public class LineItemAssociator implements KeyAssociator { public Object getAssociatedKey(Object oKey) { if (oKey instanceof LineItemId) { return ((LineItemId) oKey).getOrderId(); } else if (oKey instanceof OrderId) { return oKey; } else { return null; } } public void init(PartitionedService service) { } }
キー・アソシエータは、NamedCache
に関して、関連付けられている<distributed-scheme>
要素で構成できます。
例28-4は、アフィニティを使用してより効率的な問合せ(NamedCache.entrySet(Filter)
)およびキャッシュ・アクセス(NamedCache.getAll(Collection)
)を作成する方法を示しています。
例28-4 アフィニティを使用した効率的な問合せの作成
OrderId orderId = new OrderId(1234); // this Filter is applied to all LineItem objects to fetch those // for which getOrderId() returns the specified order identifier // "select * from LineItem where OrderId = :orderId"Filter filterEq = new EqualsFilter("getOrderId", orderId); // this Filter directs the query to the cluster node that currently owns // the Order object with the given identifier Filter filterAsc = new KeyAssociatedFilter(filterEq, orderId); // run the optimized query to get the ChildKey objects Set setLineItemKeys = cacheLineItems.keySet(filterAsc); // get all the Child objects immediately Set setLineItems = cacheLineItems.getAll(setLineItemKeys); // Or remove all immediately cacheLineItems.keySet().removeAll(setLineItemKeys);
パーティション分散では、パーティションがどのように、記憶域が有効なクラスタ・メンバーに割り当てられるかを定義します。次の2つの分散方法が使用可能です。
自律型分散 – これは、デフォルトの分散方針です。記憶域が有効な各サービス・メンバーは、自律的に動作して、サービスのバランスを取るために、使用可能なパーティションについて各自バランスの取れた割当てを計算し、分散をリクエストします。
集中管理型分散 – この分散方法では、集中パーティション割当て方針を使用して、記憶域が有効な各メンバーによってグローバルな分散決定が行われるようにします。集中管理型の分散は、より表現力のある分散アルゴリズムを使用することを可能にし、サービスに関するより完全でグローバルなビューを使用します。
自律型の分散方針は、デフォルトで有効です。自律型の分散方針を使用するには、割当て方針の実装が提供される必要があります。割当て方針は、com.tangosol.net.partition.PartitionAssignmentStrategy
インタフェースを実装する必要があります。Coherenceにはデフォルトの割当て方針の実装が含まれていますが、必要に応じてカスタムの割当て方針を作成して構成することができます。
単純なパーティション割当て方針は、デフォルトの自律型分散と同じようなパーティション・バランシング・アルゴリズムを使用する集中管理型の分散方法です。単純な方針では、記憶域が有効な各サーバーに応分の数のパーティションが分散される一方で、マシン、ラックまたはサイトの安全が(サービス・メンバーシップ・トポロジで許可されるレベルで)維持されます。割当て方針は、com.tangosol.net.partition.SimpleAssignmentStrategy
クラスで実装されます。このクラスは、必要に応じて拡張できます。
特定のパーティション・キャッシュ・サービスに対して単純なパーティション割当て方針を構成するには、分散キャッシュ定義内に<partition-assignment-strategy>
要素を追加し、<instance>
要素内に完全修飾クラス名を含めます。例:
<distributed-scheme> ... <partition-assignment-strategy> <instance> <class-name>com.tangosol.net.partition.SimpleAssignmentStrategy </class-name> </instance> </partition-assignment-strategy> ... </distributed-scheme>
分散キャッシュ・サービス・タイプのすべてのインスタンスに対してパーティション割当て方針を構成するには、オペレーション・オーバーライド・ファイル内のパーティション・キャッシュ・サービスのpartition-assignment-strategy
初期化パラメータをオーバーライドします。例:
<?xml version='1.0'?> <coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config" xsi:schemaLocation="http://xmlns.oracle.com/coherence/ coherence-operational-config coherence-operational-config.xsd"> <cluster-config> <services> <service id="3"> <init-params> <init-param id="21"> <param-name>partition-assignment-strategy</param-name> <param-value>com.tangosol.net.partition.SimpleAssignmentStrategy </param-value> </init-param> </init-params> </service> </services> </cluster-config> </coherence>
カスタムのパーティション割当て方針を指定するには、<partition-assignment-strategy>
要素内に<instance>
サブ要素を含めて、com.tangosol.net.partition.PartitionAssignmentStrategy
インタフェースを実装する完全修飾クラス名を指定します。<instance>
要素の使用の詳細は、「instance」を参照してください。次の例では、MyPAStrategy
クラスで実装されるパーティション割当て方針を有効にします。
<distributed-scheme> ... <partition-assignment-strategy> <instance> <class-name>package.MyPAStrategy</class-name> </instance> </partition-assignment-strategy> ... </distributed-scheme>
代替案として、<instance>
要素では、PartitionAssignmentStrategy
インスタンスを作成するためのファクトリ・クラスを使用する<class-factory-name>
要素、およびオブジェクトのインスタンス化を実行するファクトリ・クラス上で静的なファクトリ・メソッドを指定する<method-name>
要素の使用がサポートされています。次の例では、MyPAStrategyFactory
クラスでgetStrategy
メソッドを使用して、方針のインスタンスを取得します。
<distributed-scheme> ... <partition-assignment-strategy> <instance> <class-factory-name>package.MyPAStrategyFactory</class-factory-name> <method-name>getStrategy</method-name> </instance> </partition-assignment-strategy> ... </distributed-scheme>
実装に必要な初期化パラメータはすべて、<init-params>
要素を使用して指定できます。次の例では、iMaxTime
パラメータが2000
に設定されます。
<distributed-scheme> ... <partition-assignment-strategy> <instance> <class-name>package.MyPAStrategy</class-name> <init-params> <init-param> <param-name>iMaxTime</param-name> <param-value>2000</param-value> </init-param> </init-params> </instance> </partition-assignment-strategy> ... </distributed-scheme>