google-cloud-platform - Cloud Datastore 中列表属性与多个属性与祖先键的权衡是什么?
问题描述
我的应用程序具有以下模型:
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
我认为列表属性和祖先键方法之间的应用程序级权衡是列表方法更紧密地将插件与核心耦合,而祖先键具有更解耦的数据方案(尽管不完全)。
我还应该关注性能或其他方面的其他权衡吗?
解决方案
就我个人而言,出于多种原因,我会使用多个属性,但可以根据应用程序的要求混合所有这些解决方案以获得不同程度的灵活性。主要的权衡是
a)您不能在数据存储中进行连接,因此将相关数据存储在多个实体中将防止使用复杂的 where 子句(祖先键方法)进行查询 b)如果您将数字和日期字段作为标签,则不能进行范围查询(列表属性方法)c)如果您索引标签字段并且实际上只有一小部分标签需要被索引,则索引可能会很大且昂贵
因此,考虑混合所有这 3 种方法的一种方法是
a) 对于您的静态数据和应用程序逻辑,使用多个属性。b) 对于不用于查询的动态数据,您可以使用标签列表。c) 对于插件需要查询但不需要与静态数据连接的可插入数据,您可以创建另一个实体,再次使用 a) 和 b),以便插件将所有相关数据存储在一起。
推荐阅读
- python - 是否可以使用悬停或选择工具处理文本?
- json - 使用密封类或带有 Moshi 的接口时无法为类创建转换器
- oracle - 无法插入第三列数据
- asp.net - 单击按钮从每个中继器下载多个图像
- python - 如何在 Jupyter Notebook 中将图例置于交互模式图之外
- matlab - 手指接触荧光粉的面积测量 - 批处理
- android - 如何从领域响应中更新回收站视图项
- java - 如何测试是否在要测试的方法内创建的对象上调用了方法
- php - 解析错误:语法错误,意外的 'mailuid' (T_STRING)
- asp.net - 从网络聊天 iframe 中隐藏秘密