redisデータの2つの持続化方式の比較
3764 ワード
一.概念の紹介
redisは、RDB(Redis DataBase)とAOF(Apend Only File)の2つの永続化方式を提供する.
RDB方式
RDB方式は、ある時点のデータをディスクに永続化するスナップショット式の永続化方法である.
•redisは、データの永続化中に、最後に永続化されたファイルを置き換えるために、一時ファイルにデータを書き込みます.この機能により、スナップショット・ファイルは常に完全に使用可能であるため、いつでもバックアップできます.•RDB方式の場合、redisは単独で1つのサブプロセスを作成して永続化し、メインプロセスはIO操作を行わないため、redisの極めて高いパフォーマンスが確保されます.•大規模なデータのリカバリが必要であり、データリカバリの完全性に非常に敏感でない場合、RDB方式はAOF方式よりも効率的である.
AOF方式
AOF方式は,実行した書き込み命令を記録し,データ復元時に叢前から後の順にもう一度命令を実行する.
•AOFコマンドは、書き込みごとの操作をファイルの末尾までredisプロトコルで追加保存する.Redisはまた、AOFファイルをバックグラウンドで書き換えることができ、AOFファイルの体積が過大にならないようにすることができる.デフォルトのAOF永続化ポリシーは、1秒ごとにfsync(fsyncとは、キャッシュ内の書き込み命令をディスクに記録すること)です.この場合、redisは依然として処理性能を維持することができ、redisが故障しても、最近の1秒のデータしか失われません.•ログを追加するときに、ディスク容量がいっぱい、inodeがいっぱい、または電源が切れた場合にログの書き込みが不完全になり、関係なく、redisはログ修復に使用できるredis-check-aofツールを提供します.•追加方式を採用しているため、何の処理もしないとAOFファイルがますます大きくなるため、redisは、AOFファイルのサイズが設定した閾値を超えると、AOFファイルのコンテンツ圧縮を開始し、データを復元できる最小命令セットのみを保持するAOFファイル書き換え機構を提供している.例を挙げると、INCRコマンドを100回呼び出すと、AOFファイルに100個のコマンドが格納されますが、これは明らかに非効率で、この100個のコマンドをSETコマンドに統合することができます.これが書き換えメカニズムの原理です.•AOF書き換えを行う場合は、やはり一時ファイルを先に書き、すべて完了してから置き換えるプロセスを採用しているので、電源が切れたり、ディスクがいっぱいになったりする問題はAOFファイルの可用性に影響しません.
二.二つの方式の長所と短所
1.RDB方式
•メリット:
1.RDBは単一のコンパクトファイルで、ある時点のデータセットを保存し、データセットのバックアップに非常に適している.例えば、過去24時間以内のデータを1時間ごとに保存し、毎日過去30日間のデータを保存することができ、問題が発生しても必要に応じて異なるバージョンのデータセットに回復することができる.2.RDBはコンパクトな単一ファイルで、転送が便利で、災害復旧に適している.3.RDBはRDBファイルを保存する時に親プロセスが唯一しなければならないのはforkが1つのサブプロセスを出すことであり、次の仕事はすべて子プロセスによって行われ、親プロセスは他のIO操作をする必要がないので、RDB持続化方式はredisの性能を最大化することができる.4.AOFより大きいデータセットを回復する時、RDB方式はもっと速くなる.
•短所:
1.Redisは予期せぬダウンタイムで、構成されたsave時点に応じて数分間のデータが失われる可能性があります.RDB方式では、データセット全体を保存する必要があり、比較的煩雑な作業であり、通常は5分以上で完全な保存を行う必要があります.2.RDBはデータセットをハードディスクに保存するために常にforkサブプロセスを必要とし、データセットが比較的大きい場合、forkのプロセスは非常に時間がかかり、Redisがミリ秒レベルでクライアントの要求に応答できない可能性がある.データセットが巨大でCPUのパフォーマンスがあまりよくない場合、この状況はより長く続きます.
2.AOF方式
•メリット
1.AOFを使用するとRedisデータの耐久性が向上します.異なるfsyncポリシーを使用できます.fsyncなし、毎秒fsync、書くたびにfsyncを使用できます.デフォルトの毎秒fsyncポリシーを使用すると、Redisのパフォーマンスは依然として良好です(fsyncはバックグラウンドスレッドで処理され、メインスレッドはクライアント要求を処理するように努力します).障害が発生すると、最大1秒のデータが失われます.2.AOFファイルは追加のみを行うログファイルなのでseekに書き込む必要はありません.何らかの理由で(ディスク容量がいっぱいで、書き込み中にダウンタイムなど)完全な書き込みコマンドが実行されていない場合でも、redis-check-aofツールを使用してこれらの問題を修正することができます.3.Redisは、AOFファイルのボリュームが大きすぎると、自動的にバックグラウンドでAOFを書き換えることができる.書き換えられた新しいAOFファイルには、現在のデータセットを復元するために必要な最小コマンドセットが含まれている.Redisは新しいAOFファイルを作成する過程で、既存のAOFファイルにコマンドを追加し続けるため、書き換え中にダウンタイムが発生しても、既存のAOFファイルは失われません.新しいAOFファイルの作成が完了すると、Redisは古いAOFファイルから新しいAOFファイルに切り替え、新しいAOFファイルの追加操作を開始します.4.AOFファイルはデータベースに対して実行されたすべての書き込み操作を秩序正しく保存しており、これらの書き込み操作はRedisプロトコルの形式で保存されているため、AOFファイルの内容は非常に読みやすく、ファイルの分析も簡単である.AOFファイルをエクスポートするのも簡単です.たとえば、FLUSHALLコマンドをうっかり実行しても、AOFファイルが書き換えられていない限り、サーバを停止し、AOFファイルの最後のFLUSHALLコマンドを削除し、Redisを再起動すれば、データセットをFLUSHALL実行前の状態に戻すことができます.
•欠点
1.同じデータセットの場合、AOFファイルのボリュームは、通常、RDBファイルのボリュームよりも大きい.2.使用されるfsyncポリシーに従って、AOFの速度はRDBより遅くなる可能性がある.一般的に、毎秒fsyncの性能は依然として非常に高く、fsyncを閉じることで、高負荷でもAOFの速度をRDBと同じように速くすることができる.しかし、大きな書き込みロードを処理する場合、RDBは、より保証された最大遅延時間を提供することができる.
三.構成方法
1.RDB構成方式
デフォルトでは、スナップショットrdbの永続化方式であり、メモリ内のデータをスナップショットでバイナリファイルに書き込む、デフォルトのファイル名はdumpである.rdb redis.conf構成:
以上がデフォルトの構成です.900秒以内に、1つ以上のkeyが変更された場合、スナップショットの保存が開始されます.300秒以内に、10個以上のkeyが変更された場合、スナップショット保存が開始される.1分以内に1万個のkeyが変更された場合、スナップショット保存が開始されます.
この方式では、データの永続化を完全に保証することはできません.タイミング保存なので、redisサービスdownが落ちると、データの一部が失われ、データ量が多く、書き込み操作が多い場合、大量のディスクIO操作が発生し、性能に影響します.
したがって、この2つの方法が同時にオンになっている場合、データをリカバリする場合は、rdb永続化方式でデータベースをリカバリするべきではありません.
2.AOF配置方式
aofを使用して永続化し、各書き込みコマンドはwrite関数でappendonlyに追加する.aof中構成方法:aof永続化を開始する方法
参考資料:http://redis.io/topics/persistence
redisは、RDB(Redis DataBase)とAOF(Apend Only File)の2つの永続化方式を提供する.
RDB方式
RDB方式は、ある時点のデータをディスクに永続化するスナップショット式の永続化方法である.
•redisは、データの永続化中に、最後に永続化されたファイルを置き換えるために、一時ファイルにデータを書き込みます.この機能により、スナップショット・ファイルは常に完全に使用可能であるため、いつでもバックアップできます.•RDB方式の場合、redisは単独で1つのサブプロセスを作成して永続化し、メインプロセスはIO操作を行わないため、redisの極めて高いパフォーマンスが確保されます.•大規模なデータのリカバリが必要であり、データリカバリの完全性に非常に敏感でない場合、RDB方式はAOF方式よりも効率的である.
AOF方式
AOF方式は,実行した書き込み命令を記録し,データ復元時に叢前から後の順にもう一度命令を実行する.
•AOFコマンドは、書き込みごとの操作をファイルの末尾までredisプロトコルで追加保存する.Redisはまた、AOFファイルをバックグラウンドで書き換えることができ、AOFファイルの体積が過大にならないようにすることができる.デフォルトのAOF永続化ポリシーは、1秒ごとにfsync(fsyncとは、キャッシュ内の書き込み命令をディスクに記録すること)です.この場合、redisは依然として処理性能を維持することができ、redisが故障しても、最近の1秒のデータしか失われません.•ログを追加するときに、ディスク容量がいっぱい、inodeがいっぱい、または電源が切れた場合にログの書き込みが不完全になり、関係なく、redisはログ修復に使用できるredis-check-aofツールを提供します.•追加方式を採用しているため、何の処理もしないとAOFファイルがますます大きくなるため、redisは、AOFファイルのサイズが設定した閾値を超えると、AOFファイルのコンテンツ圧縮を開始し、データを復元できる最小命令セットのみを保持するAOFファイル書き換え機構を提供している.例を挙げると、INCRコマンドを100回呼び出すと、AOFファイルに100個のコマンドが格納されますが、これは明らかに非効率で、この100個のコマンドをSETコマンドに統合することができます.これが書き換えメカニズムの原理です.•AOF書き換えを行う場合は、やはり一時ファイルを先に書き、すべて完了してから置き換えるプロセスを採用しているので、電源が切れたり、ディスクがいっぱいになったりする問題はAOFファイルの可用性に影響しません.
二.二つの方式の長所と短所
1.RDB方式
•メリット:
1.RDBは単一のコンパクトファイルで、ある時点のデータセットを保存し、データセットのバックアップに非常に適している.例えば、過去24時間以内のデータを1時間ごとに保存し、毎日過去30日間のデータを保存することができ、問題が発生しても必要に応じて異なるバージョンのデータセットに回復することができる.2.RDBはコンパクトな単一ファイルで、転送が便利で、災害復旧に適している.3.RDBはRDBファイルを保存する時に親プロセスが唯一しなければならないのはforkが1つのサブプロセスを出すことであり、次の仕事はすべて子プロセスによって行われ、親プロセスは他のIO操作をする必要がないので、RDB持続化方式はredisの性能を最大化することができる.4.AOFより大きいデータセットを回復する時、RDB方式はもっと速くなる.
•短所:
1.Redisは予期せぬダウンタイムで、構成されたsave時点に応じて数分間のデータが失われる可能性があります.RDB方式では、データセット全体を保存する必要があり、比較的煩雑な作業であり、通常は5分以上で完全な保存を行う必要があります.2.RDBはデータセットをハードディスクに保存するために常にforkサブプロセスを必要とし、データセットが比較的大きい場合、forkのプロセスは非常に時間がかかり、Redisがミリ秒レベルでクライアントの要求に応答できない可能性がある.データセットが巨大でCPUのパフォーマンスがあまりよくない場合、この状況はより長く続きます.
2.AOF方式
•メリット
1.AOFを使用するとRedisデータの耐久性が向上します.異なるfsyncポリシーを使用できます.fsyncなし、毎秒fsync、書くたびにfsyncを使用できます.デフォルトの毎秒fsyncポリシーを使用すると、Redisのパフォーマンスは依然として良好です(fsyncはバックグラウンドスレッドで処理され、メインスレッドはクライアント要求を処理するように努力します).障害が発生すると、最大1秒のデータが失われます.2.AOFファイルは追加のみを行うログファイルなのでseekに書き込む必要はありません.何らかの理由で(ディスク容量がいっぱいで、書き込み中にダウンタイムなど)完全な書き込みコマンドが実行されていない場合でも、redis-check-aofツールを使用してこれらの問題を修正することができます.3.Redisは、AOFファイルのボリュームが大きすぎると、自動的にバックグラウンドでAOFを書き換えることができる.書き換えられた新しいAOFファイルには、現在のデータセットを復元するために必要な最小コマンドセットが含まれている.Redisは新しいAOFファイルを作成する過程で、既存のAOFファイルにコマンドを追加し続けるため、書き換え中にダウンタイムが発生しても、既存のAOFファイルは失われません.新しいAOFファイルの作成が完了すると、Redisは古いAOFファイルから新しいAOFファイルに切り替え、新しいAOFファイルの追加操作を開始します.4.AOFファイルはデータベースに対して実行されたすべての書き込み操作を秩序正しく保存しており、これらの書き込み操作はRedisプロトコルの形式で保存されているため、AOFファイルの内容は非常に読みやすく、ファイルの分析も簡単である.AOFファイルをエクスポートするのも簡単です.たとえば、FLUSHALLコマンドをうっかり実行しても、AOFファイルが書き換えられていない限り、サーバを停止し、AOFファイルの最後のFLUSHALLコマンドを削除し、Redisを再起動すれば、データセットをFLUSHALL実行前の状態に戻すことができます.
•欠点
1.同じデータセットの場合、AOFファイルのボリュームは、通常、RDBファイルのボリュームよりも大きい.2.使用されるfsyncポリシーに従って、AOFの速度はRDBより遅くなる可能性がある.一般的に、毎秒fsyncの性能は依然として非常に高く、fsyncを閉じることで、高負荷でもAOFの速度をRDBと同じように速くすることができる.しかし、大きな書き込みロードを処理する場合、RDBは、より保証された最大遅延時間を提供することができる.
三.構成方法
1.RDB構成方式
デフォルトでは、スナップショットrdbの永続化方式であり、メモリ内のデータをスナップショットでバイナリファイルに書き込む、デフォルトのファイル名はdumpである.rdb redis.conf構成:
save 900 1
save 300 10
save 60 10000
以上がデフォルトの構成です.900秒以内に、1つ以上のkeyが変更された場合、スナップショットの保存が開始されます.300秒以内に、10個以上のkeyが変更された場合、スナップショット保存が開始される.1分以内に1万個のkeyが変更された場合、スナップショット保存が開始されます.
この方式では、データの永続化を完全に保証することはできません.タイミング保存なので、redisサービスdownが落ちると、データの一部が失われ、データ量が多く、書き込み操作が多い場合、大量のディスクIO操作が発生し、性能に影響します.
したがって、この2つの方法が同時にオンになっている場合、データをリカバリする場合は、rdb永続化方式でデータベースをリカバリするべきではありません.
2.AOF配置方式
aofを使用して永続化し、各書き込みコマンドはwrite関数でappendonlyに追加する.aof中構成方法:aof永続化を開始する方法
appendonly yes 参考資料:http://redis.io/topics/persistence