什么是分片，为什么它很重要？

Question

我想我明白分割会将你的分片数据（碎片）放回一个容易处理的聚合，在上下文中是合理的。它是否正确？

更新：我想我在这里挣扎。在我看来，应用层应该没有业务决定数据应该存储在哪里。充其量，它应该是某种碎片客户端。两个回答都回答了什么，但不是为什么它是重要的方面。除了显而易见的绩效收益之外，它有什么影响？这些收益是否足以抵消MVC违规？在非常大规模的应用中分片是非常重要的，还是适用于小规模应用？

Answer 1

分片是数据库的“水平分区”的另一个名称。您可能想要搜索该术语以使其更清晰。

从Wikipedia：

水平分区是一个设计原则，即一个数据库表的行是通过列分开保存，而不是分裂（作为归一化）。每个分区构成分片的一部分，分片又可位于单独的数据库服务器或物理位置上。优点是减少了每个表中的行数（这减少了索引大小，从而提高了搜索性能）。如果分片基于数据的某些真实世界方面（例如，欧洲客户与美国客户），则可以容易且自动地推断适当的分片成员资格，并且仅查询相关的分片。

约分片部分的更多信息：

首先，每个数据库服务器是相同的，具有相同的表结构。其次，数据记录在逻辑上被拆分成分片数据库。与分区数据库不同，每个完整的数据记录只存在于一个分区中（除非镜像备份/冗余），并且所有CRUD操作都在该数据库中执行。您可能不喜欢使用的术语，但这确实代表了将逻辑数据库组织成更小部分的不同方式。

更新：你不会打破MVC。确定正确的分片在哪里存储数据的工作将透明地由您的数据访问层完成。在那里你必须根据你用来分割数据库的标准来确定正确的分片。 （因为您必须根据应用程序的某些具体方面手动将数据库分割成不同的分片。）然后，在从/向数据库加载和存储数据以使用正确的分片时，必须小心。

也许this example与Java代码使它更清晰（这是关于Hibernate Shards项目），这将如何在现实世界的情况下工作。

，解决“why sharding”：这是主要只针对超大规模应用，大量数据。首先，它有助于最小化数据库查询的响应时间。其次，您可以使用更便宜的“低端”机器来托管您的数据，而不是一个大型服务器，这可能不足以满足您的需求。

Answer 2

如果你有一个数据库管理系统的查询，这些数据库的局部性是非常有限的（比如说，用户只用'where username = $ my_username'来激发选择），那么把所有以AN开头的用户名放在一个服务器上是有意义的所有来自MZ。通过这个，你可以对某些查询进行线性缩放。

长话短说：分片基本上是将表分配到不同服务器上的过程，以平衡两者之间的负载。

当然，它在现实中要复杂得多。 :)

Answer 3

是非常 大规模应用主要分片重要的或者它 适用于规模较小的呢？

当且仅当您的需求超出单个数据库服务器可以提供的服务范围时，分片才成为问题。如果您有可分片数据，并且您具有令人难以置信的高可扩展性和性能要求，那么这是一个膨胀的工具。我想，在我整整12年里，我一直是一名软件专业人员，我遇到过一种可能从分片中受益的情况。这是一种适用性非常有限的先进技术。

而且，未来很可能会成为一些有趣和令人兴奋的像一个大质量天体“云”是将删除所有潜在的性能限制，对不对？ :)

Answer 4

在我看来，应用层 应该没有企业判断 在数据应该存储

这是一个很好的规则，但最喜欢的事情并不总是正确的。

当你做你的架构开始与责任和合作。一旦你确定了你的功能架构，你必须平衡非功能性的力量。

如果这些非功能性的力量之一是巨大的可扩展性，你必须适应你的架构，以迎合这股力量，即使这意味着您的数据存储抽象现在泄漏到您的应用程序层。

Answer 5

分片最初是由谷歌工程师创造的，你可以看到写在谷歌App Engine应用程序时，它使用相当严重。由于您的查询可以使用的资源数量有严格的限制，并且由于查询本身具有严格的限制，因此分片不仅受到鼓励，而且几乎被该体系结构强制执行。

另一个地方拆分可以使用是减少对数据实体的争用。当构建可扩展的系统来关注经常编写的那些数据时，这一点尤为重要，因为它们始终是瓶颈。一个好的解决方案是分离出特定的实体并写入多重副本，然后读取总数。这种“分片计数器WRT GAE的一个例子：这些网络研讨会http://code.google.com/appengine/articles/sharding_counters.html