数据库体系结构，每天有数百万个新行

Question

我需要为大量网站实施定制开发的网络分析服务。这里的关键实体是：

• 网站
• 访问者

每个唯一身份访问者在数据库中都会有一行包含着陆页，时间，操作系统，浏览器，引荐来源，IP等信息。

我需要对此数据库进行聚合查询，例如'COUNT所有以Windows为操作系统且来自Bing.com的访客'

我有数百个网站需要跟踪，这些网站的访问者数量从每天几百到几百万不等。总的来说，我希望这个数据库每天增长大约一百万行。

我的问题是：

1）MySQL是否是一个很好的数据库用于此目的？

2）什么是一个好的架构？我正在考虑为每个网站创建一个新表。或者，如果现有表中的行数超过100万（我的假设是正确的），则可能从单个表开始，然后生成一个新表（每日）。我唯一担心的是，如果一个表变得太大，SQL查询会变得非常慢。那么，每个表应该存储的最大行数是多少？此外，MySQL可以处理的表数量是否有限制。

3）建议对数百万行进行聚合查询吗？我准备等待几秒钟来获得此类查询的结果。这是一个好的做法还是有其他方法来进行聚合查询？

简而言之，我正在尝试一种设计大规模数据仓库的设置，这将是重写。如果你知道任何已发表的案例研究或报告，那就太棒了！

Answer 1

如果您正在讨论大量数据，请查看MySQL partitioning。对于这些表，按数据/时间划分肯定会有助于提高性能。有一篇关于分区here的文章。

查看创建两个独立的数据库：一个用于写入的所有原始数据，具有最小的索引;第二次使用汇总值进行报告;使用批处理从原始数据数据库更新报告数据库，或使用复制为您执行此操作。

修改

如果您希望对汇总报告非常聪明，请创建一组汇总表（“今天”，“一周到头”，“一个月到一个月”，“按年”）。每天或“实时”从原始数据汇总到“今天”;每晚从“白天”到“一周到周”汇总;每周从“一周到一天”到“一个月到一天”等。执行查询时，加入（UNION）适合您感兴趣的日期范围的表格。

编辑＃2

每个客户端使用一个数据库模式，而不是每个客户端一个表。根据客户端的大小，我们可能在单个数据库实例中有多个模式，或者每个客户端有一个专用数据库实例。我们使用单独的模式进行原始数据收集，并为每个客户端使用聚合/报告。我们运行多个数据库服务器，将每个服务器限制为单个数据库实例。为了实现弹性，可以跨多个服务器复制数据库并进行负载平衡以提高性能。

Answer 2

以数据库不可知的方式提出一些建议。

最简单的理由是区分读密集表和写密集表。可能最好创建两个并行模式每日/每周模式和历史模式。可以适当地进行分区。可以想到批处理作业使用来自每日/每周架构的数据来更新历史架构。在历史模式中，您可以为每个网站创建单独的数据表（基于数据量）。

如果您感兴趣的是聚合统计数据单独（可能不为真）。最好有一个汇总表（每月，每天），其中存储摘要，如总的unqiue访客，重复访客等;这些汇总表将在一天结束时更新。这样可以即时计算统计数据，而无需更新历史数据库。

Answer 3

您绝对应该考虑跨数据库或模式按站点拆分数据 - 这不仅使备份，删除等单个站点/客户端变得更加容易，而且还消除了确保没有客户可以看到任何其他任何其他内容的麻烦客户数据意外或编码不良等。这也意味着更容易做出有关分区的选择，超过数据库表级分区的时间或客户等。

另外你说数据量是每天100万行（这不是特别重，并且不需要巨大的咕噜声来记录/存储，也不需要报告（尽管如果你在午夜生成500份报告，你可能会logjam）。但是你也说过一些网站每天有100万访问者，所以也许你认为太保守了？

最后，你没有说你是想要实时报告la chartbeat / opentracker等还是像谷歌分析这样的周期性刷新 - 这对你的存储模型从第一天开始就会产生重大影响。

中号

Answer 4

你真的应该测试前进的方向，将模拟环境尽可能接近现场环境，使用“真假”数据（正确的格式和长度）。基准查询和表结构的变体。既然您似乎了解MySQL，那就从那里开始。设置一些用查询轰炸数据库的脚本不应花费你那么长的时间。使用您的数据研究您的数据库的结果将有助于您了解瓶颈会发生的位置。

不是解决方案，但希望有一些帮助，祝你好运：）