ベストプラクティス

Redis 圧縮戦略: 85% のデータ削減を実現した方法

Redisは、圧縮と機械学習を支援するために使用されるNoSQLKey-Valueデータ構造サーバーです。 Redisストレージのフットプリントを削減する方法を学びます。

Redis圧縮ベンチマークLogicMonitor

Redis(Remote Dictionary Server)は、によって開発された非常に高速なNoSQLキー値データ構造サーバーです。 Redisの RedisはANSI Cプログラミング言語で書かれています。Redisはメモリ内キャッシュを実行するため、データ構造ストアは従来のデータベースよりもはるかに機敏に保存および呼び出しできます。その速度に加えて、Redisの圧縮は、幅広い抽象化を簡単にサポートできます。 データ型、ほとんどすべての状況で非常に柔軟になります。 

LogicMonitorでは、エージェントレスアプリケーションで顧客のデバイスを定期的に監視し、大量のランタイムシリーズデータに焦点を当てています。最近、機械学習を統合して、ステートレスな異常検出機能を開発しました。 マイクロサービス データ ストリームを解釈し、意味のある分析を提供するプロセスです。このプロセスは不可欠ですが、効率的に保存およびアクセスする必要がある大量のデータを生成するため、Redis が役立ちます。

主要な取り組み

チェックマーク
Redisの圧縮は、大容量データ環境でのメモリ使用量の最適化とストレージフットプリントの削減に不可欠です。
チェックマーク
LZ4やBloscなどの手動圧縮戦略は、パフォーマンスを維持しながらRedisのストレージサイズを大幅に削減します。
チェックマーク
パフォーマンスの低下、データの破損、スケーリングの困難を回避するには、圧縮設定を慎重に管理することが重要です。
チェックマーク
Redisで圧縮されたデータを監視およびベンチマークすることで、システムの効率と応答性が大幅に向上します。

ネイティブRedisデータ圧縮機能

Redisは速度と柔軟性に優れていますが、保存するデータをネイティブに圧縮しません。デフォルトでは、Redisは生の形式(圧縮されていない)でデータを保存します。これは、迅速な取得と処理に非常に効率的ですが、特に時系列や大規模なデータセットなどの大量のデータを扱う場合は、メモリ使用量が増加する可能性があります。 JSONの 形式でダウンロードすることができます。

手動圧縮技術が必要な理由

Redis には組み込みの圧縮機能がないため、メモリ使用量を最適化し、ストレージ フットプリントを削減するには、手動の圧縮技術が不可欠です。これらの技術により、データを Redis に保存する前に圧縮できるため、消費されるメモリの量が大幅に削減され、データ ストレージの効率が向上します。これは、高いデータ スループットとストレージ効率が最も重要である当社のような環境では特に重要です。

この記事の後半で説明するような手動の圧縮戦略を適用することで、大規模なデータ ストレージに通常伴うメモリ消費を軽減しながら、Redis の速度を活用できます。

Redis には組み込みの圧縮機能がないため、大規模なデータを効率的に管理するには手動の戦略が不可欠です。

状態モデルの例

環境内の複数のポッドにわたってさまざまなアルゴリズムの機械学習トレーニングデータを永続化するために、JSON形式のモデルを維持しています。 このモデルは、高可用性のために一元化されたRedisクラスターにキャッシュされます。 以下は、このモデルの簡略化された例です。

{
  "resource-id-1 ": {
    "model-version" : string,
    "config-version": int,
    "last-timestamp": int,
    "algorithm-1-training-data": {
      "version" : string,
      "training-data-value": List[float],
      "training-data-timestamp": List[float],
      "Parameter-1" : float,
      "Parameter-2" : float
     },
    "algorithm-2-training-data": {
      "version" : string,
      "training-data-value": List[float],
      "training-data-timestamp": List[float],
      "Parameter-1" : float,
      "Parameter-2" : float
     },
     ......
   }
}

圧縮戦略

LZ4圧縮

デフォルトでは、Redisは保存する値を圧縮しません(続きを読む こちら)、したがって、サイズの縮小は、最初にアプリケーション側で実行する必要があります。 手動圧縮オプションのいずれかによって達成されたストレージとネットワークスループットの節約は、追加の処理時間の価値があることがわかりました。

最初は、利用することを選択しました LZ4 その速度と既存のコードベースとの統合の容易さのため。 可逆圧縮の導入により、ストレージ全体のサイズが約39,739バイトからはるかに管理しやすい16,208バイトに即座に削減されました(60%の節約)。 これらの節約のほとんどは、モデルのキー値の統計的冗長性に起因する可能性があります。

圧縮前のノイズの低減

プロジェクトが複雑になるにつれて、より長い浮動小数点値リストを追加する必要がありました。 このため、トレーニングデータモデルのサイズはXNUMX倍以上になり、統計的な冗長性を減らし、圧縮の節約を最小限に抑えた、一見ランダムな数値データで構成されていました。 これらのfloat値はそれぞれ、XNUMX進精度が大きく(Pythonの倍精度のデフォルトのため)、文字列としてRedisに設定すると、かなり多くのバイトに変換されました。 XNUMX番目の戦略は、XNUMXつの異なるオプションを使用して小数の精度を丸めることでした。 これについては、以下で詳しく説明します。

丸めオプション1(すべての値)

  • すべてのfloat値を小数点以下4桁の精度に丸めます。

丸めオプション2(5番目の変位値に基づく)

  • 値が0を超える場合は、浮動小数点数を小数点以下100桁に丸めます(例:54,012.43→54,012)
  • 値が1〜1の場合、浮動小数点数を小数点以下99桁に丸めます(例:12.43→12.4)。
  • 値が4未満の場合は、浮動小数点値を小数点以下1桁に丸めます(例:0.4312444→0.4312) 

オプション1の結果:  〜80,000バイトが〜36,000バイトに削減(55%節約)

オプション2の結果:  〜80,000バイトが〜35,000バイトに削減(56%節約)

オプション1が選択されたのは、複雑さが増したり、小数点以下の精度が低下したりすることなく、ほぼ同じレベルのメモリを節約できるためです。 また、アルゴリズムへの精度の影響を失うことは重要ではないことも確認しました。

エンコーディングによる圧縮– 85%の節約!

丸めによってRedisストレージが劇的に減少しましたが、消費量は依然として多く、アルゴリズムの計算の精度のマージンが失われました。  

リストに変換する前は、浮動小数点値の配列は次のように存在します。 Numpy N次元配列(ndarray)。 これらの各配列はfloat16値に縮小され、内部ZLibコーデックを使用してBloscでエンコードされました。 Bloscはマルチスレッドを使用し、データを分割して小さなブロックに圧縮できるため、従来の圧縮方法よりもはるかに高速です。

結果の圧縮配列は、Base64でエンコードされ、次のようにデコードされます。 8ビットUnicode変換形式(UTF-8) JSONにダンプされる前。 結果として得られたRedisストレージサイズは11,383バイト(約80,000バイトから)に縮小されました。これは、LZ4のみで圧縮するか、浮動小数点の小数点以下を丸めて圧縮することで達成されたものから劇的に改善されました。  

最終的に、エンコードによる圧縮は、異常検出プログラムの最後の反復に含まれる戦略でした。 85つの戦略を組み合わせると、メモリ消費量のXNUMX%が節約されました。

Redis での手動圧縮により、ストレージ要件を最大 85% 削減でき、パフォーマンスを犠牲にすることなくシステム効率を大幅に向上できます。

ベンチマーク中の監視

圧縮テスト中に、私たちはいくつかの すぐに使用できるRedisモジュール すべてのGetおよびSetトランザクションのパフォーマンスを監視します。 事前の圧縮がある場合とない場合の送信結果をRedisと比較すると、経過時間の大幅な改善が実証されました。

LogicMonitorで過去24時間のダッシュボードのRedisセット経過時間を表示します。

Redis 圧縮: 主な課題とベスト プラクティス

圧縮は Redis のストレージ フットプリントの削減に大きなメリットをもたらしますが、課題がないわけではありません。Redis に圧縮を実装すると、慎重に管理しないとパフォーマンスとデータの整合性に影響を与える可能性のある落とし穴が生じる可能性があります。以下では、これらの課題のいくつかを概説し、それらを軽減するための戦略を示します。

1. ピーク負荷時のパフォーマンス低下

圧縮は、その性質上、追加の CPU データのエンコードとデコードに多くのリソースが必要になります。特に、使用する圧縮アルゴリズムがリソースを大量に消費する場合は、ピーク負荷時にレイテンシが増加し、スループットが低下する可能性があります。

それを避ける方法:

  • 高スループットのユースケースを扱う場合は、LZ4 などの高速で軽量な圧縮アルゴリズムを選択してください。
  • 特定のデータ型またはアクセス頻度の低いデータのみを圧縮するハイブリッド アプローチを検討してください。
  • システム パフォーマンスを定期的に監視し、必要に応じて圧縮設定を調整して、圧縮効率とパフォーマンスの最適なバランスを維持します。

2. データ破損のリスク

圧縮されたデータは、特に複雑なエンコード方式を使用している場合、特に解凍も行われている場合は破損しやすくなります。圧縮されたブロック内の 1 ビットが変更されると、ブロック全体が読み取り不能になり、データが失われる可能性があります。

それを避ける方法:

  • データの整合性を確保するために、強力なエラーチェック メカニズムとバックアップを実装します。
  • 組み込みのエラー検出を含む圧縮アルゴリズムを使用します。
  • 圧縮されたデータを定期的にテストおよび検証して、エラーを早期に発見して修正します。

3. スケーリングの難しさ

Redis データベースが大きくなるにつれて、圧縮データの管理はますます複雑になる可能性があります。圧縮レイヤーを追加するには、データ取得時間の一貫性を保ち、システムの応答性を維持するために、慎重なスケーリング戦略が必要です。

それを避ける方法:

  • 成長を考慮して圧縮戦略を設計することで、スケーラビリティを計画します。
  • Redis のクラスタリング機能を活用して負荷を分散し、圧縮がボトルネックにならないようにします。
  • データ量やアクセス パターンの変化に合わせて、圧縮戦略を継続的に監視および最適化します。

LogicMonitorについて

LogicMonitorは、エンタープライズITおよびマネージドサービスプロバイダー向けの唯一の完全に自動化されたクラウドベースのインフラストラクチャ監視プラットフォームです。。 XNUMXつの統合されたビュー内で、ネットワーク、クラウド、サーバーなどのフルスタックの可視性を獲得します。

著者
LogicMonitorチーム
免責事項: このブログで述べられている見解は著者の見解であり、LogicMonitor またはその関連会社の見解を必ずしも反映するものではありません。

私たちのブログを購読する

このような記事をあなたの受信箱に直接お届けします