【DBを自作する会 #1-2】ファイルシステムを理解しよう！─ファイル編
前回のおさらい
前回は、ファイルシステムを理解する最初の一歩として、ディスクドライブの構造を理解し、ブロックとページを学習しました。
0と1からなるバイト列を、「ブロック」という単位に分割し、主記憶上の「ページ」にロードすることで、ディスクへのアクセスを実現しようというものでした。
「ファイル」という概念
ここでは、ディスクアクセスをさらに抽象化することを考えます。
すなわち、アプリケーション側からの目線から、「ブロックとページさえも秘匿してしまう」概念を作ります。
プログラムからファイルを扱うことを考えます。例えば、「text.txt」というファイルに、"hello"と書き込むことを考えます。
この時、プログラムからの目線はこうなっています。
ここで、重ね重ねになりますが、
ファイルを操作しているとき、プログラムから「ブロック」が見えない
ことに留意してください。すなわち、「裏側でファイルとブロックを結びつける処理」が必要になるのです。その点を詳しく見ていきましょう。
論理ブロック参照（Logical Block Reference）
今、ブロックのサイズが 4096バイト（4KiB）だとします。このとき、ファイル「text.txt」の7992バイトめを参照するとどうなるでしょうか。つまり、以下の図の状況を指します。
これを見ると、text.txt の Block 1に7992バイトめが存在することがわかります。この、「text.txt の Block 1」という参照方法を「論理ブロック参照（Logical Block Reference）」といいます。
ファイルのバイト列から論理ブロック参照を見つけるのは簡単です。なぜなら、バイトのインデックスをブロックサイズで割れば見つかるからです。
物理ブロック参照（Physical Block Reference）
あるバイト列の参照位置が与えられた時、物理的にどのブロックに対応づけられるのかという情報が「物理ブロック参照」です。すなわち、実際にディスクのどの位置にブロックが格納されているのかを知る必要があるため、論理ブロック参照を算出するよりも難しいです。また、論理ブロック参照から物理ブロック参照への変換は、ファイルシステムの実装に依存します。上述した「FAT」や「NTFS」などによって、ブロックの格納方法に違いがあるためです。
このファイルシステムごとの実装の違いについては、また別でまとめるかもしれません。
Javaでのファイルレベルインタフェース例
こちらの記事に詳しいので、適宜ご覧ください！
データベースシステムとOSについて
OSは、「ブロックレベル」と「ファイルレベル」のインタフェースを両方ともサポートしています。すなわち、DBMSを作る際に、どちらを使って実装しても良いことになります。最後はこの２種類の利点と欠点を紹介しつつ、今後の実装パートでどう利用していくかについても触れながら進めたいと思います。
どちらを使う方がいいの？
ブロックレベルなら
今、ブロックレベルのインタフェースを使うとして、まず利点から見ていきます。
などが挙げられています。しかしながら、完全にマニュアルで扱う上で欠点もあります。
が挙げられています。
ファイルレベルなら
では、ファイルレベルのインタフェースではどうでしょうか。
まず利点として、
が挙げられています。しかしながら、完全にファイルレベルのインタフェースに依存してしまうと、実際のディスクアクセスの制御が一切できなくなってしまいます。これは主に2点の問題があります。
以上の理由から、どちらを取っても利点・欠点が明確のため、折衷案を用意してみます。
ハイブリッドなデータ管理
ブロックレベルとファイルレベルの管理をブレンドするのはどうでしょうか？以下の方法を考えてみます。
ということを考えてみます。簡単に言えば、「OS提供のファイルシステムを利用しつつ、DBMSも制御できるところは制御しよう」ということを主張しています。一見何を言っているのか分からないですね。
この部分は、1-3の実装パートにおいて詳しく述べたいと思います。
まとめ
ファイルレベルインタフェースについて理解が深まりました。
次回は、いよいよ実装編です。ブロック、ファイルを操作するためのクラスとメソッド群を定義していきます。第１回における読み物は一旦おしまいです。お疲れさまでした〜
Discussion