我正在维基百科上阅读这篇文章：http://en.wikipedia.org/wiki/Shard_(database_architecture)试图找出这两种技术之间的主要区别。这是我发现的：
水平分区通常按行拆分一个或多个表 在模式和数据库服务器的单个实例中。有可能 通过减少索引大小（以及搜索工作量）提供优势 只要有一些明显的，强大的，隐含的识别方法 在哪个表中将找到特定的行，而不需要 搜索索引，例如'CustomersEast'的经典示例 和'CustomersWest'表，他们的邮政编码已经表明了 他们将被发现的地方。
Sharding超越了这个：它将有问题的表分区为 以同样的方式，但它可能跨多个实例 架构。显而易见的优点是搜索负载 现在，可以跨多个服务器拆分大型分区表 （逻辑或物理），而不仅仅是同一逻辑上的多个索引 服务器
据我所知，水平分区更适用于单实例（单节点环境），而分片则用于多节点/多数据中心环境。它是否正确？或者有不同的使用场景吗？
额外的问题：对于具有简单模式（大约4-5列）的大型表（具有数百万行），提高此表的读/写性能的最佳技术是什么？
答案 0 :(得分：8)
你是对的，水平分区（例如在MySQL和PostgreSQL中支持）在单个服务器中分割表。这可以提高性能，因为可以跨多个磁盘卷拆分数据和索引，从而改善I / O.这通常使用关键范围来完成。
使用数据库分片，您可以跨多个服务器划分数据，而不仅仅是在单个服务器中。在这种情况下，您使用分片键来对数据进行分区，通常使用某种散列算法。你可以在这里获得关于这个主题的白皮书（由我们公司提供，它不是特定于任何产品，它解释了技术）：http://www.codefutures.com/database-sharding-white-paper/
DBMS单服务器分区的优点是设置和管理相对简单。缺点是最终您受限于单个服务器可以执行的操作。当涉及大量写入争用，数据库锁定和繁重查询时，尤其如此。
数据库分片需要更多工作，但具有无共享方法的优势，因此它具有完全可扩展性。
需要数据库分片的明确指标是单个服务器无法跟上写入量。如果您有许多繁重的查询，这也可能需要这种类型的解决方案。
说完所有这些，如果你在谈论＆＃34;数百万＆＃34;有4到5列的行，并且您的读取可以很好地索引以便快速访问，但是您是否需要实现这些选项中的任何一个都是值得怀疑的。当您谈论数百万或数十亿行，拥有1000个用户时，这就是数据库可扩展性至关重要的地方。
我正在研究一个关于数据库可扩展性的信息网站：www.bigdatascalability.com。它包含各种文章的链接，并会随着时间的推移添加新内容。
答案 1 :(得分：0)
区分分区和分片是正确的。 我建议你仔细阅读我在这个主题上写的帖子：Scale Up, Partitioning, Scale Out
这里可以找到另一个好帖子：＆＃34; MySQL Partitioning: A Stopgap Measure＆＃34; （免责声明：我为ScaleBase工作）
分区解决了一些大小挑战并从表中读取，但分片只是真正解决大数据库所有方面的方法，包括读取和写入以及数据库实例的并发和维护（备份，复制等）和所有方面其他
虽然像MongoDB这样的现代数据库（通常是那些NoSQL）提供了这种开箱即用的功能，但在MySQL中，它已经过去了＃34;自己去了＃34;议程... ScaleBase是一个完整的横向扩展解决方案和自动分片机＆＃34;如果你喜欢。 ScaleBae分析您的数据和SQL流，跨数据库节点分割数据，路由命令并在运行时聚合结果 - 所以您不必这样做！
希望有所帮助！
多伦