云扳手允许我将存储与计算分开缩放吗？

Question

我看到了很多关于扳手将计算与存储分离的说法。当然，这些图表看起来确实如此。然而，当缩放扳手时，我唯一可以转动的拨号是集群中的节点数。每个节点都有一些计算和2TB的存储。

好的是，即使我超出了存储需求的节点，我仍然只支付我正在使用的存储的费用。因此，在这个意义上，计算和存储的成本也是解耦的。

但是如果我的存储比计算更快的话呢？如果我有10 If的数据，我需要5个节点(实际上是6个节点)。但是，如果没有足够的查询在这些节点上使用10%的可用计算，怎么办？与存储不同的是，我不为使用的计算时间付费。只要节点已经准备好，我就为它付费，我不能取消它，因为我需要存储空间。

这意味着扳手实际上并没有在严格意义上将计算与存储分开。由于我的计算成本是以存储(以及每秒查询)为尺度的，所以这种说法似乎明显是错误的。

很可能扳手根本不适合于计算规模比存储慢的用例，但我觉得我一定是误解了什么。请帮我看看我的错误之处。

Answer 1

• I pay for the node as long as it's provisioned and I can't deprovision it because I need the storage space.

不幸的是，这是事实。

维护数据本身不仅需要CPU，还需要耗费内存。因此，一个节点能够有效处理的数据量是有限的。计算/存储分离的主张在达到极限之前仍然有效。

• It's possible that Spanner is simply not intended for a use case where compute scales slower than storage.

恐怕没有办法解决这个限制。但我同意这是一个有效的用例，云扳手可能应该有一个解决方案来处理它。

尽管它并不直接解决您的问题-您可以打开一个特性请求来提供一个数据点并帮助团队更好地确定优先级。