先日、Sun Micro SystemsのCOOがblogを書いているとHarvard Business Reviewで知り、調べてみたのです。そうすると、Sunのdeveloperさんなどもblogを書いており、興味本位で、覗いてみると、ZFS at OpenSolaris.orgという新しいファイルシステムのプロジェクトを発見しました。
通 常のデータベースは、データを一元管理するので、データの更新時、ディスク上のデータを書き換えるという操作をします。複数ユーザによる同時書き込みを防 止するために、データがある部分を保護（write lock)するのですが、このwrite lockはファイルシステムの性能を上げる際のボトルネックになることが多いのです。 なにせこの領域のロックが開放されるまで、他がその部分にアクセスできないので。また、read lockを取得後、write lockを取得してデータを書き換えるというプロセスは、デッドロックに陥りやすいという欠点もあります。
write lockを使わずに同時書き込みを防止するには、versionningといって、古いデータを上書きせずにとっておいて、更新後のデータを別のディスク 領域に書き出します。 この方式(Multiversion 2PL)はPostgreSQLでも採用されていて、古くなったデータの後始末さえうまく行えば、readトランザクションは、writeを気にせずデー タをとりだせるので、それなりの性能を発揮できます。ただ、このversion管理がわりと曲者で、B-Treeなどのデータ構造に、version管理 用のデータ構造を組み合わせる必要があるので、目的のデータにたどり着いてもversionを調べる分アクセスが間接的になるし、遅いイメージがありまし た。
け れど、ZFSでは、B-Treeのようなデータ構造を、更新時に新しいversionにswapしてしまうのです。swap操作は、リンクの張替えだけな ので、負荷は低く抑えられます。簡単だし、version管理の長所そのままを具現化したものなのですが、目から鱗が落ちる思いです。た だ、トランザクション管理は、B-Treeではここ20年の研究成果が集積されていて随分安全になっているのですが、ログを管理をしないこの木の入れ替 え方式がどこまで、データベースのトランザクション管理に応用できるかは、検証してみないといけない。ログがない時点で、ディスクエラーには強くても、 rollbackには対応していないのは明らか。でも、利用価値は存分にあります。
研究者として、本質的に新しい方式を見るのはわくわくします。 最新の研究といっても、既存の技術をこねくりまわしたものが多いご時勢なので。
0 件のコメント:
コメントを投稿