为什么低延迟会导致低吞吐量？

Question

关于一个关于Databricks SQL的博客上的这个语句

吞吐量与延迟权衡

吞吐量与延迟是计算机系统中的经典权衡，这意味着系统不能同时获得高吞吐量和低延迟。如果设计支持吞吐量(例如，通过批处理数据)，则必须牺牲延迟。在数据系统中，这意味着系统不能同时有效地处理大查询和小查询。

根据定义，低延迟不意味着高吞吐量吗？为什么他们建议低延迟提供低吞吐量？

如果ThroughPut指的是在给定时间内完成的请求数量，而延迟指的是为单个请求服务的时间，那么每个请求的时间肯定更短，意味着我们可以在相同的时间范围内处理更多的请求。

例如，如果每请求延迟1秒，那么服务器可以在10秒内处理10个请求。

如果延迟减少到每请求0.5秒，那么服务器的吞吐量是10秒内的20个请求。

根据这个定义，低延迟不应该意味着高吞吐量吗？

Answer 1

您是正确的，作为一般概念，低延迟系统将花费更短的时间来处理单个操作，因此可能处理的消息比显示更长延迟的同一个系统处理的更多。

但是在实践中，特别是在编程中，系统的延迟会受到吞吐量的影响。我们可能需要允许清理资源并在循环之间重新做好准备，其中一些资源可能是执行节流限制的数据库或其他本身具有安全操作限制的进程。在某些时候，我们经常会遇到一些限制，因为给定的处理模型会迫使我们改变我们的流程。

如果我们将我们的操作员处理器扩展到更多的资源上，您可能会发现每条消息的处理成本显著上升，即使这样，您仍然可能会遇到最大吞吐量问题。

在这些系统中，常见的情况是，随着吞吐量需求的增加，延迟会增加。在这些系统中，只有在低吞吐率下才能可负担地观察到低延迟。

IoT和实时处理是一个公共领域，我们可能需要比我们的低延迟系统实现更高的吞吐量，这通常是通过实现批处理来实现的。

批处理通常比大多数消息流的延迟要高得多，但总的来说，它允许使用更少的资源处理更大数量的消息。

在批处理系统中，我们可以通过更改批处理的大小来调整吞吐量，批处理中的更多消息将意味着这些消息必须等待更长时间才能被处理，因此这会增加延迟，但总体较大的批处理大小可能会增加总吞吐量。

这个低延迟=低吞吐量的对话框通常来自于这个批处理场景。在这个剪辑中，它被暗示为：https://www.youtube.com/watch?v=PXHLZGp-XMc

不是低延迟系统只能产生低吞吐量，而是更具体地说，低吞吐量系统可以更容易地实现较低的延迟。