【问题标题】:Strong consistency in Datastore (HRD)... my idea数据存储区(HRD)中的强一致性......我的想法
【发布时间】:2014-01-21 17:33:04
【问题描述】:

我希望这不会被标记为“没有帮助”,因为我认为很多人都在尝试找出一种方法来保持 HRD 的强一致性。

这是我用于我的应用程序的想法。我想听听你的意见。

我有一个健身应用。这当然是由锻炼和练习组成的。 HRD 包含大约 400 个练习可供选择,或者用户可以创建自己的练习(一个 UExercise)。

当用户登录时,我将所有锻炼键加载到用户的“锻炼键”列表中。同时,我将所有用户练习键 (UExercise) 加载到用户上的“exerciseKeys”列表中。

如果用户想要在特定锻炼中添加/删除锻炼,则会加载锻炼并将其所有锻炼键加载到锻炼上的“锻炼键”列表中。

在这里看到一个模式?

因此,每当我想查看用户创建的练习 (UExercise) 或用户锻炼,或该锻炼中的练习时,我都会使用这些键执行 get()。

由于用户可能不会进行 1000 次锻炼或创建 1000 次锻炼,我认为这是实现强一致性的安全快捷方式。

并不是说这是每个应用程序的最佳方式。但对我来说,我相信它会运作良好。

如果我在这里可能遗漏了什么,或者没有适当考虑到,我将非常感谢您的所有意见。

【问题讨论】:

    标签: google-app-engine google-cloud-datastore consistency


    【解决方案1】:

    好的...在仔细考虑了我的应用程序将如何工作以及用户如何实际使用它之后,我决定放弃上面的想法并使用祖先查询。

    所以对于上面的模型,我想出了以下...

    • 对于锻炼,我将用户设为父母
    • 对于创建用户 (UExercise) 的练习,我将用户设为 父母

    这允许我使用祖先查询(它们是强一致的)来提取最近添加或修改的实体。

    由于用户不会大量修改这些实体,我认为写入的限制不会是一个因素。

    这也让我摆脱了模型对象上原本不应该存在的属性。

    顺便说一下,我也试过 Memcache。我发现这是最大的痛苦。必须保持 Memcache 和 Datastore 同步似乎比实际需要的复杂性要多得多。

    但您的网站和结果可能会有所不同。这个想法很适合我的应用。

    谢谢!

    【讨论】:

      猜你喜欢
      • 2013-07-25
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2012-04-04
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2018-08-13
      相关资源
      最近更新 更多