インメモリデータグリッド。 操作モード、インデックス、ロック

In-memory-data-gridトピックに関する一連の短い記事を続けます。

最初の記事では、具体的な例や実装の詳細なしにIMDGの概念が明らかにされました。 今日はもう少し掘り下げます。

IMDGモード

動作モードは特定のIMDGソリューションに応じて根本的に異なるわけではないため、個々のソリューションではなく、IMDGコンセプト全体について次のことが当てはまります。

1.ローカルモード

このモードでは、IMDGクラスターは1つのノードのみで構成されます。 主にデバッグ目的でのみ使用されます。

2.複製モード

複製モードでは、完全なデータセットがクラスター内の各ノードに複製されます。







長所 ：

• データへの高速アクセス、として すべてのデータはクラスターの各ノードで利用可能です
• いずれかのノードが失われても、クラスターの再調整は行われません。 データを再配布する必要はありません

短所 ：

• このモードは、操作に必要なすべてのデータが1つのノードのメモリに保存されている場合にのみ適用されます
• 増加したメモリ消費
• クラスター内のオブジェクトのPUTは、すべてのノードでこのオブジェクトの更新につながる必要があるため、クラスター内のデータの一貫性を確保するには追加の作業が必要であるため、このモードでのPUTは遅くなります
• 各PUTは各ノードへのデータ複製を必要とするため、スケーラビリティが制限されます

各PUTにそれほど時間がかからないようにするために、非同期で実行できます（多くのIMDGがこのような機会を提供します）が、データの一貫性について回答できるのは自分だけです。 したがって、書き込み集中型のシステムではこの操作モードを使用しません。

3.分散モード

IMDGの最も興味深い使用モード。このコンセプトのすべての肯定的な品質を評価できます。







この政権の説明は前の記事の基礎でした。

指数

IMDGでデータを検索するには、逆索引検索が使用されます。

1. Oracle Coherence

インデックスは、MapIndexインターフェイスを実装するオブジェクトによって表されます。

現在（Oracle Coherence 3.7）、2つのインデックス実装が利用可能です：

• SimpleMapIndex-通常の逆索引
• ConditionalIndex-キャッシュオブジェクトにインデックスを付ける条件を設定できるのとは対照的に、SimpleMapIndexを拡張します

インデックスが配布されます、つまり クラスターの各ノードでは、そこに含まれるデータのみがインデックス付けされます。 クラスター全体に対して要求を実行する場合、各ノードは一般応答の一部を個別に計算し、これらの部分は要求が行われたノードに転送され、そこで1つの共通の回答に組み立てられます。

要求が一度に複数のインデックスへのアクセスを必要とする場合、最初に各インデックスに対して回答が形成され、次に最終結果を取得するために判明したそれらのセットが互いに交差します。 この交差はすぐには発生しないため、複数のインデックスへのアクセスを必要とするリクエストを行う前に、巨大なキーセットの交差につながるかどうかを考える必要があります。



長所 ：

• 分散インデックスParallels検索
• インデックスを作成するオブジェクトを制御できます。

短所 ：

• 複数の大きなセットを横断すると、インデックス化されていないデータを検索するよりも時間がかかる場合があります
• このようなインデックスの検索速度は、ビットセットに基づくインデックスの検索速度よりも遅くなります。
• インデックスの更新は増分です。つまり、 インデックスにオブジェクトを追加するとき、完全に再構築する必要はありません

2. JBoss Infinispan

ここでは、 Apache Lucene （オープンソース全文検索エンジン）とHibernateSearch （同じLuceneに基づいています）がキャッシュ検索に使用されます。

この選択には重大な欠点がありますが、利点もあります。

長所 ：

• インデックスに対するクエリの結果はビットセットであるため、そのようなセットの共通部分（クエリで複数のインデックスを検索する必要がある場合）は安価な操作です。
• 全文検索のサポート
• クイック検索（バイナリマスクを適用することで行われるように）

短所 ：

• インデックスは配布されず、Apache Lucene Directoryに保存されます（より正確には、ALD自体の実装に適合したものです）
• 一度に1つのスレッドのみがインデックスを更新できます
• 完全な再構築のみによるインデックスの更新

3. VMWare Gemfire

データのインデックスを作成する場合、 主キーインデックスと機能インデックスの 2種類のインデックスが使用されます 。



これらの違いは、主キーインデックスを使用すると、インデックス付けされた属性の値をチェックして定数が等しいかどうかを確認できることと、機能インデックスを使用して比較を実行できることです。 たとえば、フィールドsomeField> 10を持つオブジェクトを選択できます。



インデックスの更新は、同期（一貫性を確保）または非同期（インデックス更新率）で実行できます。



一般に、長所と短所はOracle Coherenceの長所と短所と同じです。

4.ヘーゼルキャスト

インデックスをタイプに分離することはありませんが、インデックスの動作原理はOracle Coherenceの原理と同じであるため、インデックスを個別にペイントすることは意味がありません。

ロック

アプリケーションがオブジェクトへのデータのマルチスレッド書き込みを許可している場合、通常、データの整合性を確保するためにロックメカニズムが使用されます。 また、同じマシン内にいる場合、このメカニズムは確実に機能します。 しかし、データがクラスター全体に分散している場合はどうでしょうか？



この場合、IMDGソリューションには分散ロックの実装があります。

分散ロックは、クラスターのすべてのノードで使用可能なロックであり、これらのすべてのノードで同じ状態になります。 つまり 異なるノード上の2つのスレッドが同時に同じロックを持つ状況は不可能です。

分散ロックは、クラスター内のデータへのアクセスの同期を提供します。

おわりに

次の記事では、さまざまなIMDGとNoSQLソリューションを比較した結果についてお話しますが、ご存じのとおり、これには時間がかかるため、9月中旬までに記事を待たないでください。 私はすべての人に結果の議論に参加するよう勧めます:)