索引简短枚举列表的可伸缩性

Question

在Datastore中，索引只能有4-5个可能值的属性是一个问题吗？这会导致平板电脑热点吗？

我想到的是一个包含字符串值的枚举的属性，如“已完成”、“工作”、“完整”。索引这样一个属性的原因是，您可以创建一个复合索引，例如，让我们查询所有“已完成”的实体。

Answer 1

是的，如果/当您使用索引中列出的这些复合索引的查询率很高时，这将是一个问题。

• 不要用单调递增的值(例如NOW()时间戳)索引属性。维护这样的索引可能会导致热点，从而影响具有较高读写速率的应用程序的Cloud延迟。有关处理单调属性的进一步指导，请参阅下面的窄键范围内的高读/写率。

如果/当您命中高速率的数据存储写入具有相同属性值的实体(例如，每秒成为done的实体的100多个实体)时，您还会遇到一个平板热点问题--这是同一问题的另一个方面。这是较高的读/写速率到一个狭窄的键范围中提到的这个案例

• 如果使用单调递增的索引属性(如时间戳)以高速率创建新实体，您也会看到这个问题，因为这些属性是Bigtable中索引表中行的键。

Answer 2

TLDR:只要实体键分散，它就会缩放。

博士：

让我们首先考虑正在写入的索引条目。

我们有这样的东西：

SomeKind\E1 -> FullEntityKey1
SomeKind\E2 -> FullEntityKey2
SomeKind\E2 -> FullEntityKey3
SomeKind\E3 -> FullEntityKey4

我们注意到，每个索引条目指向某个实体。

就负载分片而言，正在分割的值如下所示：

SomeKind\E1\FullEntityKey1
SomeKind\E2\FullEntityKey2
SomeKind\E2\FullEntityKey3
SomeKind\E3\FullEntityKey4

现在让我们想象一下，我们对实体键使用了随机分配的ids (范围0,2，非常简单) --我们假设在随机实体ids之间均匀地分布写。

SomeKind\E1\0\RestOfKey1
SomeKind\E2\0\RestOfKey2
SomeKind\E2\1\RestOfKey3
SomeKind\E3\2\RestOfKey4

然后我们可以注意到，有明确的分割点来分割负载--也就是说，每一个0,2可能的随机id都是一个碎片，系统可以无限期地缩放，只要写入在SomeKind写的各个功能之间均匀分布(对于更多的拆分点/缩放，使随机id更长)。

因此，is索引枚举值缩放/热点与被索引的实体键高度相关，这些索引键通常是以可分的方式构造的，这意味着关联的索引项也是。

这并不是说不可能创建热点可能发生的情况(例如，如果实体键的值单调增加(比如时间戳))，或者通过将一小部分键作为很高的写入速率的目标--但在默认情况下，这种情况不应该发生在典型的流量模式和实体键中。