Cloud Datastore 中列表属性与多个属性与祖先键的权衡是什么？

Question

我的应用程序具有以下模型：

class Employee:
  name = attr.ib(str)
  department = attr.ib(int)
  organization_unit = attr.ib(int)
  pay_class = attr.ib(int)
  cost_center = attr.ib(int)

它工作得很好，但我想将我的应用程序重构为更多的微内核（插件）模式，其中有一个可能只有名称的核心 Employee 模型，并且插件可以添加其他属性。我想也许一种可能的解决方案是：

class Employee:
  name = attr.ib(str)
  labels = attr.ib(list)

员工可能看起来像这样：

Employee(
   name='John Doe'
   labels=['department:123',
           'organization_unit:456',
           'pay_class:789',
           'cost_center:012']
)

也许另一种解决方案是为每个“标签”创建一个实体，其中核心员工作为祖先键。此解决方案的一个问题是，目前对实体组的写入限制为每秒 1 次，尽管一旦 Google 将现有数据存储升级到新的“数据存储模式中的 Cloud Firestore”，该限制就会消失（希望很快）：

https://cloud.google.com/datastore/docs/firestore-or-datastore#in_native_mode

我认为列表属性和祖先键方法之间的应用程序级权衡是列表方法更紧密地将插件与核心耦合，而祖先键具有更解耦的数据方案（尽管不完全）。

还有其他我应该关注的权衡，性能还是其他方面？

Answer 1

出于多种原因，我个人会使用多个属性，但可以根据应用程序的要求混合所有这些解决方案以获得不同程度的灵活性。主要的权衡是

a) 您不能在数据存储中进行连接，因此将相关数据存储在多个实体中会阻止使用复杂的 where 子句进行查询（祖先键方法） b) 如果将数字和日期字段作为标签，则不能进行范围查询（列表属性方法） c) 如果您索引标签字段并且实际上只需要索引一小部分标签，则索引可能会很大且昂贵

因此，考虑混合所有这 3 个的一种方法是

a) 对于您的静态数据和应用程序逻辑，请使用多个属性。 b) 对于不用于查询的动态数据，您可以使用标签列表。 c) 对于插件需要查询但不需要与静态数据连接的可插入数据，您可以创建另一个再次使用 a) 和 b) 的实体，以便插件将所有相关数据存储在一起。