Question

我使用谷歌应用引擎作为我的后端和数据存储区作为数据库。链接https://cloud.google.com/datastore/docs/concepts/limits表示项目的最大复合索引数不能超过200。我的项目中有大约130个复合索引，将来某个时候会达到极限。

限制200对我来说似乎很少。假设我的项目中有5个模块，每个模块各有10个“类”。在每种类型中，我有4个我想要索引的属性（让我们称它们为prop1，prop2，prop3和prop4）。此外，每个“种类”都有一个名为creationTime的字段，该字段存储在数据存储区中创建实体的时间。无论我是应用0,1,2,3还是所有4个过滤器，我总是希望我的实体列表按照最新的firstTime进行排序。

在我看来，这是一个非常合理的场景。在这种情况下，对于每个“种类”，我将不得不定义以下复合索引

<datastore-index kind="kind1" ancestor="false">
        <property name="prop1" direction="asc" />
        <property name="creationTime" direction="desc" />
</datastore-index>
<datastore-index kind="kind1" ancestor="false">
        <property name="prop2" direction="asc" />
        <property name="creationTime" direction="desc" />
</datastore-index>
<datastore-index kind="kind1" ancestor="false">
        <property name="prop3" direction="asc" />
        <property name="creationTime" direction="desc" />
</datastore-index>
<datastore-index kind="kind1" ancestor="false">
        <property name="prop4" direction="asc" />
        <property name="creationTime" direction="desc" />
</datastore-index>

由于有50种这样的类型，因此会有200个这样的指标。现在我知道如果我不按creationTime对实体列表进行排序，我可以避免使用这些索引，但我认为从用户的角度来看这将是非常糟糕的。

那么有没有办法增加/克服限制？我在这里错过了什么吗？我是否需要限制查询？如果是，那么我如何才能获得相同的用户体验？数据存储区不适用于此类查询吗？我有什么选择？

Answer 1

您无法增加限制，因此您应该查看数据模型。

首先，让我们清理术语：您呼叫的是什么＆＃39;实体＆＃39;真的被称为“种类”＃39;实体是一种单独的记录。

检查您的种类并查看它们是否真的在语义上不同，或者它们是否实际上非常相似（许多重叠属性）。如果它们相似，你可以将它们全部放在同一种类中，并添加一个属性来区分它们;我们称之为type属性。

例如，与trolls，zombies和witches不同，您可以使用一种称为monsters的种类。

现在，您的示例索引：

<datastore-index kind="Entity1" ancestor="false">
        <property name="prop1" direction="asc" />
        <property name="creationTime" direction="desc" />
</datastore-index>

将是以下内容：

<datastore-index kind="Master" ancestor="false">
        <property name="type" direction="Entity1" />
        <property name="prop1" direction="asc" />
        <property name="creationTime" direction="desc" />
</datastore-index>

有什么好处，是过滤器prop1，按creationTime排序只需要一个复合索引，而不管类型的数量。因此，在您的50种示例中，而不是涵盖每种类型的50个复合索引，您现在只有1种。

Answer 2

我认为克服此限制的唯一选择是将模块分散到多个应用程序中，如果需要，甚至可以按照每个应用程序的一个模块进行扩展，基本上遵循Project isolation GAE微服务架构方法：

如果您不想依赖这些模式来实现隔离和你想要一个更正式的分离执行，你可以使用多个 App Engine项目。使用项目有利有弊服务，你必须平衡权衡取决于你的情况。除非你特别需要其中一个优点通过使用多个项目提供，最好从使用开始单个项目中的多个服务，因为性能将是更好，管理开销将最小化。当然，你也可以选择两种方法的混合。

最大索引限制是多个项目优势之一，总的来说，您可以将限制乘以项目数。

在该部分下方与您当前使用的Service isolation架构进行了比较。

但是这种方法只有在每个模块使用的索引少于限制时才有用。如果他们中的任何一个需要更多，你将不得不重新设计它。

<强>更新

另一种可能的方法是优化索引使用，在某些情况下，可以使用以下方法处理多个不同的查询：

根本没有复合索引，例如，如果我只是使用了相同的过滤器，请参阅How can a multi-property ndb query be successful without a composite index?
精心制作的复合索引较少，请参阅Index Selection and Advanced Search：

然而，有些情况下无法确切知道   提前查询的形式，例如查询的过滤器   根据用户输入动态构建。在这些情况下，所有   索引必须支持可能的过滤器组合   由应用程序定义。传统上，这需要一个   定义的索引数量为combinatorial explosion。最近   enhancements to the App Engine Datastore查询计划程序   消除了对这种扩散的要求   应用程序的索引。本文介绍如何完整   这些改进的优点。

...

索引总数为2 ^（过滤器数量）*（数量为   不同的订单）= 2 ^ 5 * 4 = 128个索引

可以指定这么多索引，但这样做有风险：


可能超过指数上限（200）

每个实体大大增加storage cost（因为此费用包括索引条目的大小）


...

所需的索引条目数量（过滤器数量+ 1）*   （订单数量）= 7 * 4 = 28.这是一个更易于管理的   数。此外，这些索引都没有爆炸，所以   其他storage cost个实体同样很小。

增加Google Cloud DataStore综合索引限制

2 个答案: