ブロックサイズの理解

Question

私の質問はPostgresをターゲットにしていますが、回答はどのデータベースの背景からも十分に良いかもしれません。

私の仮定は正しいですか：

• ディスクには固定ブロックサイズがありますか？
• RAIDコントローラーは、ブロックサイズが異なる場合がありますか？ 1つのRAIDブロックは複数の実際のディスクブロックに分割されますか？
• ファイルシステムには、独立したブロックサイズもあり、再びRAIDブロックサイズに分割されますか？
• Postgresは、固定された8Kブロックで動作します。ここでファイルシステムのブロックサイズへのマッピングはどのように行われますか？ Postgres 8Kブロックはファイルシステムによってバッチされていますか？

システムをセットアップするときは、8Kですべてのブロックを使用するのが最善ですか？それとも、設定は本当ではありませんか？また、「間違った」ブロックサイズの設定が、クラッシュの場合にデータの整合性を危険にさらす可能性があるかどうか疑問に思っていましたか？たぶん、Postgres 8Kブロックを複数のディスクブロックに分割する必要がある場合は？

または、何もバッチされていないので、定義されたブロックサイズの間のすべての不一致でディスクスペースを失いますか？

Answer 1

ディスクセクター

ディスクには固定セクターサイズがあり、通常は512バイトまたは一部の最新のディスクで4096バイトです。これらのディスクには、512バイトセクターをエミュレートするモードもあります。ディスクには、さまざまな数のセクターを持つトラックがあります。ディスクの外側に近いトラックには、特定のビット密度の余地が増えているため、セクターが増えています。これにより、ディスクスペースのより効率的な使用が可能になります。通常、トラックには、最新のディスク上の1,000 512バイトセクターのようなものがあります。

一部のフォーマット構造には、520または528バイトのセクターで低レベルのフォーマットされているディスクに現れるSecotrsのエラー修正情報も含まれます。この場合、セクターにはまだ512バイトのユーザーデータがあります。 i5os（IBM Iseries）やさまざまなSANコントローラーが行っていますが、WindowsもLinuxもこれを直接サポートしていません。

通常、セクター/ヘッド/トラックは論理ブロックアドレスに翻訳されます。後方互換性に関する歴史的な問題により、オペレーティングシステム（特にIDEおよびSATAディスクで）で見られるジオメトリ（ヘッドxセクターxトラック）は通常、その物理的構造とはほとんど関係がありません。

襲撃ストライプサイズ

RAIDコントローラーは、ストライピングを使用してアレイ用のストライプサイズを持つことができます（RAID-5またはRAID-10など）。アレイに（exmaple用）128kのストライプがある場合、各ディスクには128kの連続データがあり、次のデータセットは次のディスクにあります。通常、ディスクの革命ごとに約1つのストライプを取得することが期待できます。そのため、ストライプサイズは特定のワークロードのパフォーマンスに影響を与える可能性があります。

パーティションアライメント

ディスクパーティションは、RAIDストライプと正確に整列する場合とまったく合わない場合があり、整列されていない場合、分割読み取りによりパフォーマンスの低下を引き起こす可能性があります。一部のシステム（Windows 2008サーバーなど）は、ディスクボリュームストライプサイズに合わせてパーティションを自動的に構成します。一部（Windows 2003サーバーなど）はそうではありません。また、Stripeアラインメントをサポートして確認するパーティションユーティリティを使用する必要があります。

ファイルシステムブロックサイズ

ファイルシステムは、特定のサイズのチャンクにストレージブロックを割り当てます。通常、これは構成可能です - たとえば、NTFは（IIRC）4K〜64Kの割り当て単位をサポートします。パーティションとファイルシステムブロックをraidストライプに誤って調整すると、単一のファイルシステムブロックが読み取られ、ファイルシステムがRAIDストライプと正しく整列した場合に1つだけが必要な複数のディスクアクセスが生成されます。

データベースブロックサイズ

データベースは、特定のブロックサイズでテーブルまたはインデックスのスペースを割り当てます。 SQL Serverの場合、これは8Kで、8Kは多くのシステムでデフォルトです。 Oracleなどの一部のシステムでは、これは構成可能であり、PostgreSQLではビルドタイムオプションです。ほとんどのシステムでは、テーブルへのスペース割り当ては通常、より大きなチャンクで行われ、それらのチャンク内にブロックが割り当てられます。

ファイルシステムとデータ割り当てブロックの不整合により、単一のブロック書き込みの複数のI/OSが生成され、パフォーマンスペナルティが促進されます。

i/oチャンキング

通常、DBMSは実際に複数のブロックのチャンクでI/Oを実行します。たとえば、SQL Serverでは、すべてのI/Oは8ブロックのチャンク、合計64Kのチャンクで行われます）。 Oracleでは、これは構成可能です。 PostgreSQLドキュメントのカジュアルな検査では、PostgreSQLがこれを行うかどうかの特定の説明が明らかにされていないため、このプラットフォームでどのように機能するかはわかりません。

ファイルシステムのブロックサイズよりも大きいI/Oチャンク、またはRAIDストライプ境界で誤って調整されている場合、DBからのディスクの書き込みは複数のディスク書き込みを引き起こす可能性があり、パフォーマンスペナルティが生成されます。

ディスクスペースの使用

ディスクスペースは無駄になりません - データベースI/Oは、ディスク上の1つ以上の物理I/O操作を使用して完了しますが、誤って調整されたI/Oは、データベースを遅くする非効率性を生成できます。整合しなければならない主なことは次のとおりです。

• 襲撃ストライプとパーティション - パーティションは、RAIDストライプ境界で開始する必要があります。

• ファイルシステムI/Oの割り当ておよびRAIDストライプ/パーティションの境界 - RAIDストライプ境界は、ファイルシステム割り当てユニットに合わせて、ファイルシステム割り当てユニットサイズの複数でなければなりません。

• ディスク書き込みサイズとファイルシステム割り当てユニットサイズ。データベースI/O操作とファイルシステムI/O操作の間には1：1の関係があるはずです。

ミスアライメントは、そうでなければ存在するよりも大きなデータ整合性の問題を作成しません。データベースとファイルシステムには、ファイルシステムのオペアがアトミックであることを確認するためのメカニズムがあります。通常、ディスククラッシュはデータの損失をもたらしますが、データの整合性の問題は発生しません。