对于涉及大量插入的项目的数据库/存储引擎建议？

Question

我正在研究一个每天涉及大量插入的项目。我将有一个用户列表（例如 500k 的用户集），为此我需要每天监视与它们相关的某些活动。

例如，让一组 100 个用户说 U1,U2,...,U100

我需要将他们的每日分数插入到我的数据库中。

考虑用户U1在6月30日-7月6日期间获得的总分如下

June 30 - 99
July 1 - 100
July 2 - 102
July 3 - 102
July 4 - 105
July 5 - 105
July 6 - 107

数据库应该保存每个用户的每日分数，比如

对于用户 U1，

July 1- 1pt (100-99)
July 2- 2pt (102-100) 
July 3- 0pt (102-102) 
July 4- 3pt (105-102) 
July 5- 0pt (105-105) 
July 6- 2pt (107-105) 

同样，数据库应该保存全套用户的每日详细信息。

在以后的阶段，我设想从这些数据中提取汇总报告，例如每天、每周、每月等的总分；并将其与旧数据进行比较。

我需要从头开始。我有使用 PHP 作为服务器端脚本和 MYSQL 的经验。我对数据库方面感到困惑？既然我每天需要处理大约一百万次插入，那么所有的事情应该注意什么？

MySQL 是否符合我的要求，如果是，应该使用什么存储引擎？最初，我设想创建一个带有外键用户 ID 的用户表和带有日期作为字段的月度评分表。后来我得到建议，先将内容写入 csv/excel，然后在特定时间段后将它们加载到表中。

文件插入是否使事情在这方面更有利。

或者我应该尝试其他一些数据库，NoSQL 方法吗？

编辑

我正在总结我的要求，我需要有一个包含一百万用户的数据库，这些用户的积分每天都会作为单独的条目进行更新。这将定期进行，以便每个使用每天都有一个字段显示每日积分，可以每周/每月/每年汇总。我对数据库设计以及部署后可能发生的问题感到困惑。每天做一百万甚至更多的数据库操作。这种情况下如何考虑服务器和其他事情。

任何帮助将不胜感激。提前致谢。

Answer 1

让我们把这个问题分成几个部分。

问：我每天需要插入 1 毫米的行。这是很多吗？

并不真地。1 毫米除以 24 小时除以 60 分钟除以 60 秒，每秒大约可以插入 12 次。从粗略的角度来看，在没有调整的典型商品服务器中每秒看到 1,000 次插入并不罕见。

诚然，您的负载不会像那样完美平均 - 您将有突发负载 - 但我不会基于每秒少于 10k-20k 的插入来做出数据库平台决策。任何平台都可以很好地工作。

问：我应该如何构建数据？

缩小 - 不要考虑表格，考虑数据库。如果您要永久保留这些数据，并且它是真正的仅插入而没有更新，那么您可能想要启动一个新的数据库一段时间。您的插入可能只进入一个数据库中的一个表，但每年都会创建一个新数据库 (MyApp_2015) 并将旧的 2014 数据密封为只读。你可以停止备份（只要你还有一次好的备份），停止做索引维护、统计更新等。

PHP 只需知道用于插入的当前数据库，使您的设计更容易。只要您知道将涉及多个数据库，归档过程就会在很晚以后成为 DBA 的一项任务。

如果您持续每秒执行超过 1,000 次插入，并且您想要更轻松的性能管理，那么我还建议在初始设计中构建分片，而不管数据库平台如何。不要误会我的意思，任何现代数据库每秒都可以处理超过 1,000 次插入，但是现在设计分片只会在以后为您提供更大的灵活性。每秒 12 次插入，不值得设计/测试麻烦。

问：我应该如何做报告？

在理想的世界中，不会针对实时服务器进行报告。针对数据库的还原或复制副本运行报告。这有两件事：减少实时服务器上的负载，并验证您的备份，确保您在其他地方拥有有价值的数据。