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