Mysql 用于提供大量历史信息的数据库服务器体系结构

我们有一个web服务，允许固定数量的用户查看每天早上收集和插入的每日位置数据。我们还允许访问历史记录

我们的测试环境包括两个负载平衡的web服务器、一个主mysql和两个负载平衡的mysql从服务器。出于开发目的，这很好，但只有大约50个用户同时处理数据

我们很难规划在用户负载范围内维持正常运行所需的服务器体系结构。 我们的限制是众所周知的，包括每天插入的数据量

考虑到我们需要在<10%的时间内访问历史数据，设计系统的最佳架构是什么

已知内容：

• 我们的用户设置为125000，估计每天有5000到20000个活跃用户，这一点不会改变
• 我们的服务每天收集大约5760000条信息记录。（如果我们将所有数据压缩到一个日表中，可以压缩到大约120000条日记录，我们被告知这是一个大禁忌“所以要规范化它”）
• 用户可以随意浏览其历史信息，但他们通常只对其每日、每周、每月信息感兴趣
• 我们不需要数据检索非常快
• 如果用户愿意，可以查看历史数据（想想地下天气，查看1960年的温度）
• 我们的数据聚合是非常可预测的。到目前为止，我们拥有长达5年的信息，数据库大小约为每年80GB，包括索引
• 尽管用户很少访问任何超过1年的数据，但我们仍然希望提供这种功能
• 用户可以选择接收包含每日、每周和每月信息的电子邮件，因此我们还将每天处理一次收到的数据以发送电子邮件

测试环境：

目前，我们有一个大型ec2实例，所有表上都有一个标准的500gb ebs，使用mysql和innodb，还有两个小型从机进行读取。
包含用户信息的表将位于单独的服务器中

• 让不同的数据库服务器将当月数据保存在一个数据库中，将历史数据保存在另一个数据库中是否可行？还是将其与主动访问的数据保存在同一服务器的单独表中更好？我们考虑在几个月的活动数据（7GB）中使用一个单独的小型磁盘高内存数据库服务器，当它成为历史数据时，我们将其移动到另一台服务器

• 我们听说过集群，但同时也听说除非用尽所有其他选择，否则最好远离集群

每天20000活跃用户[用户]

嗯，即使每个用户每天有10次点击，我们说的是平均

20_000 users * 10 hits/day / (24*3600.0 seconds/day) = ~2 hits per second.

---

您的峰值负荷将是平均负荷的4到10倍。所以也许你每秒会有20次点击。你又在担心什么呢？

你设计了一个可操作的数据库，它是关于如何访问和使用的，而不是需要存储什么，也不是“我们可能需要……”

关系模型非常适合于临时查询和假设场景。随着负载的增加和数据大小的增加，这些临时一次性查询变得越来越少，也越来越不可行。最终，您在“生产”服务器上根本负担不起它们，因为它们不可避免地会干扰生产

我提到这一点是因为你提到：

我们的服务每天收集大约5760000条信息记录。（如果我们将所有数据压缩到一个日表中，可以压缩到大约120000条日记录，我们被告知这是一个大禁忌“所以要规范化它”）

如果您的用户只对120000条摘要记录感兴趣，那么将570万行存储到其他地方。它只是占用了空间和性能。一个好的、坏的查询可能是一个I/O绑定、CPU绑定、数据库缓存崩溃的怪物。这正是您在生产系统中不想要的

因此，您需要根据用户查询的内容、他们真正需要的内容以及他们需要的时间来进行设计。如果用户可以发出异步请求：“嗨，我希望这个历史查询基于这个条件”，然后让他们排队，然后在准备好后给他们发送电子邮件，或者根据需要安排每日、每周、每月的作业

如果您可以将活动数据保存在7GB的RAM中，那么这将是一个很大的帮助。在慢速磁盘存储上执行慢速导入操作，每晚将摘要数据发送到基于RAM的系统。另外，不要忽视SSD。SSD非常非常快。硬盘驱动器是新的磁带驱动器

正如@BraveNewCurrency所指出的，20000个活跃用户不是很有意义，对于简单的查询来说也不是很多。超过24小时了吗？是从9点到5点吗？当市场关闭时，它们是否都会激增？调整你的峰值负荷，然后调整一些

至于数据库大小，如果您使用适当的统计数据在小范围内执行简单的索引查询，甚至针对大表，那么数据库的总体大小基本上是没有意义的。如果你在做“给我这2000万排中最大的10件事”，那么你就注定要失败。如果像这样的查询是常见和流行的，它们需要特别注意。从索引中提取小部分是相当快的。在大型数据集上进行大量的汇总、计数、平均值和排序是毁灭性的。即使有行限制

如果您这样做：

SELECT ... FROM BIG_O_TABLE ORDER BY NON_INDEXED_COLUMN LIMIT 10

在20M行表上，您将对整个20M行表进行排序。每一个单身。时间然后得到最低的10行

因此，您需要专注于向用户提供的活动查询，并围绕这些查询进行设计。如果要管理多个数据库，请执行您的过程以确保完整性，并始终存档和维护原始数据，以便能够