データベースファイルを開いたプロセスが突然死した場合、次回にそのファイルを開いた際には自動的に復旧処理が走るようになっている。従来のバージョンでは、復旧に際して、データベース内の全レコードをスキャンして、データベースを再構築するのが専らであった。これは確実な方法だが、データベースの規模に応じた時間がかかってしまう。実際にはファイルを閉じなくても不整合は起きないことが多いので、その場合には再構築をしなくても復旧できる。よって、整合性の検査をした上で復旧処理を省略して高速化する機能を追加した。
マルチシャードのトランザクション
TkrzwにはShardDBMというクラスがあり、シャーディングで分割した複数のデータベースファイルをあたかも単一のデータベースであるかのように透過的に扱うことができる。複数マシンに分散しないローカル環境でも、シャーディングを施すと、並列処理性能や再構築処理等の効率の点で有利な点が多々ある。レイテンシが重要課題となるオンライン系での運用では特にシャーディングは有用だ。シャーディングによって複数のデータベースファイルが関わるとなると、トランザクションの独立性(Isolation)をどうやって実現するかが課題となる。今回は、トランザクションをコールバック関数の連続呼び出しとしてモデル化したProcessMultiメソッドと、任意の外部処理とCompare-and-Swapによって実現するためのCompareExchangeMultiメソッドの実装について説明する。
続きを読むCRCをデータベースに内蔵する
データベースにレコード単位のCRCを内蔵することで、データが破損した際の検出率を高められるようにした。ハッシュ関数の性能測定とそれを組み込んだ際のデータベースの性能測定もして、実用になることを確かめた。
これにより、Synchronizeを呼ばない運用でも、レコード単位の一貫性を向上させることができる。アプリケーションの責任でCRCをレコードのデータに付随させれば良いとも考えたが、面倒なことはやらない人が多いだろう。なので、やはりデータベース側で面倒を見ることにした。PostgreSQLやMySQLなどでもCRCは内蔵しているので、データベース側で一貫性の向上策を持つのは一般的とも言える。「はじめてのDBM」スライドにCRCを使った運用についても書いておいたので、ご覧いただきたい。