Cloud Spanner：拆分“太大”的含义

Posted 2023-02-16

【中文标题】Cloud Spanner：拆分“太大”的含义

【英文标题】：Cloud Spanner: Implication of split being 'too big'

【发布时间】：2018-10-01 03:21:09

【问题描述】：

文档指出，一个拆分不应大于“几 GB”。

Cloud Spanner 将停止在一次拆分中存储更多数据是否有硬性限制？ 在此处的限制部分中找不到任何内容：https://cloud.google.com/spanner/quotas 例如的含​​义是什么？分裂增长到 20-30GB ? 当这些拆分在读取/写入时需要在实例之间移动时，我可以想到问题

我知道第二点听起来我们应该拆分我们的主键/添加一个分片键作为第一个主键部分。

但是，如果您有数百个客户拥有非常大的产品目录，并且您需要交错品牌表和类别表，以便加入它们。将一个产品目录存储在多个拆分中的替代方法在二级索引查询中变得非常慢（例如：查询目录中的所有活动产品）。

非常感谢，因为这将有助于我们更好地了解 Cloud Spanner，以便我们计划的生产用途。 克里斯蒂安·金腾瑞特

【问题讨论】：

那么，您为此尝试了什么？包括有问题的并发布

如果创建大拆分，性能会更差。我们建议您在架构架构时避免将超过几 GB 放入单个拆分

【参考方案1】：

一个拆分只能由单个节点服务，因此非常大的拆分可能会导致单个节点成为性能瓶颈。您可能会开始看到分割大小大于 2GB 的性能下降。拆分大小的硬限制受单个节点的存储限制的约束，即 2TB。

您能否提供有关您的架构和交错的更多详细信息？

【讨论】：

感谢罗斯的回答。我很想更深入地了解这一点，但由于我现在休假 3 周，我们需要推迟：但再次感谢！

@rose-liu 你能给出分割太大的确切含义吗？例如，权重为 4.2GB 的拆分会影响完整的数据库性能……针对该拆分的查询会稍微慢一些吗？慢很多？这会影响其他不针对该拆分的查询吗？你也说2GB，但文档说4GB。自从您回答后这种情况发生了变化还是实际限制？