了解块大小

我的问题针对Postgres，但从任何数据库背景来看，答案可能就足够好。

我的假设正确吗：

• 磁盘具有固定的块大小？
• RAID控制器可以具有不同的块大小吗？是否将一个RAID块拆分为多个实际磁盘块？
• 该文件系统还具有独立的块大小，该块大小又被拆分为RAID块大小吗？
• Postgres适用于固定的8k块。到文件系统块大小的映射在这里如何发生？文件系统是否将Postgres 8k块批处理在一起？

设置系统时，最好将所有块都设置为8k？还是设置不是很重要？我还想知道在崩溃时某些“错误”的块大小设置是否会危害数据完整性？也许Postgres 8k块必须拆分为多个磁盘块？

还是什么都没有批处理在一起，因此我在定义的块大小之间的每一个不匹配都会丢失磁盘空间？

磁盘扇区

磁盘具有固定的扇区大小，在某些现代磁盘上通常为512字节或4096字节。这些磁盘还将具有一种模拟512字节扇区的模式。磁盘上的磁道具有不同数量的扇区。在给定的位密度下，距离磁盘更近的磁道具有更多的扇区。这样可以更有效地利用磁盘空间。通常，一个轨道在现代磁盘上将具有大约1,000 512字节的扇区。

某些格式化结构还可以在保护区中包含纠错信息，该信息在以520或528字节扇区进行低级格式化的磁盘中体现出来。在这种情况下，该扇区仍具有512字节的用户数据。Windows和Linux都不直接支持此功能，尽管i5OS（IBM iSeries）和各种SAN控制器都支持。

通常，扇区/磁头/磁道被翻译成逻辑块地址。由于具有向后兼容性的历史问题，操作系统（特别是在IDE和SATA磁盘上）看到的几何形状（磁头x扇区x磁道）通常与其物理结构无关。

RAID条带大小

RAID控制器可以使用条带化（例如RAID-5或RAID-10）为阵列提供条带化大小。如果阵列（例如）有128k条带，则每个磁盘具有128k连续数据，然后下一组数据位于下一个磁盘上。通常，您可以期望磁盘每转大约获得一个条带，因此条带大小可能会影响某些工作负载上的性能。

分区对齐

磁盘分区可能会（也可能不会）与RAID条带完全对齐，并且如果未对齐，则会由于拆分读取而导致性能下降。某些系统（例如Windows 2008 Server）将自动配置分区以使其与磁盘卷条带大小一致。某些（例如Windows 2003 Server）不会，并且您必须使用支持条带对齐的分区实用程序以确保它们这样做。

文件系统块大小

文件系统将按一定大小的块分配存储块。通常，这是可配置的-例如NTFS将支持从（IIRC）4K到64K的分配单位。分区和文件系统块与RAID条带对齐不正确会导致单个文件系统块读取生成多个磁盘访问，如果文件系统块与RAID条带正确对齐，则仅需要进行一次磁盘访问。

数据库块大小

数据库将以给定的块大小在表或索引中分配空间。对于SQL Server，此值为8K，而在许多系统上，默认值为8K。在某些系统（例如Oracle）上，这是可配置的，而在PostgreSQL上，这是一个构建时选项。在大多数系统上，对表的空间分配通常是在较大的块中完成的，而在这些块中分配了块。

文件系统和数据分配块的未对齐可能会为单个块写入生成多个I / O，这可能会导致性能下降。

I / O分块

通常，DBMS实际上将以一个以上的块为单位进行I / O。例如，在SQL Server上，所有I / O以8个块的块（总计64k）完成。在Oracle上，这是可配置的。随意检查PostgreSQL文档并没有显示有关PostgreSQL是否执行此操作的具体描述，因此我不确定它在该平台上如何工作。

当I / O块大于文件系统块大小或未与RAID条带边界对齐时，从DB进行磁盘写操作可能会导致多次磁盘写操作，从而导致性能下降。

磁盘空间使用

不会浪费磁盘空间-数据库I / O将使用磁盘上的一个或多个物理I / O操作来完成-但是错误地调整I / O会产生效率低下的问题，从而降低数据库的速度。必须保持一致的主要内容是：

• RAID条带和分区-分区应从RAID条带边界开始。

• 文件系统I / O分配和RAID条带/分区边界-RAID条带边界必须与文件系统分配单元对齐，并且应为文件系统分配单元大小的倍数。

• 磁盘写大小和文件系统分配单元大小。数据库I / O操作和文件系统I / O操作之间应该存在1：1的关系。

与其他情况相比，未对齐不会造成更大的数据完整性问题。数据库和文件系统具有适当的机制来确保文件系统的外观是原子的。通常，磁盘崩溃将导致数据丢失，但不会导致数据完整性问题。