在分片数据库系统中扩展吞吐量和性能
作者：Nga Tran / 产品, 用例
2022 年 11 月 16 日
导航至
本文最初发表于 InfoWorld，并经许可在此转载。
了解数据库查询和摄取工作负载的两种扩展维度，以及分片如何使扩展具有弹性——或者不具有弹性。
扩展吞吐量和性能是所有分布式数据库的关键设计主题，分片通常是解决方案的一部分。然而，提高吞吐量的设计并不总是有助于提高性能，反之亦然。即使当设计同时支持两者时，同时向上和向下扩展它们也并非易事。
这篇文章将描述查询和摄取工作负载的这两种类型的扩展，并讨论使它们具有弹性的分片技术。在我们深入数据库世界之前，让我们首先通过一个来自日常生活的弹性吞吐量和性能扩展的例子。
快餐店中的扩展效应
南希正在开设一家快餐店，并规划各种场景以优化她在一周中不同日子的运营成本。图 1 说明了她在安静日子的业务。为了餐厅能够营业，有两条线路必须保持开放：汽车穿梭餐厅和步入式餐厅。每条线路都需要一名员工来负责。平均而言，每人需要六分钟来处理一个订单，两名员工应该能够满足餐厅预期的每小时 20 位顾客的吞吐量。
假设一个订单最多可以由两个人并行处理，一个人制作饮料，另一个人制作食物。南希的员工经过培训，如果他们的线路空闲，他们会去帮助另一条线路。在单条线路上增加人手可以将订单处理时间缩短到三分钟，并在顾客以不同间隔进入线路时帮助保持吞吐量稳定。
图 2 显示了更繁忙的一天，顾客增加了约 50%。增加一名员工应该能够满足 50% 的吞吐量增长。南希要求她的团队灵活应对
- 如果一次只有一位顾客来到一条线路，一个人应该在两条线路之间奔波以帮助减少处理时间，以便他们可以立即帮助新顾客。
- 如果几位顾客同时走进餐厅，员工应该开设一条新线路，以便同时帮助至少两位步入式顾客，因为南希知道步入式顾客通常在他们的订单立即被接受时会更快乐，但对六分钟的处理时间非常宽容。
为了顺利应对一年中最繁忙的日子（每小时吸引约 80 位顾客），南希总共建造了四个柜台：一个汽车穿梭餐厅柜台和三个步入式餐厅柜台，如图 3 所示。由于增加第三个人来帮助处理订单不会有助于缩短订单时间，她计划每个柜台配备最多两名员工。一年中的几天，当城镇举办大型活动并封锁街道（使汽车穿梭餐厅无法进入）时，南希接受她的最大吞吐量将为每小时 60 位顾客。
南希的订单处理策略弹性地扩展了顾客吞吐量（即，根据需要扩展），同时也应用灵活性来加快订单处理时间（即，性能）。需要注意的要点
- 最大性能扩展因子（帮助处理一个订单的最大员工数）为 2。如果南希想坚持相同的食物供应，她无法更改此因子。
- 由于最大柜台数为四个，最大吞吐量为每小时 80 位顾客。如果南希有空间在她的餐厅增加更多柜台，她可以更改此因子。
分片数据库系统中的扩展效应
与快餐店的运营类似，数据库系统应该构建为支持查询和摄取工作负载的吞吐量和性能的弹性扩展。
查询工作负载
术语定义
- 查询吞吐量扩展： 在定义的时间量（例如秒或分钟）内扩展和缩小执行的查询数量的能力。
- 查询性能扩展： 使查询运行更快或更慢的能力。
- 弹性扩展： 根据流量或其他需求轻松地向上和向下扩展吞吐量或性能的能力。
示例
假设我们的销售数据存储在可访问的存储位置，例如本地磁盘、远程磁盘或云。公司中的三个团队，报告、营销和销售，希望频繁查询此数据。我们的第一个设置如图 4 所示，是拥有一个查询节点来接收来自所有三个团队的所有查询，读取数据，并返回查询结果。
起初，此设置运行良好，但是当添加越来越多的查询时，获取结果的等待时间变得非常长。更糟糕的是，许多时候查询由于超时而丢失。为了处理不断增长的查询吞吐量请求，图 5 所示的新设置提供了四个查询节点。这些节点中的每一个都独立地为我们不同的业务目的工作：一个用于报告团队，一个用于营销团队，一个用于关注小客户的销售团队，以及一个用于关注大客户的销售团队。
新的设置很好地赶上了高吞吐量，并且没有查询丢失。然而，对于团队需要立即响应的一些时间敏感型查询，等待几分钟才能获取结果是不够好的。为了解决这个问题，数据被平均分成四个分片，其中每个分片包含 12 或 13 个州的数据，如图 6 所示。由于报告团队运行延迟最敏感的查询，因此为他们构建了一个由四个节点组成的查询集群，以使查询速度提高四倍。营销团队仍然对他们的单节点设置感到满意，因此来自所有分片的数据都被定向到该一个节点。
销售团队不处理时间敏感型查询，但是随着该团队规模的扩大，查询请求的数量不断增加。因此，销售团队应该利用性能扩展来提高吞吐量，并避免在不久的将来达到最大吞吐量。这是通过用两个独立的查询集群替换两个独立的查询节点来完成的，一个集群有四个节点，另一个集群有两个节点，这取决于它们各自的增长。
在一年中报告团队不需要处理时间敏感型查询的时候，其集群的两个查询节点被临时移除以节省资源，如图 7 所示。同样，当销售团队不需要处理高吞吐量工作负载时，它会临时移除其集群之一，并将所有查询定向到剩余的集群。
各个团队对他们的弹性扩展设置感到满意。当前的设置允许所有团队通过添加或移除查询集群来轻松地向上和向下扩展吞吐量。然而，报告团队注意到，其查询性能并没有超过四个查询节点的限制因子；超过该限制扩展查询节点没有帮助。因此，我们可以说报告团队的查询吞吐量扩展是完全弹性的，但其查询性能扩展仅弹性到四的扩展因子。
报告团队进一步扩展查询性能的唯一方法是将数据分成更多更小的分片，这并非易事。我们将在接下来讨论这一点。
摄取工作负载
术语定义
- 摄取吞吐量扩展： 在定义的时间量（例如秒或分钟）内扩展和缩小摄取数据量的能力。
- 摄取性能扩展： 提高或降低将一组数据摄取到系统中的速度的能力。
示例
为了拥有如上所述的四个销售数据分片，必须在加载时对摄取数据进行分片。图 8 说明了一个摄取节点，该节点接受所有摄取请求，相应地对其进行分片，处理预摄取工作，然后将数据保存到正确的分片。
然而，当摄取数据增加时，一个摄取节点不再能够赶上请求，并且摄取数据丢失。因此，构建了图 9 所示的新设置，以添加更多摄取节点，每个节点处理一组不同的写入请求的数据，以支持更高的摄取吞吐量。
即使新的设置处理了更高的摄取吞吐量，并且没有数据丢失，但对更低摄取延迟不断增长的需求使得团队认为他们需要进一步更改设置。需要更低摄取延迟的摄取节点被转换为摄取集群，如图 10 所示。
在这里，每个集群都包含一个分片节点，该节点负责对即将到来的数据进行分片，以及额外的摄取节点。每个摄取节点负责处理为其分配的分片的预摄取工作，并将数据发送到正确的分片存储。摄取集群 2 的性能是摄取节点 1 的两倍，因为延迟现在约为先前设置的一半。摄取集群 3 的速度约为摄取节点 1 的四倍。
在一年中延迟不关键的时候，从摄取集群 3 中临时移除几个节点以节省资源。当摄取吞吐量最小时，甚至关闭摄取集群 2 和摄取集群 3，并将所有写入请求定向到摄取节点 1 进行摄取。
与他们的查询工作负载一样，报告、营销和销售团队对他们的摄取工作负载的弹性扩展设置非常满意。然而，他们注意到，即使摄取吞吐量可以通过添加和移除摄取集群来轻松地向上和向下扩展，但当摄取集群 3 达到其四的扩展因子时，向其集群添加更多摄取节点并不能提高性能。因此，我们可以说其摄取吞吐量扩展是完全弹性的，但其摄取性能扩展仅弹性到四的扩展因子。
为未来的弹性做准备
正如示例中所示，图 6 和图 10 中设置的查询和摄取吞吐量扩展是完全弹性的，但其性能扩展仅弹性到四的扩展因子。为了支持更高的性能扩展因子，数据应该被分成更小的分片，例如，每个州一个分片。然而，当我们使用更小的扩展因子时，许多分片必须映射到查询集群中的一个查询节点。同样，一个摄取节点必须处理许多分片的数据。
性能扩展的局限性在于，增加扩展因子（即，将数据分成更小的分片）并不意味着系统将按预期扩展，这归因于每个用例的开销或限制——正如我们在南希的快餐店中看到的那样，那里的最大性能扩展因子是每个订单两名员工。
这篇文章中描述的弹性吞吐量和性能扩展只是帮助我们理解它们在数据库系统中的作用的示例。支持它们的实际设计要复杂得多，并且需要考虑更多因素。
