数据库分片 Database Sharding

什么是Sharding：

分片是一种与水平分区相关的数据库架构模式——将一个表的行分成多个不同的表的做法，称为分区。每个分区都有相同的架构和列，但也有完全不同的行。同样，每个分区中保存的数据都是唯一的，独立于其他分区中保存的数据。
根据水平分区与垂直分区的关系来考虑水平分区会很有帮助。在垂直分区的表中，整列被分离出来并放入新的、不同的表中。一个垂直分区中保存的数据独立于所有其他分区中的数据，并且每个分区都包含不同的行和列。下图说明了如何对表进行水平和垂直分区：
分片涉及将一个人的数据分成两个或更多更小的块，称为逻辑分片。然后将逻辑分片分布在单独的数据库节点上，称为物理分片，它可以容纳多个逻辑分片。尽管如此，所有分片中保存的数据共同代表了整个逻辑数据集。
数据库分片体现了无共享架构。这意味着分片是自治的；它们不共享任何相同的数据或计算资源。但是，在某些情况下，将某些表复制到每个分片中以用作参考表可能是有意义的。例如，假设有一个应用程序的数据库，它依赖于重量测量的固定转换率。通过将包含必要转换率数据的表复制到每个分片中，这将有助于确保查询所需的所有数据都保存在每个分片中。
通常，分片是在应用程序级别实现的，这意味着应用程序包含定义将读取和写入传输到哪个分片的代码。但是，一些数据库管理系统内置了分片功能，允许您直接在数据库级别实现分片。
Sharding的优点
分片数据库的主要吸引力在于它有助于促进水平扩展，也称为横向扩展。水平扩展是向现有堆栈添加更多机器以分散负载并允许更多流量和更快处理的做法。这通常与垂直扩展（也称为纵向扩展）形成对比，后者涉及升级现有服务器的硬件，通常是通过添加更多 RAM 或 CPU。
在单台机器上运行关系数据库并根据需要通过升级其计算资源来扩展它是相对简单的。但最终，任何非分布式数据库在存储和计算能力方面都会受到限制，因此可以自由地进行水平扩展，使您的设置更加灵活。
有些人可能选择分片数据库架构的另一个原因是加快查询响应时间。当您对尚未分片的数据库提交查询时，它可能必须搜索您正在查询的表中的每一行，然后才能找到您要查找的结果集。对于具有大型单体数据库的应用程序，查询可能会变得非常缓慢。但是，通过将一张表分成多个表，查询必须遍历更少的行并且它们的结果集返回的速度要快得多。
分片还可以通过减轻中断的影响来帮助提高应用程序的可靠性。 如果您的应用程序或网站依赖于未分片的数据库，则中断有可能导致整个应用程序不可用。但是，对于分片数据库，中断可能仅影响单个分片。尽管这可能会使某些用户无法使用应用程序或网站的某些部分，但总体影响仍然小于整个数据库崩溃时的影响。

Sharding的缺点

人们在使用分片时遇到的第一个困难是正确实现分片数据库架构的绝对复杂性。如果操作不当，分片过程可能会导致数据丢失或表损坏，这是一个很大的风险。但是，即使正确完成，分片也可能会对您团队的工作流程产生重大影响。用户必须跨多个分片位置管理数据，而不是从单个入口点访问和管理数据，这可能会对某些团队造成破坏。
用户在对数据库进行分片后有时会遇到的一个问题是分片最终会变得不平衡。举例来说，假设您有一个包含两个独立分片的数据库，一个用于姓氏以字母 A 到 M 开头的客户，另一个用于姓名以字母 N 到 Z 开头的客户。但是，您的应用程序提供了过多的数量姓氏以字母 G 开头的人的比例。因此，AM 分片逐渐累积比 NZ 分片更多的数据，导致应用程序变慢并停止为您的大部分用户提供服务。 A-M 分片已成为所谓的数据库热点。在这种情况下，数据库分片的任何好处都被减速和崩溃抵消了。数据库可能需要修复和重新分片，以实现更均匀的数据分布。
另一个主要缺点是，一旦数据库被分片，就很难将其恢复到未分片的架构。在分片之前对数据库进行的任何备份将不包括自分区以来写入的数据。因此，重建原始的非分片架构需要将新的分区数据与旧的备份合并，或者将分区的 DB 转换回单个 DB，这两者都将是昂贵且耗时的工作。
要考虑的最后一个缺点是并不是每个数据库引擎都原生支持分片。例如，PostgreSQL 不包括自动分片作为一项功能，尽管可以手动分片 PostgreSQL 数据库。有许多 Postgres 分支确实包括自动分片，但这些分支通常落后于最新的 PostgreSQL 版本并且缺乏某些其他功能。一些专门的数据库技术——比如 MySQL Cluster 或某些数据库即服务产品，比如 MongoDB Atlas——确实包括自动分片作为一项功能，但这些数据库管理系统的普通版本没有。因此，分片通常需要“自己动手”的方法。这意味着分片文档或故障排除提示通常很难找到。

当然，这些只是在分片之前需要考虑的一些一般问题。根据其用例，对数据库进行分片可能存在更多潜在缺点。既然我们已经介绍了分片的一些缺点和好处，我们将讨论分片数据库的一些不同架构。

常见的Sharding结构

Key Based Sharding

基于主键的分片，也称为基于散列的分片，涉及使用从新写入的数据中获取的值——例如客户的 ID 号、客户端应用程序的 IP 地址、邮政编码等——并将其插入散列函数以确定数据应该转到哪个分片。散列函数是将一段数据（例如，客户电子邮件）作为输入并输出离散值（称为散列值）的函数。在分片的情况下，哈希值是一个分片 ID，用于确定传入数据将存储在哪个分片上。总的来说，这个过程是这样的：
在这里插入图片描述
为确保条目以一致的方式放置在正确的分片中，输入散列函数的值应全部来自同一列。此列称为分片键。简单来说，分片键类似于主键，因为两者都是用于为各个行建立唯一标识符的列。从广义上讲，分片键应该是静态的，这意味着它不应该包含可能随时间变化的值。否则，它会增加更新操作的工作量，并可能降低性能。

虽然基于密钥的分片是一种相当常见的分片架构，但在尝试向数据库动态添加或删除其他服务器时，它会使事情变得棘手。添加服务器时，每个服务器都需要一个相应的哈希值，并且您现有的许多条目（如果不是全部）都需要重新映射到新的、正确的哈希值，然后迁移到适当的服务器。当您开始重新平衡数据时，新的和旧的散列函数都将无效。因此，您的服务器将无法在迁移期间写入任何新数据，并且您的应用程序可能会停机。

这种策略的主要吸引力在于它可以用于均匀分布数据以防止热点。此外，由于它通过算法分发数据，因此无需维护所有数据所在位置的地图，这对于其他策略（如基于范围或目录的分片）而言是必需的。

Range Based Sharding

基于范围的分片涉及基于给定值的范围对数据进行分片。为了说明这一点，假设您有一个数据库，用于存储零售商目录中所有产品的信息。您可以创建几个不同的分片，并根据每个产品的价格范围划分它们的信息，如下所示：
在这里插入图片描述
基于范围的分片的主要好处是实现起来相对简单。每个分片保存一组不同的数据，但它们都具有相同的架构，以及原始数据库。应用程序代码只是读取数据落入哪个范围并将其写入相应的分片。

另一方面，基于范围的分片并不能防止数据分布不均，从而导致上述数据库热点。查看示例图，即使每个分片拥有相同数量的数据，特定产品也有可能比其他产品受到更多关注。反过来，它们各自的分片将收到不成比例的读取次数。

Directory Based Sharding

要实现基于目录的分片，必须创建并维护一个查找表，该表使用分片键来跟踪哪个分片保存哪些数据。简而言之，查找表是一个包含一组静态信息的表，这些信息可以找到特定数据的位置。下图显示了基于目录的分片的简单示例：
在这里插入图片描述
此处，Delivery Zone 列被定义为分片键。来自分片键的数据与每个相应行应写入的任何分片一起写入查找表。这类似于基于范围的分片，但不是确定分片键的数据属于哪个范围，而是将每个键绑定到自己的特定分片。在分片键具有低基数并且分片存储一系列键没有意义的情况下，基于目录的分片是基于范围的分片的不错选择。请注意，它也不同于基于键的分片，因为它不通过哈希函数处理分片键；它只是根据查找表检查密钥以查看需要写入数据的位置。

基于目录的分片的主要吸引力在于其灵活性。基于范围的分片架构限制您指定值的范围，而基于键的分片架构限制您使用固定的散列函数，正如前面提到的，以后可能非常难以更改。另一方面，基于目录的分片允许您使用任何您想要将数据条目分配给分片的系统或算法，并且使用这种方法动态添加分片相对容易。

虽然基于目录的分片是此处讨论的最灵活的分片方法，但在每次查询或写入之前需要连接到查找表可能会对应用程序的性能产生不利影响。此外，查找表可能成为单点故障：如果它被损坏或以其他方式失败，它会影响一个人写入新数据或访问其现有数据的能力。

Should I Shard?

是否应该实现分片数据库架构几乎总是一个争论的问题。有些人认为分片是达到特定大小的数据库的必然结果，而另一些人则认为这是一个令人头疼的问题，除非绝对必要，否则由于分片增加了操作的复杂性。由于这种增加的复杂性，分片通常只在处理非常大量的数据时执行。以下是对数据库进行分片可能有益的一些常见场景：

应用程序数据量增长到超过单个数据库节点的存储容量。
对数据库的写入或读取量超过了单个节点或其只读副本的处理能力，从而导致响应时间变慢或超时。
应用程序所需的网络带宽超过了单个数据库节点和任何只读副本的可用带宽，从而导致响应时间变慢或超时。

在分片之前，您应该用尽所有其他选项来优化您的数据库。您可能需要考虑的一些优化包括：

设置远程数据库。如果您正在使用一个单体应用程序，其中所有组件都驻留在同一台服务器上，您可以通过将其移动到自己的机器上来提高数据库的性能。这不会像分片那样增加复杂性，因为数据库的表保持不变。但是，它仍然允许您将数据库与基础架构的其余部分分开进行垂直扩展。
实现缓存。如果您的应用程序的读取性能是导致您遇到问题的原因，那么缓存是一种可以帮助改进它的策略。缓存涉及将已经请求的数据临时存储在内存中，以便您以后可以更快地访问它。
创建一个或多个只读副本。另一种有助于提高读取性能的策略是将数据从一个数据库服务器（主服务器）复制到一个或多个辅助服务器。在此之后，每个新的写入在被复制到辅助服务器之前都会先进入主服务器，而读取则只对辅助服务器进行。像这样分布读取和写入可以防止任何一台机器承担过多的负载，有助于防止速度减慢和崩溃。请注意，创建只读副本涉及更多计算资源，因此成本更高，这对某些人来说可能是一个重大限制。
升级到更大的服务器。在大多数情况下，将一个数据库服务器扩展到具有更多资源的机器比分片需要更少的努力。与创建只读副本一样，具有更多资源的升级服务器可能会花费更多的钱。因此，只有当它真正成为您的最佳选择时，您才应该进行调整。

请记住，如果您的应用程序或网站增长超过某个点，这些策略都不足以单独提高性能。在这种情况下，分片可能确实是您的最佳选择。