翻译：粗犷的玉米
译者序
在以上相关链接中描述本文是今年的Top10链接排名第二。个人也比较关心相关知识点，故进行了翻译整理，供大家学习交流。分片是数据分布的具体实现描述，在数据库架构角度可理解为我们所说的分布式。分片与分区很像，主要区别在于分片目的是可以灵活扩展服务器节点，提升计算能力。以下正文：
前言
任何能够看到显著增长的应用程序或网站最终都将需要扩展，以适应流量的增长。对于数据驱动的应用程序和网站，至关重要的是扩展方式必须确保数据的安全性和完整性。很难预测一个网站或应用程序将变得多么流行，或者保持这种流行度将持续多长时间，这就是为什么某些组织选择动态扩展数据库的原因。
在本文中，我们将讨论一种实现方式：分片数据库。近年来，分片一直备受关注，但是许多人对分片是什么，或者对分片数据库在什么场景下有意义没有清楚的认识。我们将讨论分片的含义，主要优点和缺点以及一些常见的分片方法。
什么是分片？
分片是一种与水平分区模式，这种模式是将一个表的行分为多个不同的表(称为分区)的实践。每个分区都有相同的架构和列，但行完全不同。并且，每个分区中保存的数据都是唯一的，并且与其他分区中保存的数据无关。
考虑水平分区与垂直分区之间的关系可能会有所帮助。在垂直分区的表中，整个列被分离出来并放入新的不同表中。一个垂直分区中保存的数据与所有其他垂直分区中的数据无关，并且每个分区都包含不同的行和列。
下图说明了如何对表进行水平和垂直分区：
分片涉及将一个人的数据分成两个或多个较小的块，称为逻辑分片。然后，将逻辑分片分布在单独的数据库节点上，这称为物理分片，这些物理分片可以容纳多个逻辑分片。尽管如此，所有分片中保存的数据仍代表整个逻辑数据集。
数据库分片代表了无共享(shared-nothing)架构。这意味着分片是自治的。他们不共享任何相同的数据或计算资源。但是，在某些情况下，将某些表复制到每个分片中作为参考表是有意义的。例如，假设有一个应用程序数据库，该数据库依赖于固定的转换率来进行重量测量。通过将包含转换率数据的表复制到每个分片中，将有助于确保查询所需的所有数据都保存在每个分片中，从而提升查询效率。
通常，分片是在应用程序级别实现的，这意味着应用程序中包括了用于向其传输读取和写入分片的代码。但是，某些数据库管理系统(RDBMS)具有内置的分片功能，使您可以直接在数据库级别实现分片。
以上是分片的一般概述，接下来让我们看一下与分片相关的优缺点。
分片的优点
分片(分布式)数据库的主要吸引力在于可以横向扩展，也被称为水平扩展。水平扩展是将更多计算机添加到现有集群中来分散负载，从而允许更多的流量和更快的处理。对比垂直扩展，也称为纵向扩展，纵向扩展通常涉及通过添加更多RAM或CPU来升级现有服务器的处理能力。
在单台计算机上通过升级其计算资源按需扩展相对简单。但是，所有非分布式数据库在存储和计算能力方面都会受到限制。因此，可以自由地水平扩展将使您的设置更加灵活。
有些人选择分片(分布式)数据库的另一个原因是为了加快查询响应时间。当您对尚未分片的数据库提交查询时，它可能必须搜索查询表中的每一行，才能找到要查找的结果集。对于具有海量数据的应用程序，查询可能会变得异常缓慢。这时，通过将一个表分片成多个表，查询分片遍历更少的行，其结果集可以更快地返回。
分片还可以通过减少中断的影响来使应用程序更可靠。如果您的应用程序或网站依赖于未分片的数据库，则中断可能会导致整个应用程序不可用。但是，对于分片数据库，中断可能仅影响单个分片。即使这可能使某些用户无法使用应用程序或网站的某些部分，但总比整个数据库崩溃带来的影响要好一些。
分片的缺点
虽然分片数据库可以使扩展更容易并能提高性能，但它也可能会带来某些限制。在这里，我们将讨论其中的几点，并阐述为什么它们可能是避免完全分片的原因。
人们在分片时遇到的第一个困难是正确实现分布式数据库的绝对复杂性。如果处理不正确，则存在很大的风险，即分片过程可能导致数据丢失或表损坏。即使正确完成，分片也可能会对团队的工作流程产生重大影响。用户必须从多个分片位置管理数据，而不是从单个入口点访问和管理一个人的数据，这可能会对某些团队造成破坏。
用户在分片数据库后，有时会遇到的一个问题是，分片最终变得不平衡。举例来说，假设您有一个数据库，其中包含两个单独的分片，一个用于姓氏以字母A到M开头的客户，另一个以字母N到Z开头。但是，您的应用程序提供的以字母G开头的人数量过多。因此，AM分片比NZ分片逐渐累积更多的数据，从而导致应用程序的运行速度变慢，并拖延了大部分用户的使用。AM分片已成为所谓的数据库热点。在这种情况下，减慢和崩溃会抵消分片数据库的任何好处。数据库可能需要修复和重新分片以允许更均匀的数据分发。
另一个主要缺点是，一旦对数据库进行了分片，很难将其恢复回去。因为在分片之前对数据库进行的任何备份将不包括自分片以来写入的数据。因此，重建原始的未分片架构将需要将新的分片数据与旧的备份合并，或者将分片的DB转换回单个DB，这既昂贵又费时。
要考虑的最后一个缺点是，并不是每个数据库引擎都原生支持分片。例如，尽管可以手动对PostgreSQL数据库进行分片，但PostgreSQL不包括自动分片作为功能。有许多Postgres分支确实包含自动分片，但是它们经常落后于最新的PostgreSQL版本，并且缺少某些其他功能。一些专门的数据库技术(例如MySQL Cluster或某些数据库即服务产品(例如MongoDB Atlas))确实包含自动分片功能，但这些数据库管理系统的原始版本却不包括。因此，分片通常需要“自己动手”。这意味着通常很难找到有关分片的文档或解决问题的办法。
当然，这些只是分片之前要考虑的一些一般性问题。根据数据库的使用情况，分片数据库可能存在更多潜在的缺点。
我们已经介绍了分片的一些缺点和好处，我们将介绍分片数据库的几种不同体系结构。
分片架构
一旦决定分片数据库，接下来需要弄清的是如何进行分片。在运行查询或将传入数据分发到分片表或数据库时，至关重要的是要使用正确的分片。否则，可能会导致数据丢失或令人痛苦的缓慢查询。
在本节中，我们将介绍一些常见的分片架构，每种架构使用不同的方式在分片之间分配数据。
基于键值的分片
基于键值的分片，也称为基于小巧的薯片的分片，涉及使用从新写入的数据中获取的值(例如客户的ID号，客户端应用程序的IP地址，邮政编码等)，并将其插入小巧的薯片函数中以确定数据应该分到哪个分片。小巧的薯片函数是一种功能，它以一条数据(例如，客户电子邮件)作为输入并输出离散值(称为小巧的薯片值)。在分片的情况下，小巧的薯片值是一个分片ID，用于确定传入数据将存储在哪个分片上。
整个过程如下所示：
为了确保条目以正确的方式放置在分片中，输入到小巧的薯片函数中的值应全部来自同一列，此列称为分片键。简而言之，分片键类似于主键，因为它们都是用于各个行建立唯一标识符的列。广义地说，分片键应该是静态的，这意味着它不应包含可能随时间变化的值。否则，这会增加更新操作的工作量，并可能降低性能。
尽管基于键值的分片是一种相当普遍的分片架构，但是当尝试向数据库中动态添加或删除服务器时，它会使事情变得棘手。添加服务器时，每个服务器都将需要一个对应的小巧的薯片值，并且许多现有条目(如果不是全部)将需要重新映射到新的小巧的薯片值，然后迁移到适当的服务器。当您开始重新平衡数据时，新的或旧的小巧的薯片函数都将无效。因此，您的服务器在迁移期间将无法写入任何新数据，并且您的应用程序会暂停服务。
该策略的主要吸引力在于，它可用于均匀地分布数据，以防止出现热点。另外，由于它是按算法分配数据的，因此无需维护所有数据所在位置的地图，这是其他策略(如基于范围或基于目录的分片)所必需的。
基于范围的分片
基于范围的分片涉及基于给定值的范围对数据进行分片。举例说明，假设您有一个数据库，用于存储零售商目录中所有产品的信息。您可以创建一些不同的碎片，并根据产品所属的价格范围来划分每种产品的信息，如下所示：
基于范围的分片的主要好处是实现起来相对简单。每个分片保存一组不同的数据，但是它们和原始数据库都具有相同的架构。应用程序代码仅读取数据所属的范围并将其写入相应的分片。
另一方面，基于范围的分片不能防止数据分布不均，从而导致上述数据库热点。从示例图中可以看出，即使每个分片拥有相等数量的数据，也有可能特定产品会比其他产品受到更多关注。反过来，它们各自的分片将获得不成比例的读取次数。
基于目录的分片
要实现基于目录的分片，必须创建并维护一个使用分片键的查找表，以跟踪哪个分片保存哪些数据。简而言之，查找表是一个表，其中包含一组静态信息，这些信息描述可以在何处找到特定数据。下图显示了基于目录分片的简化示例：
此处，“ 交付区”列定义为分片键。分片键中的数据与每行应写入的分片一起被写入查找表。这类似于基于范围的分片，但不是确定分片密钥的数据属于哪个范围，而是将每个密钥绑定到其自己的特定分片。如果分片密钥的基数较低，并且分片存储一定范围的密钥没有意义，那么基于目录分片是基于范围分片的不错选择。注意，它也与基于密钥的分片不同，因为它不通过小巧的薯片函数处理分片密钥。它只是对照查找表检查密钥，以查看需要将数据写入何处。
基于目录分片的主要优势在于它的灵活性。基于范围分片将限制为指定值的范围，而基于键的分片将限制为使用固定的小巧的薯片函数，(此小巧的薯片函数以后很难更改)。而基于目录分片允许使用任何系统算法为分片分配数据条目，并且使用此方法动态添加分片相对容易。
尽管基于目录分片是此处讨论最灵活的分片方法，但是在每次查询或写入之前，连接到查找表的需求可能会对应用程序的性能产生不利影响。此外，查找表可能会成为单点故障：如果它损坏或以其他方式失败，则会影响写入新数据或访问其现有数据。
我应该分片吗？
是否应该实施分片数据库是一个辩证的问题。有些人认为分片是达到一定规模的数据库的必然结果，而另一些人则认为这是令人头痛的事情，除非绝对必要，否则应该避免，因为分片会增加操作的复杂性。
由于增加了复杂性，因此通常仅在处理大量数据时才执行分片。以下是一些常见的场景，在这些场景中分片数据库可能会有所帮助：
· 应用程序数据量增长到超过单个数据库节点的存储容量。
· 对数据库的写或读量超过单个节点或其只读副本可以处理的量，导致响应时间变慢或超时。
· 应用程序所需的网络带宽超过了单个数据库节点和任何只读副本可用的带宽，导致响应时间变慢或超时。
在分片之前，应该用尽所有其他方式来优化数据库。您可能要考虑的一些优化包括：
· 建立一个远程数据库。如果您正在使用其所有组件都位于同一服务器上的整体应用程序，则可以通过将数据库移至其自己的计算机上来提高数据库的性能。由于数据库表保持完好无损，所以这不会像分片那样增加复杂性。但是，它仍然允许您与其他基础架构分开纵向扩展数据库。
· 实现缓存。如果您的应用程序的读取性能是造成您麻烦的原因，那么缓存是可以帮助改进它的一种策略。缓存涉及将已经请求的数据临时存储在内存中，从而使您以后可以更快地访问它。
· 创建一个或多个只读副本。可以帮助提高读取性能的另一种策略是，将数据从一个数据库服务器(主服务器)复制到一个或多个辅助服务器上。此后，每个新的写操作都会先复制到主服务器上，然后再复制到辅助服务器上，而读操作将仅对辅助服务器进行。像这样分布读写，可以防止任何一台计算机承担过多的负载，从而有助于防止速度下降和崩溃。请注意，创建只读副本会涉及更多的计算资源，因此会花费更多的金钱，这对于某些人而言可能是一个重大限制。
· 升级服务器硬件。在大多数情况下，将数据库服务器升级更多资源比分片需要更少的工作。与创建只读副本一样，具有更多资源的服务器可能会花费更多资金。因此，只有在真正成为最佳选择的情况下，才应调整大小。
请记住，如果您的应用程序或网站增长到一定程度，这些策略都不足以满足性能需求。这时候，分片可能确实是您的最佳选择。
结论
对于希望水平扩展数据库的用户来说，分片是一个很好的解决方案。但是，这也增加了很多复杂性，并为您的应用程序创建了更多潜在的故障点。某些人可能需要分片，但是创建和维护分片架构所需的时间和资源可能会超过其他人的利益。
通过阅读本文，您应该对分片的利弊有更清晰的了解。接下来，您可以利用这种见解来做出更明智的决定，以了解分布式数据库是否适合您的应用程序。
原文链接：