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

Question

我认为我理解将分片数据（分片）放回到易于处理在上下文中有意义的聚合的分片。它是否正确？

更新：我想我在这里挣扎。在我看来，应用程序层应该没有业务确定应该存储数据的位置。最好它应该是某种类型的分片客户端。两个回答都回答了什么，但不是为什么它是重要方面。除了明显的性能提升之外，它有什么影响？这些收益是否足以抵消MVC违规？分片在大规模应用中最重要，还是适用于较小规模的应用？

Answer 1

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

来自Wikipedia：

  

水平分区是一种设计原则，数据库表的行分别保存，而不是按列分割（对于规范化）。每个分区都构成分片的一部分，分片又可以位于单独的数据库服务器或物理位置。优点是减少了每个表中的行数（这减少了索引大小，从而提高了搜索性能）。如果分片基于数据的某些实际方面（例如，欧洲客户与美国客户），则可以轻松自动地推断出适当的分片成员资格，并仅查询相关分片。

有关分片的更多信息：

  

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

更新：你不会破坏MVC。确定正确的分片存储数据的位置的工作将由您的数据访问层透明地完成。在那里，您必须根据用于对数据库进行分片的条件来确定正确的分片。 （因为您必须根据应用程序的某些具体方面手动将数据库分为几个不同的分片。）然后，在从数据库加载和存储数据以使用正确的分片时，您必须小心。

使用Java代码时，this example可能会使它更清晰（它是关于Hibernate Shards项目），这在现实场景中是如何工作的。

解决“why sharding”问题：它主要适用于非常大规模的应用程序， lot 数据。首先，它有助于最小化数据库查询的响应时间。其次，您可以使用更便宜的“低端”计算机来托管您的数据，而不是一台大型服务器，这可能还不够。

Answer 2

如果您对DBMS的查询非常有限（例如，用户仅使用'where username = $ my_username'激发选择），那么将所有以AM开头的用户名放在一台服务器上是有意义的所有来自新西兰的。通过这种方式，您可以获得一些查询的线性缩放。

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

当然，它在现实中要复杂得多。 ：）

Answer 3

着色是水平（行明智）数据库分区，而垂直（列明智）分区是 Normalization 。它将非常大的数据库分成更小的，更快的和更容易管理的部分，这些部分称为数据碎片。这是一种实现分布式系统的机制。

我们为什么需要分布式系统？

• 增加可用性。
• 更容易扩展。
• 经济学：借助一台大型计算机的功能，创建小型计算机网络的成本更低。

您可以在此处了解更多信息：Advantages of Distributed database

分片如何帮助实现分布式系统？

您可以将搜索索引划分为N个分区，并将每个索引加载到单独的服务器上。如果查询一台服务器，将得到结果的1 / N。因此，为了获得完整的结果集，典型的分布式搜索系统使用聚合器，该聚合器将从每个服务器中收集结果并进行组合。聚合器还将查询分发到每个服务器上。在大数据术语中，此聚合程序称为MapReduce。换句话说，分布式系统=分片+ MapReduce（尽管也有其他东西）。

下面的视觉表示。

Answer 4

  

分片最重要的是非常重要   大规模的应用程序或它   适用于较小规模的？

当且仅当您的需求超出单个数据库服务器所能提供的服务时，才需要进行分片。如果您拥有可分析数据并且具有极高的可伸缩性和性能要求，那么它就是一个膨胀工具。我想在我12年的时间里，我一直是一名软件专家，我遇到过一种可能从分片中受益的情况。这是一种适用性非常有限的先进技术。

此外，未来可能会变得有趣和令人兴奋，就像一个消除所有潜在性能限制的大型对象“云”，对吧？ ：）

Answer 5

Sharding最初是由谷歌工程师创造的，你可以看到它在Google App Engine上编写应用程序时使用得相当多。由于查询可以使用的资源量存在严格限制，并且查询本身具有严格的限制，因此不仅鼓励分片，而且几乎强制执行分片。

可以使用分片的另一个地方是减少对数据实体的争用。在构建可扩展系统时要特别注意那些经常写入的数据，因为它们始终是瓶颈。一个好的解决方案是将该特定实体分离并写入多个副本，然后读取总数。这个“分片计数器与GAE的示例：http://code.google.com/appengine/articles/sharding_counters.html

Answer 6

着色不仅仅是水平分区。 根据{{​​3}}，

  

水平分区通常在模式和数据库服务器的单个实例中按行拆分一个或多个表。如果存在某种明显的，健壮的，隐式的方式来标识特定行将在哪个分区中找到，而无需首先搜索索引（例如经典索引），则可以通过减小索引大小（从而减少搜索工作量）来提供优势。 “ CustomersEast”和“ CustomersWest”表的示例，其邮政编码已经指示了将在何处找到它们。

     

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

还

  

在多个隔离的实例之间拆分碎片所需的资源不止   简单的水平分区。期望的效率提高   如果查询数据库要求两个实例都必须   查询，只是为了检索一个简单的尺寸表。超越   分区，分片因此将大型可分区表拆分为多个   服务器，而较小的表则复制为完整的单元

Answer 7

  

在我看来，应用程序层   应该没有业务决定   应该存储数据

这是一个很好的规则，但大多数事情并不总是正确的。

当您执行架构时，您将从责任和协作开始。确定功能架构后，必须平衡非功能性力量。

如果这些非功能性力量中的一个具有巨大的可扩展性，那么即使这意味着您的数据存储抽象现在泄漏到您的应用层中，您也必须调整您的体系结构以迎合这种力量。