【问题标题】:Task queues and Datastore read and writes任务队列和 Datastore 读写
【发布时间】:2015-03-29 14:24:02
【问题描述】:

我在我的谷歌云端点模块中使用 Objectify,我的端点项目处理我的大部分数据存储读取和写入操作,但我想知道使用任务队列包装读取或写入操作是否是一种有效的设计实践在谷歌应用引擎的数据存储上。

【问题讨论】:

  • 为什么要在任务中包装读/写?你想解决什么问题?
  • 我只是在尝试古玩,如果它可以帮助加快读写操作。

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


【解决方案1】:

任务执行所需的所有数据都必须写入某处,App Engine 将这些数据保存在由同一数据存储区支持的任务队列中。除非您的写入操作涉及数字运算、URL 获取、外部 API 调用、数百个实体的更新或其他一些昂贵的逻辑,否则将写入调用包装在任务中没有任何优势。

在大多数情况下,将读取调用包装在任务中是不可能的,因为您无法在同一个调用中返回此数据。

【讨论】:

  • 谢谢,就像我说的那样,这只是一个想法。您是 appengine 开发人员吗?。
  • 你可以点我的名字看我不是:) 但是我用 App Engine 很多年了。
  • 好的,刚开始使用,很喜欢。
  • 大家好。我有问题。有没有办法修改 Datastore Admin Backup 内置任务队列?这是我的问题的链接。谢谢*.com/questions/65698872/…
【解决方案2】:

如果您想加快写入速度,请考虑使用 write-behind-cache。丢失数据的可能性很小,但会大大加快写入速度(如用户所见)。

这个想法是先将实体只写入memcache,这样用户就不会等待实际的数据存储写入,然后通过任务队列/cron 取出该memcached实体并将其写入数据存储。

【讨论】:

  • 我正在使用 objectify @cache 注释,所以我认为缓存的东西已经处理了,我不明白你的 write-behind-cache 概念。
  • 实际上透明地处理异步写入(如果你不使用.now()),你不会得到任何反馈(比如创建的实体id)。
  • 好吧,忘记你的意思,我明白,但有些操作不适用于典型示例,当您处理交易时,您可能需要获取一个对象的 ID 和将其引用到另一个对象。感谢您的提示。