我打算为一个非政府组织的灵感网站工作,我正在寻找实施某种Facebook风格的事件流,其中包括“Michael推荐苹果派”等活动, “John评论巧克力蛋糕”,“ Caramel fudge 于8小时前由Alice发布”,等等。
事情是这些事件都是以兴趣为基础的,所以有人只对焦糖和樱桃感兴趣,不应该看到苹果馅饼或巧克力蛋糕。这有很多排列,并且即时生成用户的个性化事件流意味着一些相当昂贵的数据库查询。
所以我的想法是通过在发生动作事件时进行某种后台处理来预先生成接收用户和发布事件(可能是一个简单的SQL JOIN表)之间的关系。
将数百名用户的偏好与事件进行权衡所需的工作必然是实质性的,因此无法将其作为触发工作的POST请求的一部分来完成,因此我将不得不做很多事情。在不同的过程中工作。我目前正在寻找Gearman来完成这项任务,但我对这些建议持开放态度。
我不是在寻找某人为我做我的工作,但如果有人有任何建立此类事情的经验,我很乐意听到你的想法。
答案 0 :(得分:2)
我有一些在社交网站上构建新闻流的经验,是的,当您有多种类型的事件和多个兴趣级别(或隐私设置或用户权限)时,查询会变得非常复杂。
假设事件的查看频率高于生成事件,那么在事件发生时进行一些非规范化并计算事件的潜在观察者是有意义的,而不是每当有人请求新闻流时。
我建议运行一个后台进程,将这些事件对象(与其创建者相关)转换为更简单的消息对象(与其读者相关,在新闻流上看到它们的人)。每个事件最终可能会有很多消息,但这会使请求更快,并将工作卸载到后台进程。
我没有使用过Gearman,但是如果它允许你在后台进程中加载应用程序的环境并接收要通过队列处理的事件,那么这可能是一个好主意。
我的简单解决方案是使用beanstalkd和我自己的PHP脚本自行推送。
答案 1 :(得分:1)
不知道你的数据库是如何构建的(你可能想告诉我们更多),但显而易见的是
SELECT events.* FROM events, event_tags, user_tags
WHERE event_tags.event_id = events.id
AND event_tags.tag_id = user_tags.tag_id
AND user_tags.user_id = <$user_id>
假设你到处都有指数,对我来说,
似乎并不是非常沉重
答案 2 :(得分:1)
这听起来像是可以用适当的索引解决的东西。我会围绕数据库能够处理它的假设来构建解决方案,但是将服务放在数据库前面并让所有客户端都经历这一点。如果事情开始变得太慢,您可以在此层中引入各种类型的缓存。与大多数性能决策一样,尝试预先做好可能不是一个好主意。
答案 3 :(得分:1)
答案 4 :(得分:1)
你看过Activity模块了吗?以下是项目页面的摘录:
...跟踪人们在您网站上所做的事情,并通过块,专业表格和RSS提供这些活动的迷你供稿。该模块是可扩展的,因此任何其他模块都可以与之集成。生成的消息可通过管理界面自定义,并且对上下文敏感。
我会对你提出的问题感到好奇,因为需要在不久的将来做这样的事情。