了解块大小

Question

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

我的假设是否正确：

• 磁盘有固定的块大小吗？
• RAID 控制器可以有不同的块大小？是否将一个 RAID 块拆分为多个实际磁盘块？
• 文件系统也有一个独立的块大小，它再次被拆分为 RAID 块大小？
• Postgres 使用固定的 8k 块。这里是如何映射到文件系统块大小的？Postgres 8k 块是否由文件系统批量处理？

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

或者没有任何东西一起批处理，因此我会因定义的块大小之间的每一次不匹配而丢失磁盘空间？

Answer 1

磁盘扇区

磁盘具有固定的扇区大小，在一些现代磁盘上通常为 512 字节或 4096 字节；这些磁盘也有一种模式，可以模拟 512 字节扇区。磁盘将具有不同扇区数的磁道；靠近磁盘外部的磁道有更多的扇区，因为它们对于给定的位密度有更多的空间。这允许更有效地使用磁盘空间；通常，一个磁道在现代磁盘上会有 1,000 个 512 字节的扇区。

一些格式化结构还可以在 secotrs 中包含纠错信息，这体现在磁盘被低级格式化为 520 或 528 字节扇区。在这种情况下，扇区仍然有 512 字节的用户数据。尽管 i5OS (IBM iSeries) 和各种 SAN 控制器支持，但 Windows 和 Linux 都不直接支持这一点。

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

RAID 条带大小

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

分区对齐

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

文件系统块大小

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

数据库块大小

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

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

输入/输出分块

通常，DBMS 实际上会以多于一个块的块的形式执行其 I/O。例如，在 SQL Server 上，所有 I/O 都是在 8 个块的块中完成的，总共 64k）。在 Oracle 上，这是可配置的。对 PostgreSQL 文档的随意检查并没有揭示 PostgreSQL 是否这样做的具体描述，所以我不确定它在这个平台上是如何工作的。

当 I/O 块大于文件系统块大小或与 RAID 条带边界未对齐时，从数据库写入磁盘可能会导致多个磁盘写入，从而产生性能损失。

磁盘空间使用

不会浪费磁盘空间 - 数据库 I/O 将使用磁盘上的一个或多个物理 I/O 操作来完成 - 但不正确调整的 I/O 会导致效率低下，从而降低数据库速度。必须保持一致的主要事项是：

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

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

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

未对齐不会产生比其他情况下更大的数据完整性问题。数据库和文件系统有适当的机制来确保文件系统操作是原子的。通常，磁盘崩溃会导致数据丢失，但不会导致数据完整性问题。