我开始在MySQL开发一个网站分析系统，用于我正在开发的项目，但很快意识到它不足以满足我的需求（在可扩展性，速度等方面）。在做了一些研究之后，MongoDB一直是一个很好的候选者，我唯一的问题是我没有经验，也不知道高性能/大小MongoDB数据库的最佳实践以及我为MySQL做的最佳实践
当用户访问网站时，需要记录标准信息（IP，浏览器信息，网站ID，URL，用户名）。它还需要记录用户访问的每个后续页面（当前时间戳，URL）。如果用户离开网站并在10天后返回，则需要记录该访问并记录它是返回用户（由用户名标识）。
除了记录多个网站的访问量（查看每秒添加的500条记录）之外，它还需要具有报告功能。我很适合生成图表等，但我需要知道如何有效地从数据库中提取数据。我希望能够提供每15分钟显示活动的图表，但如果它更实用，则一小时就足够了。
如果一方认为将来能够进行实时报告会很好，但这超出了当前项目的范围。
现在我已经阅读了http://blog.mongodb.org/post/171353301/using-mongodb-for-real-time-analytics上的文章，但它没有提及任何有关高流量网站的内容 - 它可能只能处理几千条记录。我是否遵循该帖子的概念并直接从该集合中提取报告，或者预先分析数据并将其存档到单独的集合中会更好吗？
对数据插入，数据库结构和报告的任何想法都将非常感激！
答案 0 :(得分：6)
（MySQL）不足以满足我的需求（在可扩展性，速度等方面）
嗯......看来facebook在很大程度上使用了MySQL。谈到NoSQL，我认为它不一定是技术，它的数据结构和算法。
您所面临的是潜在的高写入吞吐量。满足您的问题的高写入吞吐量的一种方法是 sharding ：无论机器有多大以及软件的效率如何，单个机器的写入次数都会受到限制可以处理。分片在多个服务器之间分割数据，因此您可以写入不同的服务器。例如，用户A-M写入服务器1，用户N-Z写入服务器2。
现在，分片是以复杂性为代价的，因为它需要平衡，跨所有分片的聚合可能很棘手，你需要维护多个独立的数据库等。
这是一个技术问题：MongoDB分片相当简单，因为它们支持自动分片，它可以为您完成大部分讨厌的事情。我不认为你需要每秒500次插入，但知道它在那里是很好的。
对于模式设计，重要的是要考虑shard key，它将用于确定哪个分片负责文档。这可能取决于您的流量模式。假设您有一个操作公平的用户。每年一次，他的网站完全疯了，但360天它是较低流量的网站之一。现在，如果您在CustomerId上进行了分片，则该特定用户可能会导致问题。另一方面，如果您在VisitorId上进行了分片，则必须为每个分片点击一个简单的count()。
分析部分在很大程度上取决于您要支持的查询。真正的交易slice&dice相当具有挑战性，特别是如果您想支持近实时分析。一种更简单的方法是限制用户的选项，只提供一小组操作。这些也可以缓存，因此您不必每次都进行所有聚合。
通常，分析可能很棘手，因为有许多功能需要关系。例如，群组分析将要求您仅考虑由特定用户组生成的那些日志条目。对于较小的同类群组，$in查询可以解决问题，但如果我们谈论的是成千上万的用户，那么它就不会这样做。您只能选择一个随机的用户子集，因为这在统计上应该足够，但当然这取决于您的具体要求。
对于大量数据的分析，Map / Reduce派上用场：它将在服务器上进行处理，Map / Reduce也可以从分片中受益，因为每个分片都可以单独处理作业。但是，根据众多因素，这些工作需要一些时间。
我相信blog of Boxed Ice有一些信息;他们肯定有使用MongoDB处理大量分析数据的经验。