我只是想知道选择实施跟随系统的解决方案是什么？
在MySQL中我会有一个表
userID INT PRIMARY,
followID INT PRIMARY
在Redis中我只使用SET并将所有followID添加到UserID。
什么会更快，让我们说有2000个粉丝，你想列出所有粉丝？（在一个有大约1M条目的表中） 如果两个用户互相关注，会更快发现什么？
非常感谢！
答案 0 :(得分：5)
按照现代标准，1M项目都不算什么。任何数据库或NoSQL系统都可以正常使用这样的音量，所以你只需要选择一个你最熟悉的那个。
就绝对性能而言，Redis在这个用例上比MySQL更快，因为：
但请注意，关系数据库比像Redis这样的键/值存储更灵活。如果您可以预测数据的所有访问路径，那么Redis是一个很好的解决方案。否则，更传统的数据库将为您提供更好的服务。
答案 1 :(得分：2)
在我看来，请使用MySQL。
在做出决定时你会考虑的两个要点是：
1）您是否考虑过您的用例？
你说你想要实现一个跟随系统。如果您只是要显示每个用户拥有的关注者列表，那么Redis SET就足够了。
但是，如果您想获得“您当前关注的用户列表”列表，该怎么办？你不能轻易地从你的Redis SET中挖掘出来，对吗？或者如果你想知道User-X是否跟随用户A怎么样？如果用户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,000请求/秒之后。 否则你不会看到超过50毫秒的差异。
在您拥有非常大的流量之前，性能差异不会成为问题。
因此，在考虑了这两点之后，MySQL将是一个更好的答案。
只有在以下情况下才能使用Redis：1）集/列表的目的是具体的，将来不需要灵活性
2）您认为性能差异实际上会对您的架构产生影响。
答案 2 :(得分：0)
这取决于您想要对数据执行的操作。您给出了一些示例，但听起来并不像您真正完全定义了产品需要做什么。如果您真正想要做的就是向用户展示他们是否互相关注？然后要么就好，因为你只是在谈论2个简单的查询。但是，如果您希望向两个用户显示他们共享的用户，或者您希望根据用户的配置文件数据从数据中提出建议，该怎么办？然后，它变得更有趣，因为Redis具有非常快速地轻松为您提供交集的功能（我们在速度方面不仅仅是毫秒级，而且由于有更多的用户/关系，差异会成倍增大）如果你想实时提供数据，解析为获取数据所需的sql连接可能会变得过高。
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还是那个真的是你期望处理的）以及功能和预算。然后真正检查市场上的许多不同选项。