需要帮助选择正确的mysql DB分片、集群或分区方法

Question

我正在开发一个将使用三个表的应用程序。1-100万行产品。2-5亿行用户。3-100亿行用户喜欢的产品。表将随着时间的推移而增长，但将保持在这些数字附近。我想为这种数据库选择正确的方法。我真的不太了解分片，集群或分区，但如果你们中的一些人能告诉我这个问题的最佳解决方案，我将专注于它，它将是一个巨大的帮助。我只想要支持mysql的方法，如果这种数据库需要多个服务器？谢谢。

Answer 1

您可以很容易地对此数据集进行分片，但根据您尝试进行的分析类型，您可能不必这样做。如果这只是每个用户喜好的历史记录，那么您可能可以使用database partitioning按日期范围对数据进行分区，然后在user_id上进行子分区。

如果您要频繁更新日期(用户可以“不同”的事情)，那么您可能需要考虑分片。这里有一个分片实现的例子：Shard-Key-Mapper。您可以在以下位置对数据集执行分布式并行查询(如SQL的map/reduce )：Shard-Query。

如果要分片，我建议按user_id进行分片，并将products表保留为“共享”表，该表在每个分片上重复。您应该使用基于目录的分片方法，允许您在分片之间移动用户。关于单个用户的所有信息，以及他们喜欢什么的信息将一起存储在一个分片上。

Answer 2

我认为如果你真的不想要像Hadoop这样的noSQL解决方案，你不可避免地需要多个数据库(这里: MySQL)服务器。在我看来，MySQL复制不能为这类数据提供足够的可伸缩性，因为主节点将成为瓶颈。我也不是可伸缩性专业人士，但我目前也在考虑一个很好的解决方案来解决我这边的类似问题。我认为我将采用分片解决方案，将数据分区到多个节点上。我只是在想一种智能的方式来创建从数据到分片的映射。但这取决于你的应用程序你想如何制作它。我认为你的“喜欢产品”的数据是一个很好的分区候选者，因为它太庞大了。

顺便说一句:一篇有趣的文章 An sharding：http://37signals.com/svn/posts/1509-mr-moore-gets-to-punt-on-sharding