t100のプログラミング脱出作戦

自分のプログラミング脳をプログラムにして、いつかプログラミングから脱出してやるぞっ!とか夢見ながら、日々プログラム作っていく 百野 貴博 の日記です!今は、屋号『百蔵。』として、Silverlight・WPFを追跡中です! (2007/09/30)
スポンサーサイト
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
【--/--/-- --:--】 | スポンサー広告 | トラックバック(-) | コメント(-) top↑
MySQLのインデックスを調べついでに、ハードディスクに関して復習してみた。
現場の勉強会向けに、MySQLのインデックスの仕組みを勉強してみた際に、気になったことがあったので、ハードディスクに関して復習してみました。
情報処理2種試験受けて以来だな~。(古)

それにしても、分かってるようで分かってないもんですね~
当時では見えてなかったポイントも、経験値アップした今だから見える。みたいなこともありますよね。

というわけで、調べた内容を忘れないように簡単にまとめてみます。

調べたきっかけの疑問は、「詳解MySQL」の以下の分です。

MyISAM Bツリーはリーフと非リーフノード、すなわちページで構成されている。
デフォルトはここのページは1024バイトである。



はて?ページとは?
Oracleでも、SQL Serverでも、必ずファイルアクセスには「ページ」の話が出てきます。
よくよく考えると、「ページ」という単位で読む意味ってなんでしょう。


常にディスクI/Oがボトルネックになるデータベース。
もしかするとこれは、ハードディスクの性能を引き出す工夫なのかもしれません。
というわけで、調べてみました。
■ハードディスクの特徴

ハードディスクのデータ読み書き単位は、512バイトで固定されています。
この512バイトの単位を、セクタと呼びます。
つまり512バイト以下であれば、データは必ず連続した領域に記述されることが保障されます。

また、ハードディスクは、データを読むまでに物理的な待ち時間が存在します。これをシークタイムと言います。
ヘッドが適切な位置に動く時間と、ディスクがヘッドのところまで回転してくる時間の合計です。
そのため、物理的に連続した領域を読む方が効率が良く、ディスク上に点在したデータを読む方は効率が悪くなります。
(昨今ブームのSSDは、シークタイムが無いのでパフォーマンス特性が変わりそうです)

つまり、いかに物理的に連続した領域にデータを書けるか。が、パフォーマンス上の一つのポイントになりそうです。
でも、僕らがファイルを読み書きする時に物理的な連続性は意識しないけど、その辺どうなってるんだろう!

■OS側のディスクI/Oの特徴

ハードディスクは、512バイトがデータの単位(セクタ)になっていますが
実際は、それではサイズが小さすぎて運用上効率が良くありません。
そこで、OS側ではファイルシステムによって、複数のセクタをまとめて読み書きするように工夫しています。
これをクラスタと呼びます。
OSのファイルシステムを通してディスクに読み書きする場合は、このクラスタのサイズが読み書きの最小単位になります。
もちろん、1つのクラスタのデータは物理的に連続していることが保障されます。わお。

クラスタのサイズは、OSでファイルフォーマットを指定する際に決まります。
Windowsでは、「アロケーションユニットサイズ」と呼ばれています。
NTFSのデフォルトのアロケーションユニットサイズは、4096バイトとなっているので
ハードディスクの8セクタを1クラスタとしていることが分かります。

なるほど!4096バイト以下のデータは、必ず物理的に連続した領域に保存されるのか!
アロケーションユニットサイズは、512バイトから64キロバイトまで選択することができます。

アロケーションユニットサイズを大きくすると、たとえどんな小さなデータの保存にも、そのサイズが使われる為にディスクの使用に無駄が発生しやすくなります。(この、実際のファイルサイズと、使用されるサイズの差をクラスタギャップと言う)

データベースのような大きなファイルを扱う場合は、大きな値にしたほうが物理的に連続した領域にデータが保存されやすくなって、パフォーマンスアップが期待できそうですね。

■再びデータベースから考えると、、、

なるほど!HDDやOSのファイルシステムの特徴を考慮した上で考えだされたのが「ページ」という単位だったんですね!(たぶん)
インデックスのキーサイズや、データサイズを極力小さくした方が速度が早くなるというのもうなずけます。
一回の連続した領域に沢山データが入った方が、読み込むページ数が少なくなるもんね。

となると、ページサイズはOSのクラスタサイズと合わせた方が効率良いのでは?という気も。

というか、さらに言うとOSのファイルシステムに頼らずに、データベース自身が自分の都合の良いようにデータを物理的に書き込めたほうが、もっと良いパフォーマンスが出せそう。

これがいわゆる、OracleのRAWデバイスということなのか、、、(たぶん)
そしてMySQLでも使えるみたいです。RAWデバイス。(調べれてませんが、、、)


■今後、、、

ハードディスクの性能なんて情報処理試験の時は「何に使うんだ」と思っていましたが、ソフトウェアが最適な性能を出すにはハードウェアの特性を理解も重要ということですね。

今後、ハードディスクメーカーは512バイト以上のセクタサイズを持ったディスクを生産するそうです。
(もうある?)
そうなってくると、ハードディスクの性能指標として回転数、接続方式、シークタイム、バッファ等の他に、セクタサイズも加わりそうです。
ややこしいなぁ。

またSSD、Ramディスクの価格下落などで、場合によってはシークタイムの制約がそもそも無いメディアの選択肢も広がってきています。
こうなってくると、データベースのパフォーマンス特性も変わってきます。

いずれにしても、エンジニアとしてはシステムのパフォーマンスを最大限に生かせるようになっておきたいですね!



以下、今回の調査で参考にさせて頂いたサイトです。

2003年度 コンピュータリテラシー演習
4月24日:ファイルシステムの基礎


アロケーションユニットサイズについて


セクタ・クラスタ ・ファイルシステム(FAT・FAT32・NTFS)とファイルサイズ


【HDD】最適なアロケーションユニットサイズ


【初級】知っておきたいストレージの基礎 第2回 HDDの内部構造とスペックの読み方


ディスクパラメータの構造


ハードディスクのクラスタサイズ


セクタ サイズが大きいハード ディスク ドライブに対する Windows Vista のサポート


C#でセクタリード













管理者にだけ表示を許可する


トラックバックURL:
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。