Berkeley DB
ログマネージャ
ログマネージャーは、構造化された追記限定のファイルを抽象化したものである
ログの概念は極めてシンプルである。不透明なバイト文字列を受け取り、それをシーケンシャルにファイルへ書き出し、各レコードに一意な識別子を付与する。この識別子はログシーケンス番号(LSN)と呼ばれる
LSNを使ってレコードの取得などをやる。
- 追記しかしないデータ構造
- LSNの形式はファイル番号とファイル内オフセットのペア
- ゆえに場所は簡単にわかる
注意点
- 障害時でも一貫性の保証
- パフォーマンス
設計講座11
ソフトウェアの構造を改良するため根本的にフレームワークを変更してしまうことを恐れてはいけない。また、一部だけ変更して後で徐々に整えていこうなんて考えではいけない。やるなら全体的にやってしまって、それから次に進もう。何度となく言われているように、「今それをする時間がないのなら、いつまでたってもそんな時間はひねり出せないだろう」ってことだ。また、フレームワークを変更するときにはテストもきちんと書いておこう
ログレコード書式
ログには必ずレコード単位のメタデータが含まなければならない。そうすれば、LSNさえわかれば返すレコードのサイズもわかるようになる
レコードヘッダがログレコードに含まれる
- オフセット
- チェックサム
トランザクションIDを見ればそのログレコードがどのトランザクションに属するのかがわかるので、リカバリー中にそのレコードを無視できるのか処理が必要なのかも判断できる
設計講座12
大量のソフトウェア部品を組み上げたり保守したりする能力はとてもはかないものだということである。大量のソフトウェア部品を組み上げたり保守したりするのは難しくて間違いを犯しやすい。そして、ソフトウェアアーキテクトとして、できる限りのことをしてできるだけ早くできるだけ頻繁にソフトウェアが運ぶ情報を最大化しなければならない
Building and maintaining significant pieces of software is difficult and error-prone, and as the software architect, you must do everything that you can, as early as you can, as often as you can, to maximize the information conveyed in the structure of your software.
積分値→整数値
ログ先行書き込みとなんの関係があるのだろう…
抽象化違反
特別なログレコード チェックポイントレコード
チェックポイントとは、ある特定時点のデータベースの状態をディスク上に書き出す処理のことである
一般に、ログマネージャー自身はレコードタイプを気にしないものだ。
ログマネージャーとトランザクションマネージャーがそれぞれログをまるごと読み込んで位置を調べるのではなく、トランザクションマネージャーがその処理をログマネージャーに委譲するということだ。抽象化による処理の切り分けに違反してでもパフォーマンスを求めたという、ありがちな話だ
有害なレイヤー化違反あるいは抜け目のないパフォーマンス最適化
Berkeley DBのログレコードの大半はデータベースを特定できなければならない。各ログレコードにデータベースファイルのフルパスを含めてもよいが、そんなことをすればログの容量が肥大化するしあまり美しくない
→かわりに一意な整数値を記録
ファイル名とログファイルIDのマッピングを管理
設計講座13
バグを修正するときには、単におかしなところを見つけるだけではいけない。なぜそうなったのか、何か誤解があったのではないかということを探るようにしよう。そうすれば、そのプログラムのアーキテクチャをより深く理解できるようになるし、そもそもの設計自体に根本的な問題があればそれもはっきりするだろう。
びっくりするほどいいこと言ってる
