Database design 何时使用水平分区，何时使用数据库分片？

我正在维基百科上读这篇文章：试图找出这两种技术之间的主要区别。以下是我的发现：

水平分区通常按行分割一个或多个表 在架构和数据库服务器的单个实例中。可能 通过减少索引大小（从而减少搜索工作量）提供优势 前提是有一些明显的、可靠的、隐含的方法来识别 在哪个表中可以找到特定的行，而不需要首先 搜索索引，例如“CustomerEast”的经典示例 和“CustomerWest”表，它们的邮政编码已经表明 在那里可以找到它们

切分超出了这个范围：它将有问题的表划分为 同样的方法，但它可能跨多个实例执行此操作 模式的一部分。明显的优势是，搜索负载为 大型分区表现在可以跨多个服务器拆分 （逻辑或物理），而不仅仅是同一逻辑上的多个索引 服务器

据我所知，水平分区更适用于单实例（单节点环境），而分片则用于多节点/多数据中心环境。这是正确的吗？或者有不同的使用场景

---

额外问题：对于一个具有简单模式（大约4-5列）的大型表（有数百万行），提高该表读/写性能的最佳技术是什么？

没错，水平分区（例如在MySQL和PostgreSQL中受支持）将一个表拆分到单个服务器中。这可以提高性能，因为数据和索引可以跨多个磁盘卷拆分，从而提高I/O。这通常是通过密钥范围来完成的

通过数据库分片，您可以将数据划分到多个服务器上，而不仅仅是单个服务器上。在这种情况下，您使用一个分片键来划分数据，通常使用某种散列算法。您可以在此处获得关于此主题的白皮书（由我们公司提供，它不是针对任何产品的，它解释了技术）：

DBMS单服务器分区的优点是设置和管理相对简单。缺点是最终您会受到单个服务器的限制。当涉及到大量写入争用、数据库锁定和大量查询时，情况尤其如此

数据库分片需要更多的工作，但它的优点是不共享，因此它是完全可扩展的

当单个服务器无法跟上写入卷的速度时，需要使用数据库分片的一个明确指标。如果您有许多繁重的查询，这也会促使您需要这种类型的解决方案

话虽如此，如果你说的是4-5列的“数百万”行，并且你的读取可以很好地被索引以便快速访问，那么你是否需要实现这两个选项中的任何一个都是值得怀疑的。当您谈论的是1亿或数十亿行，以及1000多个用户时，数据库的可伸缩性至关重要

---

还有一个关于数据库可伸缩性的信息网站：。它包括到各种文章的链接，并将随着时间的推移添加新内容。

您对分区和分片的区分是正确的。 我建议你仔细阅读我写的一篇关于这个主题的文章：

另一个好帖子可以在这里找到：“ （免责声明：我为ScaleBase工作）

分区解决了一些大小挑战和表读取问题，但切分是真正解决大型数据库所有方面的唯一方法，包括读取和写入以及数据库实例（备份、复制等）的并发性和维护等

虽然像MongoDB这样的现代数据库（通常是NoSQL）提供了这种开箱即用的功能，但在MySQL中，它曾经是“自己动手”的议程。。。 ScaleBase是一个完整的横向扩展解决方案的制造商，如果您愿意，它可以称为“自动切分机”。ScaleBae分析您的数据和SQL流，在数据库节点之间拆分数据，在运行时路由命令并聚合结果–因此您不必这样做

希望有帮助

---

Doron

巨大的表格不是数百万行。巨大的表现在至少有500亿行。在不了解数据和查询模式的情况下，无法选择一种最佳的技术来提高读/写性能。任何声称要告诉您如何做到这一点的人都将面临一个尴尬的问题，即对于相同“大小”的两个数据库，性能相差悬殊