我正在构建/构建一个商业社交网络Web应用程序，其中包含一个我认为会导致主要可扩展性问题的组件，我想就最佳前进方式获得一些反馈/想法。
该应用程序具有User对象。这个想法是，每次新用户加入系统时，他都会根据一系列因素对其他人的“有用性”进行排名。同样，系统中的每个其他用户都会对他/她进行排名。
但是，我担心这种方法的可扩展性含义。例如，如果10,000个用户加入系统，我们正在讨论要存储到数据库的10,000 ^ 2个计算。这是1亿条记录，因此无论是在计算这些排名所花费的时间方面，还是在将其存储在数据库方面，都显然会产生问题。
因此，我正在寻求帮助/灵感：）
我的背景是在java中，我一直在看hadoop / map-reduce作为以并行方式实现计算的可能方式，但是我真的不确定这个问题是否适用于Map Reduce或者什么是最好的方法。
所以，我想我的查询有两个具体的部分..
1）要进行实际计算，我应该以并行的方式进行这些计算，即..is Map减少这个问题的好方法
2）为了存储排名，我应该使用什么...是一个标准的关系数据库一个坏主意，即......这不适合MySQL ...我应该看看像Cassandra，HBase还是其他一些NoSQL解决方案？
非常感谢任何帮助/想法。
欢呼声， 布赖恩
答案 0 :(得分：1)
答案 1 :(得分：0)
我建议只存储“真实”值（用户输入的值）。这样，用户对其他对用户有价值的用户进行排名，其余所有用户都被认为是“无用的”;）。因此，您可以为每个用户存储几百个值。我假设你不是真的会让每个新用户浏览其他用户的整个列表并单独排名，对吧？
您还可以通过建立存储两个用户评估的双向关联来减少您的空间需求（一个记录将用户A与用户F链接，并且记录A将F排名为5，而F将A排名为3）。将您的空间需求大致减少一半，但它仍然是很多记录。此外，您还需要两个用户键上的索引，因为您必须同时搜索两个用户键才能找到所有记录。
答案 2 :(得分：0)
虽然100米行肯定很大，但可能没有你想象的那么大。我处理的是一个MySQL数据库，它有一个超过10米行的表，它连接到行数超过100k的其他表没有太多问题。重要的是要使您的索引正确并使您的查询更有效。也许在花费太多时间考虑超级架构之前，用你认为可能在其中的行填充一个播放表，并编写一些你认为你将要编写的查询，看看它是否可管理。