2

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

在 MySQL 中我会有一张桌子

userID INT PRIMARY,
followID INT PRIMARY

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

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

非常感谢你!

4

3 回答 3

5

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

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

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

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

于 2013-01-22T14:36:14.557 回答
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) 你觉得性能差异实际上会对你的架构产生影响。

于 2013-01-22T15:07:08.370 回答
0

这取决于你想对数据做什么。你举了一些例子,但听起来你并没有真正给出产品需要做什么的完整定义。如果您真正想做的只是向用户展示他们是否互相关注?然后两者都可以,因为您只是在谈论 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 或者这真的是你期望处理)以及功能和预算。然后真正检查市场上的许多不同选项。

于 2013-01-22T15:52:29.617 回答