我一直在编写App Engine应用程序，最近开始对App Engine在数据扩展时的成本有所担忧。
我的应用程序具有员工数据。雇员实体具有许多属性，例如名字，姓氏，生日，地址，电话，移动电话，参考人，教育背景，培训历史，收入数据等。将来总资产可能达到100处。
起初，我认为我不应该将所有属性打包在一个名为Employee实体的实体中，因为每次我想在实体中放置或更新几个属性时，都必须获取该实体中的所有属性，因此，我以一对一的关系方式将实体分解为许多实体，并将“用户界面”划分为选项卡，联系信息选项卡，教育背景选项卡，收入选项卡等。当用户单击选项卡时，将随后从该特定实体加载数据，并且先前关闭的选项卡上的数据将自动保存。为了提高性能和成本效率，我将一个大实体分为许多小的一对一关系实体。我也这样做是为了提高分页效率，因为它只获取了雇员列表页面具有最少属性编号的小型实体。
读取App Engine定价模型后，它会根据每个实体的读写时间来收取费用，这意味着我设计实体的方式将增加读写次数。我认为我的设计具有成本效益，并且性能更好。每次获得一个实体时，我都会使用较少的CPU和带宽，因为我不需要一次将所有属性都显示在同一页面上。
还是应该将实体压缩为一个或几个实体，以提高应用程序性能并降低成本。对于分页功能，我可以创建一个专用实体来手动处理分页。
如果您的Employee实体具有许多索引属性，则您的方法是正确的。每次更新实体时，每个索引属性都会产生写入费用。因此，将实体拆分成较小的部分将大大降低整个实体生命周期内的写入成本。换句话说，首次写入所有这些数据的初始成本可能会稍高，但是每次后续更新的成本都会大大降低。
类似的逻辑适用于读取。仅当您的用户单击每个员工的每个选项卡时，多个实体的价格才会稍高一些，这是不太可能的。大多数情况下，由于需要读取数据或进行更改，它们会转到特定的选项卡。
注意：我还必须观察到，除非您有成千上万的用户，否则这些方法之间的美元差额可能不值得您花费时间。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句