データベースはファイルシステムの断片化をどのように処理しますか？
特に、特定の行にランダムにアクセスするのではなく、テーブルの大部分をスキャンするクエリを最適化しようとする分析データベース。たとえば、Redshiftにはソートキーの概念があり、主要な挿入/更新/削除後にVACUUMが与えられると、データがソートキーに従ってディスク上で確実にソートされます。理想的には、これによりディスクシークが最小限に抑えられ、大規模なスキャンが最適化されます。
ただし、私の理解では、データベースはデータブロックをデータベースファイルのセットに書き込みます。そして、これらのファイルは、断片化の影響を受ける独自のブロックスキームを持つファイルシステムによって管理されます。では、データベースブロックがディスク上で正しくソートされるように、データベースはこれをどのように管理しますか（または、より正確にはVACUUMのようなものがこれをどのように管理しますか）。
ほとんどのデータベースは、他のデータベースがあまり実行されていないサーバーで実行されているという事実に関係していると思いますか？または、データベースには通常、独自のディスクパーティションが割り当てられていますか？または、データベースファイルは事前に大量のスペースを予約しますか？これらのいずれの場合でも、データベースと同じディスクスペースに書き込むプロセスはそれほど多くないので、データベースの制御外の断片化はあまりありませんか？
使用しているオペレーティングシステムと使用しているDBMSに応じて、それらの間の連携の程度は異なります。
たとえば、AIXでSyBase ASEを使用すると、DBMSだけが使用できるように、ファイルシステム全体を単一のモノリシック構造として割り当てるようにDBMSに指示できます。この場合、データベースisファイルシステムであり、ファイルシステムレベルの断片化は問題ではありません。
SQL Server、およびおそらく他のほとんどのDBMSの場合、データベースファイルは事前に設計されたファイルシステムに保存され、他のファイルが含まれる場合と含まれない場合があります。これらのデータベースファイルを含むファイルシステムにnotが他のシステムのファイルを含んでいる場合、ファイル自体の増大により、データベースファイルが断片化される可能性があります。
データベースと他のファイルの両方を含むファイルシステムでは、データベースファイルに対するファイル拡張操作により、ほぼ確実に物理的に断片化されます。私の知る限り、オペレーティングシステムと直接統合してPrevent物理ファイルの断片化を行うDBMSはありません。
多くの大規模な本番データベースシステムは、物理マシンの仮想化、ストレージエリアネットワーク（SAN）などの非常に複雑なシステムで実行されます。これらのシステムは、それらを使用するマシン間でリソースを共有するように設計されています。 SANに格納されているデータベースの場合、データベースファイルを含むSANの物理ブロックが、実際には多数の物理ドライブに分散される可能性が非常に高くなります。ブレントオザール氏は、「EMC、NetApp、Dellギアなど、多数の異なるサーバー間でドライブを共有する共有ストレージを使用している場合、ドライブへのアクセスはすべてランダムになります。ハードドライブは同時にドライブリクエストを行っている他のサーバーと共有されているため、ドライブは常にデータを取得するためにあちこちを飛び回っています。」1