这是关于使用(关系)数据库设计全文搜索的系统架构问题。我正在使用的特定软件是Solr和PostgreSQL,仅供参考。
假设我们正在与两位用户Andy和Betty建立一个论坛 -
Post ID | User | Title | Content
--------|-------|-------------------|---------------------------
1 | Andy | Dark Knight rocks | Dark Knight rocks blah
2 | Betty | I love Twilight | Twilight blah blah
3 | Andy | Twilight sucks | Twilight sucks blah
4 | Betty | Andy sucks | Twilight rocks, Andy sucks
当帖子表在Solr中编入索引时,我们可以轻松地将按相关性排序的帖子返回到“?q = twilight”或“?q = dark + night”。
现在我们要添加新功能来搜索用户而不是帖子。一个简单的实现只是索引用户名并将“Andy”返回到“?q = a”和“Betty”到“?q = b”,但如果我们想让我们的系统更智能也考虑到用户该怎么办?发布并将“Betty”之前返回“Andy”至“?q = twilight”,因为Betty比Andy更多地提到了暮光之城。
您如何设计系统以有效处理数十万用户和数百万个帖子的用户搜索功能?
答案 0 :(得分:1)
User
上的分面会返回每位用户的结果数量。如果Andy在Betty写了10的时候写了15个匹配Twilight的帖子,那么分面将会返回它们。
但如果双方都写了15篇关于暮光之城的帖子,它就不会有帮助,但是Andy's应该更具相关性;你会看到所有方面的数量(在这种情况下是15,15),即使你只是看到(例如)看到前5个结果并且安迪做了4个结果。
如果上述解决方案不够好,请考虑编写
文档的后台作业type: suggest_user_type (so you can distinguish them by a `fq`)
user: Andy (the user)
concatted_posts: "I think Twilight.." (concatenate the users latest 50 posts)
每周一次。如果你
fq=type:suggest_user_type&
q=concatted_posts:twilight&
fl=user
根据concatted_posts
与twilight
的相关性,您会得到一个有序的用户列表。
答案 1 :(得分:0)
我认为术语频率包含在全文搜索排名中。它是名为information retrieval的研究领域的一部分。还有另一个名为inverse document frequency的值,用于过滤常用术语。
对文本进行排名还有其他常见步骤,如果您有兴趣,可能需要查看OpenNLP项目。
就数据库设计而言,在帖子中有太多东西要覆盖,我不是那个写它的人。普遍的共识似乎是针对非常大的系统,他们关键是建立一个有效的索引,然后通过多台机器分配这个以扩展性能。我建议您阅读Page Rank以及Google如何开发其系统作为起点。