Apache®Ignite™+永続データストア-インメモリがディスクを貫通します。 パートI-耐久性のあるメモリ

バージョン2.1以降、 Apache IgniteにはPersistenceの独自の実装があります。



最新の設計でこのメカニズムを構築するためには、SQLサポートを備えた分散フェールセーフトランザクションストレージの構築に主に費やされた数十人分の工数がかかりました。



すべては、以前のメカニズムの基本的な問題から始まりました。これにより、In-Memory Data Gridを外部の永続ストレージ（CassandraやPostgresなど）と統合できました。



このアプローチは特定の制限を課しました-たとえば、メモリにないデータの上でSQLまたは分散コンピューティングを実行することは不可能でしたが、そのような外部ストレージでは、大幅な追加の複雑化なしにコールドで低RTO（回復時間目標）を開始することはできませんでした。



Apache Ignite Persistenceを使用する場合は、Apache Igniteの通常の機能（ ACID 、分散トランザクション、分散SQL99 、Java / .NET APIまたはJDBC / ODBCインターフェースを介したアクセス、分散コンピューティングなど）をすべて使用します。 しかし、今では、使用するものがメモリ上と、1つのノードから数千ノードまでのインストールのメモリを拡張するディスク上で動作します。



Apache Ignite Persistenceがどのように構築されているかを見てみましょう。 今日は、その基礎-耐久性のあるメモリ、および次の出版物-ディスクコンポーネント自体について検討します。

耐久性のあるメモリ

製品サポートのコストを大幅に増大させる大量のコードを複製することなく、メモリとディスク上に効果的な混合ストレージを構築するには、メモリにデータを格納するアーキテクチャを大幅に再設計する必要がありました。



永続性のような新しいアーキテクチャ- 耐久性メモリ -は、昨年末から大規模なGridGainクライアントで実行されており、Apache Ignite 2.0から公開されました。 ページ形式のオフヒープデータストレージを提供します。

ページ/メモリ

基本的なストレージユニットは、実際のデータまたはメタデータを含む「ページ」です。



割り当てられたメモリが使い果たされると、データがディスクにプッシュされると、これはページごとに発生します。 したがって、ページサイズが大きすぎてはなりません。さもないと、押し出し効率が低下します。大きなページでは、ホットデータがホットデータと混合され、ページが常にメモリにプルアップされる可能性が高いためです。



しかし、ページが小さくなると、1ページに収まらない大量のレコードを保存する問題や、メモリの断片化と割り当ての問題があります（1〜2レコードを含む小さなページごとにオペレーティングシステムからメモリを要求するには高すぎます）。



最初の問題-大規模な録音の場合-は、そのようなレコードをいくつかのページに「スミア」する機能によって解決されます。各ページにはいくつかのセグメントのみが保存されます。 このアプローチの逆は、完全な情報を取得するために複数のページをクロールする必要があるため、そのようなレコードを操作するときのパフォーマンスが低下することです。 したがって、これが頻繁に発生する場合は、 MemoryConfiguration.setPageSize(…)



使用してデフォルトのページサイズ（最初は2 KiB、1〜16 KiBの範囲で変更可能）を増やすことを検討するのは理にかなっています。



ほとんどの場合、ページサイズがSSDのページサイズと異なる場合（ほとんどの場合4 KiB）にも、ページサイズを再定義することは理にかなっています。 そうしないと、パフォーマンスの低下が見られる場合があります。



フラグメンテーションに関する2番目の問題は、プラットフォームに組み込まれたオンラインデフラグによって部分的に解決され、データページには小さな「耐火性の残留物」のみが残ります。



3番目の問題-多数のページを含むページにメモリを割り当てるコストが高い-は、次のレベルの抽象化「セグメント」によって解決されます。

メモリセグメント

セグメントは、割り当てられたメモリのアトミック単位である連続したメモリブロックです。 割り当てられたメモリが終了し、使用の制限にまだ達していない場合、OSは追加のセグメントを要求し、それはさらに内部のページに分割されます。



現在の実装では、少なくとも256 MiBのセグメントボリュームを持つ1つの領域に最大16個のメモリセグメントを割り当てることが計画されています。 セグメントの実際のボリュームは、最大許容メモリと最初に割り当てられたメモリの差を15で割ったものとして定義されます（16番目のセグメントは最初に割り当てられたメモリです）。 たとえば、上限がノードあたり512 GiBで、16 GiBが最初に割り当てられる場合、割り当てられたセグメントのサイズは（512-16）/ 15≈33 GiBになります。



セグメントについて話すときは、メモリ消費の制限について言及するしかありません。 それらの実装をより詳細に検討してみましょう。



データによってストレージ要件が異なる場合があるため、関連するすべてのパラメーター（最大ボリュームと初期ボリューム、変位など）のグローバル設定を行うことは最適ではありません。 1つの例は、オンラインおよびアーカイブデータストレージです。 昨年の注文は、ホットデータがある可能性があるため、ほとんどの部分がメモリ内にあるオンラインストレージに保存したい場合がありますが、同時に、一時的であっても、古い注文履歴と過去の内部トランザクションを保存したい場合があります貴重な思い出。



各キャッシュのレベルを制限することは可能ですが、数百または数千のテーブルが多数ある場合、それぞれいくつかのメモリパンを割り当てるか、オーバーブッキングを実行して、すぐにメモリ不足エラーを取得する必要があります。



テーブルのグループの制限を定義できる混合アプローチが選択され、次のレベルの抽象化が可能になりました。

メモリの領域/領域

Durable Memoryストレージアーキテクチャの最上位レベルは、論理エンティティ「メモリ領域」です。これは、設定や制限などで単一のストレージ領域を共有するテーブルをグループ化します。



たとえば、信頼性のための重要なデータを備えた商品のキャッシュと、アクティブではあるが損失に対してそれほど重要ではない多くの派生的な集約キャッシュを持つアプリケーションのキャッシュがある場合、2つのメモリ領域を定義できます：1つ目は、384 GiBの消費制限と厳格な一貫性の保証、商品のキャッシュのバインド、および64 GiBの制限と弱められた保証の2番目のキャッシュに、これらの64 GiBのメモリを共有するすべての一時キャッシュをバインドします。



メモリ領域は制限を課し、ストレージ設定を決定し、ストレージに割り当てられたグループスペースに関してキャッシュをグループ化します。

ページの種類とデータの取得

メモリページはいくつかのタイプに分けられ、そのキーはデータページとインデックス ページです。



データページはデータを直接保存します;それらはすでに上で広く議論されています。 レコードが1ページに収まらない場合、複数のレコードに分散されますが、これは無料の操作ではありません。 また、アプリケーションシナリオに大きなレコードが多数ある場合は、 MemoryConfiguration.setPageSize(…)



をMemoryConfiguration.setPageSize(…)



てページサイズを増やすことは理にかなっています。 データはページごとにディスクにプッシュされます。ページは完全にRAMにあるか、完全にディスクにあります。



インデックスページはB +ツリーとして保存され、各ツリーは複数のページに分散できます。 インデックスページは、データを検索するときに最大のオンラインアクセスのために常にメモリ内にあります。







このようなスキームでは、キーごとにデータを取得するために、次のプロセスを実行します。

1. cache.get(keyA);
   
   
   
   メソッドがクライアントで呼び出されますcache.get(keyA);
   
   
   
   
2. クライアントは、組み込みのアフィニティ機能を使用してこのキーを担当するサーバーノードを決定し、ネットワーク経由でこのサーバーノードに要求を委任します。
3. サーバーノードは、リクエストが行われたキーによってキャッシュを担当するメモリ領域を決定します;
4. 対応する領域では、このキャッシュの主キーを使用してB +ツリーへのエントリポイントを含むメタ情報ページにアクセスしています。
5. 特定のキーの目的のインデックスページを検索します。
6. インデックスページは実際にキーを検索し、キーを含むデータページと、このページのオフセットを決定します。
7. データページにアクセスしており、キーから値が読み取られます。

SQL

H2を使用するSQLクエリは、2段階の実行計画（一般的な場合）を生成します。これは、基本的にMapReduceのようなアプローチに要約されます。 計画の最初の段階は、テーブルを担当するすべてのノードに「流出」します。ここで、テーブルを担当するメモリ領域の決定も同様に実行されます。 さらに、選択がインデックスによるものである場合、目的のインデックスページが検索され、選択された値の場所が決定され、それらに対して反復が実行されます。 フルスキャンの場合、プライマリインデックスで完全な反復が行われ、それに応じてすべてのページにアクセスします。

混雑

バージョン2.0以降、押し出しはページごとに機能し、メモリからページが削除されます。 永続性が設定されている場合、ページのコピーとインデックスのエントリは変更されずに残り、後でローカルディスクから必要な情報を取得できるようになります。 永続性が明示的にオフになっている場合、または構成されていない場合、クラウドアウトはクラスターから対応するデータを完全に削除します。



ページネーションは、キーと値のペアを簡単に操作することを不可能にしますが、永続性がはるかに優れており、十分なページサイズで良好な結果が得られます。



バージョン2.1 では、3つの押し出しモードがサポートされています。

• 無効-混雑は発生せず、十分なメモリがない場合はエラーがスローされます。
• ランダムlru-ループでの押し出し中に、ランダムな5ページのデータが選択された後、1つが削除されます（アクセスタイムスタンプが最も長い（アクセスが最も長い））。 5つのランダムページを選択するアプローチが選択されたのは、アクセスタイムマークの完全な順序付けの高性能実装の複雑さのためです。
• random 2 lru-前のバージョンに似ていますが、各ページには2つのアクセスタイムスタンプ（最後と最後から2つ）があり、それらの最小のものが選択に使用されます。 このアプローチにより、たとえば、データ配列の大部分に対するまれなフルスキャンまたはまれなクエリなどの状況をより効果的に処理できます。

* * *

次の出版物では、Durable Memoryがディスクストレージの実装（ WAL +チェックポイント）にどのように依存しているかを詳しく調べ、独自のGridGain拡張機能を提供するスナップショットを作成する可能性についても詳しく説明します。