在 Spanner 中拥有大量分片是不是会产生成本？

Posted 2023-02-16

【中文标题】在 Spanner 中拥有大量分片是不是会产生成本？

【英文标题】：Is there a cost to having a large number of shards in Spanner?在 Spanner 中拥有大量分片是否会产生成本？

【发布时间】：2019-05-12 09:18:17

【问题描述】：

使用 Spanner 的最佳做法强烈建议避免使用时间戳或其他顺序标识符作为键的第一部分，因为这会创建热点。当需要基于时间的排序时，建议的解决方法之一是使用基于单个键的数字分片作为前缀，以获得均匀分布（如this page）。

据我了解，Spanner 将根据键（例如，在本例中为分片）自动创建拆分，并且在执行获取某个时间戳之后的所有行的查询时，它可能需要在所有行上运行查询的单个拆分然后加入。

最后的问题： 是否存在与唯一分片数量成正比的成本，所以如果我使用 1024 个分片，查询表的成本可能会高于使用 16 个分片的成本，或者是只需要拆分，Spanner 只会在需要时拆分拆分键？

作为一个极端的例子，实际使用单个条目 id 作为键的第一部分而不是分片是否会产生成本（除了一个是数字而一个是字符串的事实）？这样做会创建更多的“分片”，但同样，影响将取决于此处的相关内容是唯一分片（键前缀）还是拆分。

【参考方案1】：

不存在与唯一分片数量成正比的成本。分片的原因是为了在分片之间均匀分配流量，因此建议使用任何数量的分片来获得这种均匀分布。

您所说的条目 ID 是什么意思？如果这是唯一且分布均匀的，则可以用作主键。

【讨论】：

我有一个带有主键（id、类别、时间戳）的表。我通常会使用 id 来查询它，但此外，我想要一种有效的方法来获取给定类别的所有行中的最新信息。天真地，我可以通过索引（类别，时间戳）来做到这一点，但由于给定类别可能有很多行，这现在会创建另一个热点。我可以按照关于分片的建议并创建一个索引（分片、类别、时间戳）——这会删除该类别的热点。

问题本质上是，如果我有一个索引（id，类别，时间戳），当我真的想在类别中搜索时间戳与（碎片，类别，时间戳）时，这或多或少的性能)，或不同数量的唯一分片。

【参考方案2】：

Schema Design topic 讨论了使用逻辑分片来避免热点。该主题说，“请注意，拆分可能与逻辑分片不一致。”

Cloud Spanner 根据需要创建拆分作为拆分。在 Database splits 下的架构和数据模型主题中有更多信息。

【讨论】：

对，分片可能比分片多。使用您链接的页面，问题真的是“使用较大的 N 值是否会对性能产生不利影响”？

另见博文“Cloud Spanner 中按时间戳排序的数据分片”(cloud.google.com/blog/products/gcp/…)