mysql - 追随者系统，在 MySQL 或 Redis 中更好？

Question

我只是想知道选择什么解决方案来实施追随者系统？

在 MySQL 中我会有一张桌子

userID INT PRIMARY,
followID INT PRIMARY

在 Redis 中，我只需使用 SET 并将所有 followID 添加到 UserID 中。

假设某人有 2000 个关注者并且您想列出所有关注者，什么会更快？（在一个有大约 100 万个条目的表中）如果两个用户互相关注，什么会更快？

非常感谢你！

Answer 1

按照现代标准，100 万件物品不算什么。任何数据库或 NoSQL 系统都可以在这样的容量下正常工作，因此您只需选择您最熟悉的一个即可。

在绝对性能方面，Redis 在这个用例上会比 MySQL 更快，因为：

• 整个数据集将在内存中
• 哈希表比 btree 快
• 没有要解析或执行的 SQL 查询

但是，请注意，关系数据库比 Redis 之类的键/值存储灵活得多。如果您可以预测到数据的所有访问路径，那么 Redis 是一个很好的解决方案。否则，更传统的数据库将为您提供更好的服务。

Answer 2

在我看来，选择 MySQL。

在做出决定时，您会考虑的最大两点是：

1）您是否考虑过您的用例？

你说你想实现一个追随者系统。如果您只想显示每个用户拥有的关注者列表，那么 RedisSET就足够了。

但是，如果您想获得“您当前关注的用户列表”的列表怎么办？你不能轻易地从你的 Redis 中挖掘出来SET，对吧？或者如果您想知道 User-X 是否在关注 User-A 呢？如果 User-A 有 10,000 个关注者，这也不容易吧？

MySQL 在不同场景中查询不同类型的结果时更加灵活。

2）你真的需要性能差异吗？

如您所知，在这些情况下，Redis 比 MySQL 快。它是一个简单的 Key-Value 系统，因此会超过 MySQL 的性能。检查如下性能结果：

http://colinhowe.wordpress.com/2009/04/27/redis-vs-mysql/

http://ruturaj.net/redis-memcached-tokyo-tyrant-and-mysql-comparision/

但是 Redis 和 MySQL 之间的性能差异只有在大约 5,000request/sec 之后才真正开始出现。否则你不会看到超过 50 毫秒的差异。

除非您有非常大的流量，否则性能差异不会成为问题。

所以，在考虑了这两点之后，MySQL会是一个更好的答案。

只有在以下情况下，Redis 才会很好：

1）set/list的目的是特定的，以后不需要灵活处理

2) 你觉得性能差异实际上会对你的架构产生影响。

Answer 3

这取决于你想对数据做什么。你举了一些例子，但听起来你并没有真正给出产品需要做什么的完整定义。如果您真正想做的只是向用户展示他们是否互相关注？然后两者都可以，因为您只是在谈论 2 个简单的查询。但是，如果您想向两个用户展示他们共享的用户的交集，或者您想根据用户的个人资料数据提出建议，该怎么办。然后，它变得更有趣，因为 Redis 具有轻松快速地为您提供集合交集的功能（我们'

sadd friends:alex george paul bart
sadd friends:alice mary sarah bart
sinterstore friends:alex_alice friends:alex friends:alice

请注意，上述操作也可以使用 mysql 完成，但是您的性能会受到影响，并且您更有可能将其作为批处理作业运行，然后存储结果以备将来使用。另一方面，请记住，世界上最大的“朋友”网络 Facebook 是从 mysql 开始存储关系的。这些关系的图表被批量处理并高度非规范化以存储在数千个 memcached 服务器中以获得良好的性能。

然后，如果您正在寻找除 mysq1 或 redis 之外的更多选项，您可能想阅读 Michael Stonebaker 所说的（他帮助创建了 Postgres 和 Ingres）关于使用 RDBMS 系统处理图数据（例如朋友关系）的内容。 http://gigaom.com/2011/07/07/facebook-trapped-in-mysql-fate-worse-than-death/。当然，他正试图出售他的新 VoltDB，但这是值得深思的有趣食物。

所以我认为你真的需要根据预期负载（你只是扔掉 2000 或者这真的是你期望处理）以及功能和预算。然后真正检查市场上的许多不同选项。