Apache Ignite でのデータ圧縮。 スベルさんの経験

大量のデータを扱う場合、ディスク容量不足の問題が発生することがあります。 この問題を解決する XNUMX つの方法は圧縮です。これにより、同じ機器上でストレージ ボリュームを増やす余裕が得られます。 この記事では、Apache Ignite でデータ圧縮がどのように機能するかを見ていきます。 この記事では、製品内で実装されているディスク圧縮方法のみについて説明します。 他のデータ圧縮方法 (ネットワーク上、メモリ内) は、実装されているかどうかにかかわらず、対象外となります。

したがって、永続モードが有効になっていると、キャッシュ内のデータが変更された結果、Ignite はディスクへの書き込みを開始します。

1. キャッシュの内容
2. 先行書き込みログ（以下、単に WAL）

WAL 圧縮には、WAL 圧縮と呼ばれるメカニズムがかなり前から存在しています。 最近リリースされた Apache Ignite 2.8 では、ディスク上のデータを圧縮できる XNUMX つのメカニズムがさらに導入されました。キャッシュの内容を圧縮するディスク ページ圧縮と、一部の WAL エントリを圧縮する WAL ページ スナップショット圧縮です。 これら XNUMX つのメカニズムすべてについては、以下で詳しく説明します。

ディスクページ圧縮

これはどう動かすのですか

まず、Ignite がデータを保存する方法を簡単に見てみましょう。 ページ メモリはストレージに使用されます。 ページ サイズはノードの開始時に設定され、後の段階では変更できません。また、ページ サイズは XNUMX の累乗で、ファイル システムのブロック サイズの倍数である必要があります。 ページは必要に応じてディスクから RAM にロードされるため、ディスク上のデータのサイズが割り当てられた RAM の量を超える場合があります。 ディスクからページをロードするのに十分なスペースが RAM にない場合、古くて使用されなくなったページが RAM から削除されます。

データは次の形式でディスクに格納されます: 各キャッシュ・グループのパーティションごとに別個のファイルが作成され、このファイル内にページがインデックスの昇順で次々に表示されます。 フルページ識別子には、ファイル内のキャッシュグループ識別子、パーティション番号、およびページインデックスが含まれます。 したがって、完全なページ識別子を使用すると、ファイルと各ページのファイル内のオフセットを一意に決定できます。 ページング メモリの詳細については、Apache Ignite Wiki の記事を参照してください。 永続ストアに点火する - 内部的に.

名前から推測できるように、ディスク ページ圧縮メカニズムはページ レベルで機能します。 このメカニズムを有効にすると、RAM 内のデータは圧縮されずにそのまま処理されますが、ページが RAM からディスクに保存されるときに圧縮されます。

ただし、各ページを個別に圧縮することは問題の解決策ではないため、結果として得られるデータ ファイルのサイズを何らかの方法で削減する必要があります。 ページ サイズが固定されなくなった場合、ファイルにページを次々に書き込むことができなくなります。これは、次のようなさまざまな問題が発生する可能性があるためです。

• ページ インデックスを使用すると、ファイル内でのページ インデックスのオフセットを計算できません。
• ファイルの末尾になく、サイズが変更されたページをどうするかは明確ではありません。 ページ サイズが減少すると、解放されたスペースがなくなります。 ページ サイズが増加した場合は、ファイル内の新しい場所を探す必要があります。
• ファイル システムのブロック サイズの倍数ではないバイト数でページが移動する場合、ページの読み取りまたは書き込みにはファイル システム ブロックをもう XNUMX つ操作する必要があり、パフォーマンスの低下につながる可能性があります。

これらの問題を独自のレベルで解決しないようにするために、Apache Ignite のディスク ページ圧縮では、スパース ファイルと呼ばれるファイル システム メカニズムが使用されます。 スパース ファイルとは、ゼロで埋められた一部の領域を「ホール」としてマークできるファイルです。 この場合、これらのホールを保存するためにファイル システム ブロックが割り当てられないため、ディスク領域が節約されます。

ファイル システム ブロックを解放するには、ホールのサイズがファイル システム ブロック以上である必要があるのは論理的です。これにより、ページ サイズと Apache Ignite に追加の制限が課せられます。圧縮が効果を発揮するには、ページ サイズはファイル システム ブロックのサイズより厳密に大きくなければなりません。 ページ サイズがブロック サイズと等しい場合、単一のブロックを解放することはできません。単一のブロックを解放するには、圧縮されたページが 0 バイトを占有する必要があるためです。 ページ サイズが 2 ブロックまたは 4 ブロックのサイズに等しい場合、ページがそれぞれ少なくとも 50% または 75% に圧縮されていれば、すでに少なくとも XNUMX つのブロックを解放できます。

したがって、メカニズムがどのように機能するかについての最後の説明は次のとおりです。 ページをディスクに書き込むときに、ページの圧縮が試行されます。 圧縮ページのサイズによって XNUMX つ以上のファイル システム ブロックを解放できる場合、ページは圧縮形式で書き込まれ、解放されたブロックの代わりに「ホール」が作成されます (システム コールが実行されます)。 fallocate() パンチホールフラグ付き)。 圧縮されたページのサイズによってブロックを解放できない場合、ページは圧縮されずにそのまま保存されます。 すべてのページ オフセットは、圧縮なしの場合と同じ方法で、ページ インデックスとページ サイズを乗算して計算されます。 自分でページを移動する必要はありません。 ページ オフセットは、圧縮を行わない場合と同様に、ファイル システム ブロックの境界上にあります。

現在の実装では、Ignite は Linux OS でスパース ファイルのみを処理できるため、ディスク ページ圧縮は、このオペレーティング システムで Ignite を使用する場合にのみ有効にできます。

ディスク ページの圧縮に使用できる圧縮アルゴリズム: ZSTD、LZ4、Snappy。 さらに、残りのデータを圧縮せずにページ内の未使用領域のみを廃棄する動作モード (SKIP_GARBAGE) があり、これにより、前述のアルゴリズムと比較して CPU の負荷が軽減されます。

パフォーマンスへの影響

残念ながら、このメカニズムを本番環境で使用する予定がないため、実際のスタンドでの実際のパフォーマンスの測定は行っていませんが、どこで負けてどこで勝つかを理論的に推測することはできます。

これを行うには、アクセス時にページがどのように読み書きされるかを覚えておく必要があります。

• 読み取り操作を実行する場合、まず RAM 内でページが検索され、検索が失敗した場合、読み取りを実行したのと同じスレッドによってページがディスクから RAM にロードされます。
• 書き込み操作が実行されると、RAM 内のページはダーティとしてマークされますが、そのページは書き込みを実行するスレッドによって物理的にすぐにディスクに保存されません。 すべてのダーティ ページは、後のチェックポイント プロセスで別のスレッドでディスクに保存されます。

したがって、読み取り操作への影響は次のようになります。

• 読み取りファイル システム ブロック数の減少により、プラス (ディスク IO)。
• マイナス (CPU)、オペレーティング システムがスパース ファイルを処理するために必要な追加の負荷のため。 より複雑なスパース ファイル構造を保存するために、ここで追加の IO 操作が暗黙的に表示される可能性もあります (残念ながら、スパース ファイルがどのように機能するかについては、私は詳しく知りません)。
• ページを解凍する必要があるため、ネガティブ (CPU)。
• 書き込み操作には影響しません。
• チェックポイント プロセスへの影響 (ここでのすべては読み取り操作と同様です):
• 書き込まれたファイル システム ブロックの数が減少したため、プラス (ディスク IO)。
• スパース ファイルを操作するため、マイナス (CPU、おそらくディスク IO)。
• ページ圧縮が必要なため、マイナス (CPU)。

天秤のどちら側に傾くでしょうか？ これはすべて環境に大きく依存しますが、ディスク ページの圧縮はほとんどのシステムでパフォーマンスの低下につながる可能性が高いと私は考えています。 さらに、スパース ファイルに対して同様のアプローチを使用する他の DBMS でのテストでは、圧縮を有効にするとパフォーマンスが低下することが示されています。

有効化および設定する方法

前述したように、ディスク ページ圧縮をサポートする Apache Ignite の最小バージョンは 2.8 であり、Linux オペレーティング システムのみがサポートされています。 次のように有効にして設定します。

• クラスパスに ignite-compression モジュールが存在する必要があります。 デフォルトでは、Apache Ignite ディストリビューションの libs/optional ディレクトリにあり、クラスパスには含まれません。 ディレクトリを XNUMX つ上のレベルの libs に移動するだけで、ignite.sh を通じて実行すると自動的に有効になります。
• 永続性を有効にする必要があります (有効にする DataRegionConfiguration.setPersistenceEnabled(true)).
• ページ サイズは、ファイル システムのブロック サイズより大きくなければなりません (次を使用して設定できます) DataStorageConfiguration.setPageSize() ).
• データを圧縮する必要があるキャッシュごとに、圧縮方法と (オプションで) 圧縮レベル (メソッド) を構成する必要があります。 CacheConfiguration.setDiskPageCompression() , CacheConfiguration.setDiskPageCompressionLevel()).

WALの圧縮

これはどう動かすのですか

WAL とは何ですか? なぜ必要ですか? 非常に簡単に説明すると、これは、ページ ストレージを最終的に変更するすべてのイベントを含むログです。 これは主に、転倒した場合に回復できるようにするために必要です。 すべての操作は、ユーザーに制御を与える前に、まず WAL にイベントを記録する必要があります。これにより、失敗した場合にログで再生し、ユーザーが成功した応答を受け取ったすべての操作を復元できます。ディスク上のページ ストレージに反映する時間がありませんでした (ページ ストアへの実際の書き込みは、別のスレッドによる多少の遅延を伴う「チェックポイント」と呼ばれるプロセスで行われることはすでに説明しました)。

WAL のエントリは、論理エントリと物理エントリに分けられます。 ブール値はキーと値そのものです。 物理 - ページ ストア内のページへの変更を反映します。 論理レコードは他の場合にも役立ちますが、物理レコードはクラッシュ時の回復にのみ必要であり、レコードは最後に成功したチェックポイント以降にのみ必要です。 ここでは、なぜこのように機能するのかについては詳しく説明しませんが、興味がある方は、Apache Ignite Wiki で既に言及されている記事を参照してください。 永続ストアに点火する - 内部的に.

多くの場合、論理レコードごとに複数の物理レコードが存在します。 つまり、たとえば、キャッシュへの 90 つの put 操作は、ページ メモリ内の複数のページ (データ自体を含むページ、インデックスを含むページ、フリー リストを含むページ) に影響します。 いくつかの合成テストでは、物理レコードが WAL ファイルの最大 3% を占めていることがわかりました。 ただし、これらが必要となるのは非常に短い時間です (デフォルトでは、チェックポイント間の間隔は XNUMX 分です)。 関連性を失った後、このデータを削除するのが論理的です。 これはまさに WAL 圧縮メカニズムの機能です。物理レコードを削除し、残りの論理レコードを zip を使用して圧縮し、ファイル サイズを大幅に (場合によっては数十分の XNUMX) 削減します。

物理的に、WAL は固定サイズ (デフォルトでは 10MB) のいくつかのセグメント (デフォルトでは 64) で構成されており、これらのセグメントは循環的に上書きされます。 現在のセグメントがいっぱいになるとすぐに、次のセグメントが現在のセグメントとして割り当てられ、いっぱいになったセグメントは別のスレッドによってアーカイブにコピーされます。 WAL 圧縮はすでにアーカイブ セグメントで機能します。 また、別個のスレッドとして、チェックポイントの実行を監視し、物理レコードが不要になったアーカイブ セグメントの圧縮を開始します。

パフォーマンスへの影響

WAL 圧縮は別のスレッドとして実行されるため、実行される操作に直接的な影響はありません。 ただし、それでも CPU (圧縮) とディスク (アーカイブから各 WAL セグメントを読み取り、圧縮セグメントを書き込む) に追加のバックグラウンド負荷がかかるため、システムが最大容量で実行されている場合、パフォーマンスの低下にもつながります。

有効化および設定する方法

プロパティを使用して WAL 圧縮を有効にできます。 WalCompactionEnabled в DataStorageConfiguration (DataStorageConfiguration.setWalCompactionEnabled(true)）。 また、デフォルト値 (BEST_SPEED) に満足できない場合は、DataStorageConfiguration.setWalCompactionLevel() メソッドを使用して圧縮レベルを設定できます。

WAL ページのスナップショット圧縮

これはどう動かすのですか

WAL ではレコードが論理レコードと物理レコードに分かれていることがすでにわかりました。 各ページに変更が加えられるたびに、物理 WAL レコードがページ メモリ内に生成されます。 物理レコードも、ページ スナップショット レコードとデルタ レコードの 2 つのサブタイプに分類されます。 ページ上の何かを変更し、クリーンな状態からダーティな状態に移行するたびに、このページの完全なコピーが WAL (ページ スナップショット レコード) に保存されます。 WAL で 90 バイトだけ変更した場合でも、レコードはページ サイズよりわずかに大きくなります。 すでにダーティなページで何かを変更すると、WAL 内にデルタ レコードが形成されます。これは、ページ全体ではなく、ページの前の状態と比較した変更のみを反映します。 ページの状態をダーティからクリーンにリセットすることはチェックポイント プロセス中に実行されるため、チェックポイントの開始直後、ほとんどすべての物理レコードはページのスナップショットのみで構成されます (チェックポイントの開始直後はすべてのページがクリーンであるため)。その後、次のチェックポイントに近づくと、デルタ レコードの部分が増加し始め、次のチェックポイントの開始時に再びリセットされます。 いくつかの合成テストの測定では、物理レコードの総量に占めるページ スナップショットの割合が XNUMX% に達することが示されました。

WAL ページ スナップショット圧縮の考え方は、既製のページ圧縮ツールを使用してページ スナップショットを圧縮することです (ディスク ページ圧縮を参照)。 同時に、WAL では、レコードは追加専用モードで順次保存され、ファイル システム ブロックの境界にレコードをバインドする必要がないため、ここではディスク ページ圧縮メカニズムとは異なり、スパース ファイルは必要ありません。したがって、このメカニズムは OS Linux だけで動作するわけではありません。 さらに、ページをどれだけ圧縮できたかはもはや重要ではありません。 1 バイトを解放したとしても、これはすでに肯定的な結果であり、ディスク ページ圧縮とは異なり、圧縮データを WAL に保存できます。ディスク ページ圧縮では、複数のファイル システム ブロックを解放した場合にのみ圧縮ページが保存されます。

ページは圧縮率の高いデータであり、WAL の総ボリュームに占める割合が非常に高いため、WAL ファイル形式を変更せずにサイズを大幅に削減できます。 論理レコードを含む圧縮には、たとえば、論理レコードに関心がある可能性のある外部消費者にとって、形式の変更と互換性の喪失が必要になりますが、ファイル サイズの大幅な削減にはつながりません。

ディスク ページ圧縮と同様、WAL ページ スナップショット圧縮では、ZSTD、LZ4、Snappy 圧縮アルゴリズムに加え、SKIP_GARBAGE モードを使用できます。

パフォーマンスへの影響

WAL ページ スナップショット圧縮を直接有効にすると、データをページ メモリに書き込むスレッド、つまりキャッシュ内のデータを変更するスレッドにのみ影響することに気づくのは難しくありません。 WAL からの物理レコードの読み取りは、ノードが落下後に立ち上がった瞬間に XNUMX 回だけ行われます (チェックポイント中に落下した場合のみ)。

これは、データを変更するスレッドに次のような影響を与えます。ディスクに書き込む前に毎回ページを圧縮する必要があるためマイナスの効果 (CPU) が得られ、データ量の減少によりプラスの効果 (ディスク IO) が得られます。データが書き込まれました。 したがって、ここではすべてが単純です。システム パフォーマンスが CPU によって制限されている場合はわずかに低下しますが、ディスク I/O によって制限されている場合は増加します。

間接的に、WAL サイズの縮小は、WAL セグメントをアーカイブおよび WAL 圧縮ストリームにダンプするストリームにも (プラスの) 影響を与えます。

合成データを使用した環境での実際のパフォーマンス テストでは、わずかな増加が示されました (スループットは 10% ～ 15% 増加し、レイテンシは 10% ～ 15% 減少しました)。

有効化および設定する方法

Apache Ignite の最小バージョン: 2.8。 次のように有効にして設定します。

• クラスパスに ignite-compression モジュールが存在する必要があります。 デフォルトでは、Apache Ignite ディストリビューションの libs/optional ディレクトリにあり、クラスパスには含まれません。 ディレクトリを XNUMX つ上のレベルの libs に移動するだけで、ignite.sh を通じて実行すると自動的に有効になります。
• 永続性を有効にする必要があります (有効にする DataRegionConfiguration.setPersistenceEnabled(true)).
• 圧縮モードは次のメソッドを使用して設定する必要があります。 DataStorageConfiguration.setWalPageCompression()、圧縮はデフォルトで無効になっています (DISABLED モード)。
• オプションで、次のメソッドを使用して圧縮レベルを設定できます。 DataStorageConfiguration.setWalPageCompression()、各モードの有効な値については、メソッドの Javadoc を参照してください。

まとめ

Apache Ignite で検討されているデータ圧縮メカニズムは、それぞれ独立して使用できますが、それらを任意に組み合わせて使用​​することもできます。 これらがどのように機能するかを理解することで、それらが環境内のタスクにどれだけ適しているか、またそれらを使用する際に何を犠牲にする必要があるかを判断できるようになります。 ディスク ページ圧縮はメイン ストレージを圧縮するように設計されており、中程度の圧縮率が得られます。 WAL ページ スナップショット圧縮は、WAL ファイルに平均的な圧縮率をもたらし、パフォーマンスも向上する可能性があります。 WAL 圧縮はパフォーマンスに良い影響を与えませんが、物理レコードを削除することで WAL ファイルのサイズを可能な限り削減します。

出所： habr.com