Question

在Facebook中，如果主题下的评论太多，会有一个链接“查看更多评论”，如果点击该链接，则会加载更多评论。

如何设计模型类？

我设计了模型类，如：

class Item(db.Model):
      ...
      comments = db.ListProperty(str)

或者我应该为评论设计一个单独的类并添加对该项的引用，例如

class Comment(db.Model):
      ...
      item = db.ReferenceProperty(Item)

Jinja如何做到这一点？

目前，我使用for循环来迭代注释。

Answer 1

如果两条评论几乎同时到达并且实例达到峰值，那么您在这里接触到1秒实体更新。（如果你选择了这条路线，请确保为列表属性设置indexed = False。）考虑一下这种情况如何在继续进行之前与一个看起来更复杂的替代方案相比较，但在生产之后可能会提供真正的优势。

为什么不创建一个带有计数器字段的CommentParent模型，以及一个单独的Comments模型，其中parent_id和date_created（auto）作为索引字段。当一个新的注释出现时，启动一个新的注释线程put（）父实体，并将注释文本和parent_id引用发送到一个任务队列。对线程的所有未来评论同样只是传递到队列（产生非常快的在线处理程序延迟）。让taskqueue put（）注释记录，并更新CommentParent计数器。为了避免计数器更新的1秒限制，您需要考虑调整您的TQ，或者为实体计数器划分分片计数器。（非常大量应用中的计数器非常难。）

当用户进入此评论主题时，客户端会收到parent_id和当前计数。然后，它使用parent_id = date_created＆gt;请求使用简单查询处理的前N个记录（假设LIFO模型）。过滤器，并按date_created降序和fetch（）限制或计数器来命令限制你在query.ier（）循环内的处理（我会使用后者。）你传回注释，每个注释date_created（到是你下一个查询的“光标指针”）。客户端使用初始计数器值来维护“加载N多”按钮标签。（我还会添加另一个返回值，即当您的查询返回的次数少于获取限制时，is_finished布尔值设置为true - 这将避免完全依赖计数器数学。）

这有一些缺点。最终的一致性和任务队列延迟可能意味着偶尔的不同步计数或错过的评论。您有与date_created g.t所需的自定义索引相关的开销。并订购降序设置。但是，您也有真正的积极因素：您的在线处理程序的延迟非常快，并且没有一组近乎相似的评论问题导致您遇到1秒实体更新限制的问题。使用任务队列作为评论量中任何小峰值的缓冲区，您还有一个非常重要的好处。如果没有这个缓冲区，每次出现这样的峰值时，可能会因为启动一些实例而受到困扰。这是15分钟的收费时间，这些实例的数量，（或者你正在不断调整你的实例管理员设置，并抱怨实例没有明显的需要）。

您还有一些非常简单的方法可以使用memcache来限制需要运行的实际查询的数量。如果线程处于活动状态，则可以缓存前N个查询结果，并使用该缓存直到发出新注释。像这样的东西。当然你也可以在你的方法中使用memcache。无论如何，请考虑使用memcache。

HTH -stevep

如何使用Google App Engine Python API查看N个更多评论

1 个答案: