我们有一个中等规模的电子商务网站。我们卖书。在该网站上，我们有促销，用户推荐，常规书页，相关书籍等。与amazon.com非常相似，除了网站的数量。
我们有一个传统的LAMP设置，其中M仍然代表MariaDB。
TPTB希望记录和分析用户行为以优化转化。
底线，我认为每次点击都必须记录。 （我担心）
每月累计点击次数达到数百万次。该系统必须能够及时回溯至少3年。
可能被问到系统的问题是：给定页面（例如：主页），并点击促销横幅，所述横幅的哪种颜色提供最佳转换。现在将这个问题分解为新客户和回头客。 （多维或A / B测试）或者，考虑到书A和B的视图，用户下一步购买哪些书。查询范围将非常广泛。汇总数据毫无意义。
我非常怀疑MySQL能否提供一个存储，分析和查询这些数据的良好平台。我们可以存储这些行，通过RabbitMQ将它们提供给MySQL以避免延迟，但是在给定50M行的情况下，在MySQL中查询和分析这些数据可能不是最佳的。
有很多关于使用MongoDB存储分析数据的文章。但是所有的帖子似乎都增加了文档中的计数器（预先聚合数据），这对我们来说还不够好。
最大的问题是：是否有任何数据库（或其他系统）特别适合存储和分析这样的数据？可能MySQL仍然可以做到这一点？我的评估是否正确，MongoDB可能在这里没有任何附加价值？
答案 0 :(得分：1)
如果我理解正确，那么您只想让报告中的汇总数据每天说一次（与“直播”相对）？如果是这种情况，我建议使用Hadoop，因为它允许您为您运行运行此聚合的大量Map / Reduce作业，然后向您显示报告。在这一数据量下，任何“实时”解决方案都无法正常工作。
如果你不想搞乱Hadoop和Map / Reduce的复杂性，那么MongoDB可能会工作。它有一个非常强大的聚合框架，可以在一个实时环境中执行许多聚合。它不是真正意味着在每个网页浏览中运行，但它也不是“让我们每天做一次”的事情。它取决于您的数据聚合要求，无论聚合框架是否可以帮助您，但如果没有，那么MongoDB还支持Map / Reduce用于更复杂的任务（速度较慢）。 MongoDB非常适合，因为您可以拥有较高的写入性能 - 如果一个节点不起作用，您可以始终进行分片以获得更高的写入性能。
答案 1 :(得分：0)
如果你的主要建议是根据过去的用户选择提供建议，你也可以考虑像Neo4j或FlockDB这样的图形数据库。
这些数据库允许您建立买家与他们购买的商品之间的关系（这应该是要存储的数据要少得多，因为您将减少很少的用户数据冗余），您可以使用它来执行一些三元关闭流程 - 换句话说，找出类似用户购买的用户'A'尚未购买的东西。
我不能说我已经做到了，但我也在认真研究这个问题。 除了Map Reduce范例之外，MongoDB现在（v 2.4.6）已经发现了一个非常强大的聚合管道框架。