实施“以下” GAE 上高效的功能
我正在 Java/GAE 上实现一个具有“以下”功能的 iPhone 应用程序。 此功能与 Instagram 类似，用户可以关注其他用户的活动。事件可以是发布的新照片、喜欢照片、关注其他用户等。
假设我们有两个实体：关注和事件，两者都有对用户 ID 的引用。
所以我正在考虑使用 OR 查询来列出目标用户的事件。但GAE不支持OR查询，并且发出单独的查询也会效率低下，因为查询的数量可能非常大（例如，100+以下是常态）。
这样做的常见做法是什么？
I'm implementing an iPhone app with the "following" feature on Java/GAE.
This feature is similar to Instagram's in that a user can follow other users' events. Events can be new photos posted, liking photos, following other users, etc.
Let say we have two entities: Follow and Event, both of which have a reference to the user id.
So I'm thinking about using OR queries where we can list events of target users. But GAE does not support OR queries, and issuing separate queries would be also inefficient as the number of queries can be quite large (e.g. 100+ follows is a norm).
What is a common practice for doing this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我会为订阅和订阅者使用ListProperty。每次订阅用户发帖时，您都可以使用一项任务来添加条目以供每个订阅者查看。正如 Rick Mangi 指出的那样，关系模型不会帮助您处理数据存储。如果您使用新的 NDB API，则可以使用重复属性。由于您正在为每个观察者创建实体，因此异步 API 可能会很方便。
I'd use a ListProperty for both subscriptions and subscribers. Every time a subscribed user posts, you use a task to add entries for every subscriber to see. Like Rick Mangi pointed out, the relational model won't help you with the datastore. If you are using the new NDB API, you can use a repeated property instead. Since you are creating entities for every observer, the asynchronous API may be handy.
你必须停止在关系模型中思考;-)我们在我们的应用程序上做了类似的事情。保留被关注用户实体中“订阅”的 UID 列表。当用户执行需要通知的操作时，为关注该用户的每个用户创建一个事件实体（是的，受欢迎的用户可以创建一大堆条目，这可以被卸载到任务队列）。
当用户检查通知时，您可以通过他的 UID 获取通知。由于它已被索引，因此它会很快返回。当您获取事件时，将其删除或将其标记为已读。
请记住，联接和其他过滤查询非常慢，但获取大量索引记录则不然。如果某件事将创建大量记录，请将其卸载到任务队列。
You have to stop thinking in the relational model ;-) We do something similar on our app. Keep a List of UIDs that are "subscribed" to the user who is being followed in the followed user's entity. When the user does something that requires notification create an event entity for each user who is following the user (yes, a popular user could create a whole bunch of entries, this could be offloaded to a Task Queue).
When a user checks for notifications you can fetch them by his UID. Since this is indexed it will return very quickly. When you fetch the events, delete them or mark them read.
Remember, joins and other filtered queries are very slow, but fetching massive numbers of indexed records is not. If something is going to create a large number of records, offload it to a Task Queue.
我们正在实施 Etsy 在其公开幻灯片分享中描述的模型。
这是架构图。
强烈建议完整阅读他们的演示文稿。
Etsy 活动源架构
We are implementing the model Etsy has described on their public slide share.
Here is the schema diagram.
Highly recommend reading their presentation in its entirety.
Etsy Activity Feed Arch