我们有一项网络服务，允许固定数量的用户查看每天早上收集和插入的每日位置数据。我们还允许访问历史。
我们的测试环境包括两个负载均衡的Web服务器，一个主mysql和两个负载均衡的mysql从服务器。出于开发目的，这种方法很好，但只有大约50个用户同时处理数据。
我们很难规划在用户负载范围内维持正常运行时所需的服务器架构。 我们的约束是众所周知的，包括每天插入的数据量。
考虑到我们需要访问有关＆lt;的历史数据，我们设计系统的最佳架构是什么？ 10％的时间？
众所周知：
测试环境：
我们目前有一个大型的ec2实例，标准的500gb ebs使用mysql和innodb在所有表格上，有两个小的奴隶用于读取。
我们包含用户信息的表将位于单独的服务器中。
让不同的数据库服务器将当前月份的数据保存在一个数据库中，将历史数据保存在另一个数据库中是否可行？或者将它保存在与主动访问数据相同的服务器的单独表中是否更好？我们考虑为几个月的活动数据（7GB）设置一个单独的小磁盘高内存数据库服务器，并且当它成为历史数据时，我们将其移动到另一个服务器
我们听说过群集，但同时也听说过要远离它，除非所有其他选项都用完了。
答案 0 :(得分：1)
您设计了一个关于如何访问和使用的操作数据库，而不是需要存储的数据库，而不是“我们可能需要......”。
关系模型非常适合即席查询，并且可以播放场景。随着负载的增加和数据大小的增加，这些临时的一次性查询变得越来越少，而且不太可行。最终，你在“生产”服务器上根本买不起它们，因为它们不可避免地会干扰生产。
我提到这个是因为你提到过：
我们的服务每天收集大约5,760,000条信息记录。 （如果我们将所有数据压缩到每日表中，可以浓缩到大约120,000个日常记录，我们被告知这是一个很大的不可以“正常化”）
如果您的用户只对120,000个摘要记录感兴趣，那么将5.7M行存储在其他位置。它只占用了空间和性能。一个不错的，糟糕的查询可以是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个最低行。
因此，您需要专注于您向用户提供的有效查询，并围绕它进行设计。如果您管理的是一个以上的数据库，并且始终存档和维护原始原始数据，则可以使用您的程序来确保完整性，以便能够在需要时重建数据库，特别是如果一个人宕机并离开与另一个同步。
答案 1 :(得分：0)
每日活跃20,000 [用户]
嗯，即使每个用户每天有10次点击，我们也谈论平均值
20_000 users * 10 hits/day / (24*3600.0 seconds/day) = ~2 hits per second.
您的峰值负荷将是平均值的4倍到10倍。所以也许你每秒会有20次点击。你又担心什么？