RDBMS：单个大表的 RAID 与表分区答案

【问题标题】：RDBMS: RAID vs Table Partitioning for a Single Huge TableRDBMS：单个大表的 RAID 与表分区
【发布时间】：2013-12-24 00:49:22
【问题描述】：

我们有一个大约 10 TB 的大表，其中每行大约 10 KB。主键的类型是 BIGINT，它是均匀分布的。该服务器有 40 GB 的 RAM、两个 4 核 Xeon CPU 和五个 2 TB 磁盘。工作负载只是单次插入/更新或按主键选择。不需要任何事务或连接。

考虑到表和可用 RAM，缓存似乎不会很有效，因为查询大多是随机的。现在的问题是哪种配置更适合每秒更多查询（尤其是选择）：

我们想使用 MySQL，但也可以使用其他开源 DBMS，例如 PostgreSQL。从逻辑上讲，对于我们的设置，分区必须更好地工作，因为搜索分布在不同的磁盘之间。但是，最常用的模式是使用 RAID-0。

有没有人对这个问题有任何想法或经验。

【问题讨论】：

相关问题：stackoverflow.com/questions/45879/…
是的，我已经看到了，但没有帮助！
你存储什么样的数据？也许您需要的是分布式键值存储，而不是单个巨大的表。 Postgres 和 MySQL 提供了不同的优势，所以除非你能确定你在做什么，否则它们都是有效的选择。
@tadman 大部分数据是压缩文本。我知道我们可以使用 Voldemort、HBase 和 Cassandra 等解决方案。但是，我们只有一个服务器。我应该承认我们正在使用 RDBMS 作为键/值存储。
单个服务器不是这里的答案。至少设置一个管理程序并在您的系统上为每个物理驱动器设置一个虚拟实例，这将为您提供更多的耐用性。键值存储很容易分片。

【解决方案1】：

无论是在单独的物理磁盘上对数据进行分区，还是使用 RAID 0，其想法都是在可以并行工作的多个驱动器磁头/盘片之间分割磁盘访问以加快访问速度。

理论上，它们是相当等价的，但是，当我们考虑到索引带来的好处时，分区应该会出现。

您在问题中表示您正在插入记录（不仅仅是追加），因此，您的索引通常需要重建。重建一个较小的分区索引比重建一个巨大的索引开销更少，更不用说其他分区在重建另一个分区时不必等待的并发优势。

此外，搜索分区（较小）索引的速度更快。这两个索引的好处是表分区存在的主要原因，所以这里似乎是一个很好的例子。

我从未在多个物理磁盘上对表进行分区。假设这是可能的，这听起来是个好主意。

【讨论】：

RAID 在这里没有帮助。当您的阵列中的一个驱动器发生故障时，整个事情都将付之一炬。从可靠性的角度来看，最好拥有 N 个大小为 1 的服务器，而不是一个大小为 N 的服务器。RAID-0 阵列中的驱动器越多，发生灾难性故障的可能性就越高。
@SaeedShahrivari，只要您的条带大小 > 10k（例如 128k），就会分发 RAID 0 搜索。不过，您仍然会遇到边界问题。 RAID 0 处理扇区，而不是文件，每个磁头/盘片都尽可能快地为扇区提供服务。尽管如此，由于我在回答中陈述的原因，分区是更好的解决方案。
@MarcusAdams ，U R right RAID-0 可以帮助提高 IOPS，但在 RAID-0 中不能保证分配搜索，正如 U 所说，我认为分区是一个更好的解决方案。