我正在开发一个将使用三个表的应用程序。 1 - 100万行产品。 2 - 5亿行用户。 用户喜欢的3到100亿行产品。 表格会随着时间的推移而增长，但会保持这些数字。 我想为这种DB选择正确的方法。 我真的不太了解分片，聚类或分区，但如果你们中的一些人可以告诉我这个问题的最佳解决方案，我将专注于它，它将是一个巨大的帮助。 我只想要支持mysql的方法，如果我需要这种数据库的多个服务器？ 感谢。
答案 0 :(得分：1)
您可以非常轻松地对此数据集进行分片，但您可能不必依赖于您尝试执行的分析类型。如果这只是每个用户喜欢的历史记录，那么您可以使用database partitioning按日期范围对数据进行分区，然后在user_id上进行子分区。
如果您经常更新日期（用户可以“不同”），那么您可能需要查看分片。这里有一个示例分片实现：Shard-Key-Mapper。您可以在此处对数据集执行分布式并行查询（如map / reduce for SQL）：Shard-Query。
如果你进行了分片，我应该建议使用user_id进行分片，并将products表保留为每个分片上重复的“共享”表。您应该使用基于目录的分片方法，该方法允许您在分片之间移动用户。有关单个用户的所有信息以及他们喜欢的信息将一起存储在一个分片上。
答案 1 :(得分：0)
我认为如果你真的不想要像Hadoop这样的noSQL解决方案，你就无法避免获得多个数据库（这里是：MySQL）服务器。而MySQL复制在我看来并没有为这类数据提供足够的可扩展性，因为主服务器将成为瓶颈。我也不是一个可扩展性专业人士，但我目前也在为我这样的类似问题考虑一个很好的解决方案。我想我将采用分片解决方案，在多个节点上对数据进行分区。我正在考虑一种创建从数据到分片的映射的智能方法。但这取决于您的应用程序如何制作它。我认为你的'产品喜欢'数据是分区的一个很好的选择，因为它是如此巨大。
BTW：一篇有趣的文章反对分片：http://37signals.com/svn/posts/1509-mr-moore-gets-to-punt-on-sharding