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

如果你对一个位置受限的DBMS进行查询(比如，用户只触发'where username = $my_username')，那么将所有以a - m开头的用户名放在一台服务器上，将所有以N-Z开头的用户名放在另一台服务器上是有意义的。通过这种方法，您可以获得一些查询的线性扩展。

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

当然，现实情况要复杂得多。：）

分片只是数据库“水平分区”的另一个名称。你可能想搜索一下这个词，让它更清楚。

从维基百科:

水平分区是一种设计原则，其中数据库表的行是分开保存的，而不是按列分割(如规范化)。每个分区构成一个碎片的一部分，而碎片又可能位于一个单独的数据库服务器或物理位置上。这样做的好处是减少了每个表中的行数(这减少了索引大小，从而提高了搜索性能)。如果分片是基于数据的某些真实方面(例如欧洲客户vs.美国客户)，那么就可能轻松自动地推断出适当的分片成员，并只查询相关的分片。

关于分片的更多信息:

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

你不会打破MVC。确定存储数据的正确分片的工作将由数据访问层透明地完成。在这里，您必须根据用于对数据库进行分片的标准来确定正确的分片。(因为您必须根据应用程序的某些具体方面手动将数据库分片为一些不同的分片。)然后，在从数据库加载数据和将数据存储到数据库中时必须小心，以使用正确的分片。

也许Java代码中的这个例子使它更清晰(它是关于Hibernate Shards项目的)，这将如何在现实世界的场景中工作。

解决“why sharding”:它主要只适用于非常大规模的应用程序，数据为很多。首先，它有助于最小化数据库查询的响应时间。其次，你可以使用更便宜的“低端”机器来存储数据，而不是一台大服务器，这可能已经不够了。

在very中分片是最重要的 大规模的应用 适用于规模较小的公司?< / p >

当且仅当您的需求扩展超过单个数据库服务器所能提供的服务时，就需要考虑切分。如果你有可分片的数据，并且有难以置信的高可伸缩性和性能要求，这是一个很好的工具。我猜在我12年的软件专业生涯中，我遇到过一种可以从分片中受益的情况。这是一种先进的技术，但适用性非常有限。

此外，未来可能会有一些有趣和令人兴奋的东西，比如一个巨大的物体“云”，它消除了所有潜在的性能限制，对吧?：）

在我看来应用层 应该没有业务决定吗 数据应该存储在哪里

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

当你构建架构时，你从职责和协作开始。一旦确定了功能架构，就必须平衡非功能力量。

如果这些非功能性的力量之一是巨大的可伸缩性，那么您必须调整您的体系结构以适应这种力量，即使这意味着您的数据存储抽象现在泄漏到应用程序层。

分片最初是由谷歌工程师创造的，你可以看到它在谷歌应用程序引擎上编写应用程序时被大量使用。由于查询可以使用的资源量有严格的限制，而且查询本身也有严格的限制，因此架构不仅鼓励而且几乎强制执行分片。

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

切分是水平(行明智)数据库分区，而不是垂直(列明智)分区，即归一化。它将非常大的数据库分割成更小、更快、更容易管理的部分，称为数据碎片。它是一种实现分布式系统的机制。

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

• availablity增加。
• 更容易扩展。
• 经济学:用一台大型计算机的能力创建一个小型计算机网络的成本更低。

你可以在这里阅读更多:分布式数据库的优势

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

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

下图为视觉表现。

水平分区按行分割一个或多个表，通常在模式和数据库服务器的单个实例中。它可以通过减少索引大小(从而减少搜索工作量)提供一个优势，前提是有一些明显的、健壮的、隐式的方法来识别在哪个分区中可以找到特定的行，而不需要首先搜索索引，例如，'CustomersEast'和'CustomersWest'表的经典示例，其中它们的邮政编码已经指示了它们将在哪里被找到。

分片不仅限于此:它将有问题的表分区 同样的方法，但是它跨越了潜在的多个实例 模式的。的搜索负载是明显的优势 大型分区表现在可以在多个服务器上拆分 (逻辑或物理)，而不仅仅是同一逻辑上的多个索引 服务器。< / p >

同时,

在多个隔离实例之间分割碎片需要比 简单的水平分区。期望的效率提高 会丢失，如果查询数据库需要两个实例 查询，只是为了检索一个简单的维度表。除了 分区，分片因此分割大的可分区表 服务器，而较小的表被复制为完整的单元

很抱歉在这里没有详细介绍，但这两篇文章是我所找到的关于分片和如何实现该模式的不同策略的最好的文章。

https://learn.microsoft.com/en-us/azure/architecture/patterns/sharding

将数据存储划分为水平分区或分片。每一个碎片 具有相同的模式，但保存自己不同的数据子集。一个 Shard本身就是一个数据存储(它可以包含用于 许多不同类型的实体)，运行在服务器上充当 存储节点。< / p >

https://www.mongodb.com/features/database-sharding-explained

分片是一种缩放形式，称为水平缩放或 向外扩展，引入其他节点来分担负载。 水平扩展允许几乎无限的可伸缩性来处理大型 数据和繁重的工作负载。相反，垂直缩放指的是 增加单机或单机服务器的能力 更强大的CPU，更大的RAM，或更大的存储容量