再会，
这是我的用例：每个用户都有一个物品愿望清单和他们提供的物品清单。项目的数量是一个确定的数字，而用户可以是任何数字。
我的目标是根据算法为登录用户提供推荐或库存与他的愿望清单匹配的用户列表。需要注意的是，我需要能够以这样一种方式对结果进行排序，即根据他的愿望清单拥有最完整产品的用户出现在顶部并以降序方式对其进行排序。我需要能够以分页方式呈现它，所以我希望查询可以使用商品虚拟服务器规范在 3 秒内完成。
现在到我的数据上，为了简单起见，我只会将每个用户限制在他的愿望清单上的 35 个唯一项目和他的库存中的 250 个唯一项目。对于我的测试数据，我输入了 50k 个用户，每个用户都有基于限制的随机愿望清单/库存计数。我用 MySQL 中的一个连接来映射它，我在这个测试数据上得到了大约 700 万个关系。出于好奇，我尝试通过使用愿望清单中有 35 件商品的用户的 ID 加入愿望清单和库存表来查询数据库。即使在涉及的所有列中使用最优化的查询模式和索引，空的 Rackspace 虚拟服务器（2GB RAM，1vCPU）也需要 21 秒才能完成查询。为了知道硬件不是瓶颈，
为了确保我在决定使用图形数据库之前尝试了一切，我在 MongoDB 上做了同样的测试，我可以应用我的匹配算法的唯一方法是通过 MapReduce。它导致远程服务器上的查询时间为 9 秒，而我家用计算机上的查询时间为 3 秒。这对我的用例来说仍然不可行，因为 MapReduce 对服务器来说非常繁重，想象一下 500 个用户同时进行查询。
现在进入我正在谈论的算法：
- 获取用户心愿单上的所有东西，并获取提供这些物品的用户列表。
- 对于每个用户，获取与愿望清单中的商品匹配的所有商品，如果它们提供的数量超过了要求的数量，则只需使用所需的数量即可。
- 汇总这些计数并获得匹配的愿望清单的最终百分比。
让我们有一些示例数据：
# users
------------
uid | name
------------
1 | Ramon
2 | Mark
3 | Ralph
------------
# wishlist
--------------------------
pkid | uid | item_id | qty
--------------------------
1 | 1 | 1 | 2
2 | 1 | 2 | 5
3 | 1 | 3 | 1
--------------------------
# offers
--------------------------
pkid | uid | item_id | qty
--------------------------
1 | 2 | 1 | 1
2 | 3 | 2 | 2
2 | 2 | 3 | 7
这导致我以这种方式设计图表：
所以从节点开始Ramon，遍历图来获取其他对我有offer的用户。以下应该是汇总前的初步结果：
uid | item_id | wishlist_qty | offer_qty
----------------------------------------
2 | 1 | 2 | 1
2 | 3 | 1 | 1 # this should be 7 but we only need 1
3 | 2 | 5 | 2
----------------------------------------
有了上面的数据，我们现在可以制定出哪个用户拥有最多的用户愿望清单：
sum(offer_qty) / sum(wishlist_qty)然后根据这个结果按降序排列用户，这会给我们这样的结果：
uid | percentage
----------------
2 | 0.67
3 | 0.4
----------------
有了它，这就是我想要实现的推荐算法。我是图形数据库的新手，所以如果可以实现并且在我打算使用的环境和用户数量中表现良好，我需要朝正确的方向轻推。如果您有其他建议，可能是使用其他类型的数据库（如列存储）或更改我的数据模型以使其适用于此用例和预期环境，请随时提出建议，但请包括我如何使其工作与我的情况。
我希望我已经完整地说明了我的编程问题。提前感谢您的回答。
拉蒙