用于提供大量历史信息的数据库服务器架构 [关闭]答案

【问题标题】：Database Server architecture for the availability of large amounts of historical information [closed]用于提供大量历史信息的数据库服务器架构 [关闭]
【发布时间】：2013-10-20 21:00:04
【问题描述】：

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

我们的测试环境包括两台负载均衡的web服务器，一台主mysql，两台负载均衡的mysql从服务器。出于开发目的，这可以正常工作，但只有大约 50 个用户同时处理数据。

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

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

已知情况：

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

测试环境：

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

让不同的数据库服务器将当前月份的数据保存在一个中，并将历史数据保存在另一个中是否可行？还是将其保存在与主动访问的数据相同的服务器的单独表中更好？我们考虑为数月的活动数据 (7GB) 配备一个单独的小型磁盘高内存数据库服务器，当它变成历史数据时，我们将其移至另一台服务器
我们听说过集群，但同时也听说要远离它，除非用尽所有其他选项。

【问题讨论】：

“考虑到我们需要在不到 10% 的时间内访问历史数据，我们设计系统的最佳架构方式是什么？” - 聘请顾问。
访问历史数据的时间少于 10%？我们不需要经常访问数据，我们只需要在用户请求时“有权”访问它。

标签： mysql database architecture scalability

【解决方案1】：

您设计一个可操作的数据库，考虑如何访问和使用它，而不是需要存储什么，而不是“我们可能需要......”。

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

我提到这个是因为你提到了：

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

如果您的用户只对 120,000 条摘要记录感兴趣，则将 570 万行存储在其他地方。它只是在这里占用空间和性能。一个好的、坏的查询可能是 I/O 绑定、CPU 挂钩、DB 缓存粉碎怪物。正是您不希望在您的生产系统上出现的东西。

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

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

正如@BraveNewCurrency 所说，20,000 个活跃用户并不是很有意义，对于简单的查询来说也不是很多。超过24小时了吗？它会从 9 飙升到 5 吗？当市场收盘时，它们都会飙升吗？调整您的峰值负载，然后再调整一些。

至于数据库大小，如果您在小范围内进行简单的索引查询，并使用适当的统计信息，甚至针对大型表，那么数据库的整体大小几乎没有意义。如果你正在做“在这 20M 行中给我 10 个最大的东西”，那么你就完蛋了。如果这样的查询很常见且很受欢迎，则需要特别注意。从索引中取出一小部分是相当快的。对大型数据集进行大量汇总、计数、平均和排序是毁灭性的。即使有行限制。

如果你这样做：

SELECT ... FROM BIG_O_TABLE ORDER BY NON_INDEXED_COLUMN LIMIT 10

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

因此，您需要专注于向用户提供的活动查询，并围绕它进行设计。如果您管理的数据库不止一个，请执行您的程序以确保完整性，并始终存档和维护原始原始数据，以便在需要时能够重建数据库，尤其是当一个数据库出现故障并退出时与其他人同步。

【讨论】：

威尔，我相信我对“冷凝”的解释有点糟糕。我们获得的数据以半小时为间隔。我的意思是，该表没有标准化，而是有 48 个收集数据相关的列，而不是每条记录只有 1 个，因此 5,760,000/48 = 120,000。无论如何，在我们的案例中，数据库大小似乎不如结构重要。如果随着数据变大而出现问题，则表结构或目标一开始就是错误的。让我再研究一下我们的系统，我会回复你的其他观点。
我们可以轻松地将活动数据保存在 ram 中。 31 天的数据量约为 2.66075 GB。到目前为止，我们似乎正在寻找具有高磁盘容量的“历史”数据库服务器，以及用于活动数据的高内存数据库服务器。

【解决方案2】：

20,000 日活跃 [用户]

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

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

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

【讨论】：

我们担心我们当前的数据库实施会在每天新增 570 万条记录 + 5 年历史数据的情况下迅速降低性能。如您所说，webapp 可以轻松处理平均每秒 2 次点击，但是我们假设（可能是错误的）我们很快就会达到由于数据大小增加而导致读/写性能下降的地步。服务器。