-
Notifications
You must be signed in to change notification settings - Fork 14
Journal Memory Buffer
ストレージに対する更新系操作(e.g., PUTやDELETE)が発行される度に、対応するレコードがジャーナル領域に追記されていく。
追記されたレコード群はディスクに永続化されることになるが、ジャーナルメモリバッファが有効になっている場合には、一時的にメモリ上のバッファにのみ保持される状態となり、以降で説明する条件を満たしたタイミングで、まとめてディスクに書き出されるようになる。
ジャーナルメモリバッファが有効になっていると、プロセスクラッシュ時にレコード損失の可能性が出てくるが、更新系操作の性能は大きく向上することになる(参考: Consistency Model、Benchmark)。
細かいケースを除外すれば、通常は以下のいずれかを満たした場合に、メモリバッファ内のレコード群がディスクに永続化されることになる:
- ストレージが暇な状態となった:
- 一定期間、新規の操作要求を受け付けなかった場合には、そのストレージは暇な状態と判断され、バックグラウンドタスクが実行される
- その際に、ジャーナルメモリバッファが空ではない場合には、その内容のディスクへのフラッシュが行われる
- バッファ内のレコード数が規定数に達した:
- あらかじめ指定された数に達した場合には、そのバッファの内容がディスクにフラッシュされる
- 具体的にはjournal_sync_intervalオプションで、その上限数を指定する(デフォルト値は
4096
)- 「ジャーナルメモリバッファを無効にする」とは、操作的にはこのオプションの値に
0
を指定することを意味する
- 「ジャーナルメモリバッファを無効にする」とは、操作的にはこのオプションの値に
-
journal_syncオプションを指定して、操作要求を発行する:
- このオプションが指定されると、該当操作実行後のジャーナルメモリバッファのフラッシュが強制されるようになる
冒頭で「ジャーナルメモリバッファを有効にすると、プロセスクラッシュ時にレコード損失の可能性が出てくる」と書いたが、それで問題がないのかどうか。
結論から言えば「ケースバイケース」としか言えない。
もし整合性が最重要視されるようなデータばかりを扱うのであれば、ジャーナルメモリバッファは無効にしておくのが良い。逆に、そのようなデータが時折しか存在しないようであれば、その場合にだけjournal_syncオプションを使って明示的にバッファをフラッシュするように指示した方が性能は向上するだろう。また例えば「オフラインのバッチで、ストレージ間でデータをコピーする」といった用途であれば、失敗してもやり直せば済むだけなので、ジャーナルメモリバッファに大きめの値を指定してスループットを向上させた方が良いだろう。
別の例として、CannyLSの主要な利用者であるfrugalosでは、それ自体が分散・冗長化層を持っているため、仮にあるノード(プロセス)がクラッシュしてCannyLSの末尾部分のデータが失われたとしても、他のノードのプロセス群から復元可能であるため、致命的な問題となることはない。災害や大規模故障でクラスタ内の全ノードが一斉にダウンした場合には、直前に保存したはずのデータが(まだメモリバッファからディスクにフラッシュされていなかったために)失われてしまう可能性もあるが、そのようなケースであってさえも確実に整合性を保証したいデータがどの程度あるか、によってジャーナルメモリバッファを有効にすべきかどうかは変わってくる(個人的には、そのような大規模障害に対処したいのであれば「データセンタを跨いだ冗長化」といったようなディザスタリカバリ対策を適切に実施することの方を推奨する)。