【发布时间】:2020-10-20 10:34:26
【问题描述】:
我正在尝试了解 neo4j 在实时推荐系统中的性能。
以下是一个密码查询(取自他们的沙箱),它计算与查询用户“Cynthia Freeman”最相似的前 100 个用户(在余弦距离上):
MATCH
(p1:User {name: "Cynthia Freeman"})-[x:RATED]->(m:Movie)<-[y:RATED]-(p2:User)
WITH
COUNT(m) AS numberMovies,
SUM(x.rating * y.rating) AS xyDotProduct,
SQRT(REDUCE(xDot = 0.0, a IN COLLECT(x.rating) | xDot + a^2)) AS xLength,
SQRT(REDUCE(yDot = 0.0, b IN COLLECT(y.rating) | yDot + b^2)) AS yLength,
p1, p2
WHERE
numberMovies > 10
RETURN
p1.name, p2.name, xyDotProduct / (xLength * yLength) AS sim
ORDER BY sim DESC
LIMIT 100;
如果我的理解是正确的,LIMIT 子句后面没有魔法,因为与所有其他用户相比,距离计算仍然需要完成,所以实时解决这个查询似乎有点牵强,除非 neo4j 在幕后做点什么。
在另一个例子中,他们预先计算了用户节点之间的[:SIMILARITY]关系并将其存储在图中,因此查询前N个最相似的用户成为节点的排序。这将直观地使图密集,因此与简单地使用相似矩阵相比没有存储优势。
我是否遗漏了有关图形数据库(尤其是 neo4j)工作方式的一些基本知识?这如何扩展到实时应用程序,其中可能有数以万计的用户,以及他们与之交互的更多产品?
【问题讨论】:
标签: performance neo4j cypher recommendation-engine