我有一个在线游戏,我记录了很多游戏统计数据.这些统计表变得很快,我必须要小心,因为只要记录更多的统计数据,一旦表格变得足够大,就会导致游戏的性能变得非常糟糕.

我的策略不是一个很好的策略,就是保持统计表的小.我有一个自动过程,每24小时创建一个新表,防止性能过于失控.但我的解决方案很难看,是统计表的一种“轮换”.我使用innodb并设置了几个索引以提高性能,然后我只保留了30个这些表(每个都是24小时,所以我节省了一个月的统计数据).每24小时,我的自动进程会删除“stats30”表,然后将所有编号的表重命名为更高的数字,然后创建一个名为“stats”的新空白表.这是“实时”表格,其中统计数据被积极记录.

这些表基本上记录了每个玩家与他们交互的游戏中的每个其他玩家之间的每个交易,因此数据呈指数级增长.当一个新的交易发生时,它会检查当天这两个玩家之间的交易是否已经有一行.如果有,它会更新行以更改其事务.否则,它会创建一个新行.一对玩家每天互动1000次,一对互动一次只会在当天的桌子上只有一行.数据库上的每个操作都涉及一个SELECT,然后是UPDATE或INSERT,因此它在读取和写入之间甚至是当前设计的.相对于单个SELECT,UPDATE和INSERT,更广泛意义上的数据读取,即用于分析统计数据和多个玩家,很少进行.每天创建大约150,000行.

我知道这可能会更好.我不能轻易减少我录制的数据量,但我关注的是1.performance和2.simplicity.例如,我可以通过每4小时创建一个新表来提高性能,但是我必须弄乱180个表.相反,我可以通过使用一个表来简化它,然后一切都嘎然而止.

请注意,我确实需要更新这些表中的行,所以我不能使用类似ARCHIVE存储引擎的东西,但我只需要在“实时”统计表上插入或更新.

还存在一个小问题,即当每日轮换过程发生时,当时进入的任何查询都可能丢失. (如果它正在重命名所有表并创建一个新表,新条目可能会失败.)丢失一些插入不是一个大问题,而是一个不会发生此错误的解决方案,或者可以“原子地”完成“ 会更好.

感谢任何可能有用的想法！ 🙂

最佳答案 每天150k行,平均值是多少.一排的大小？

这些行是否包含冗余数据,您可以通过仅保留引用来最小化这些数据？

通常,保持表小,以便索引更新快速通过是一件好事.此外,如上面提到的Ben S,您的查询应至少进行优化,以便无法访问缺少索引的列等.如果您使用EXPLAIN和mysql服务器的慢查询日志,可以找到一些可能的问题搞定了.

可能对性能问题有帮助的一件事是memcached守护进程.使用它你可以延迟写入你的数据库,从而取出一些蒸汽,仍然不会受到脏缓存和类似的困扰.虽然取决于您正在使用的应用程序框架(如果有的话),但需要一些工作才能将其实现到您的应用程序中.

出于存档和统计目的,我建议您查看InfoBright(http://www.infobright.org/).这是一个开源的MySQL代替(基于MySQL).它的目的是成为一个数据仓库商店.您可以将它用于各种高容量数据分析.
它有一个非常好的压缩功能,在我们的例子中,将大约23TB的原始数据减少到大约1.2TB的压缩数据.我想不用说查询特定的压缩数据行可能会非常慢.但对于统计数据来说,它的速度非常快.因此,如果您没有查询特定的行,而是分析诸如“在08年12月到09日之间使用值foo>条更新了多少行”这样的内容,它将为您提供非常好的性能.事实上,当您使用数据库时,它将分析您的使用情况并创建一个知识网格,以优化您的特定查询的数据.

我想到的下一个问题是……如果你只保留一天或几个小时的“仅”统计/会话数据,那么关系数据库是适合这项工作的正确工具吗？
在不知道应用程序的确切性质的情况下,我可以想象某种内存中的会话(例如可以驻留在兵马俑集群中),它们编写事务日志并且每隔一段时间提交它们的数据可能更适合.但正如我所说,这在很大程度上取决于您的应用程序的性质和所涉及的大量数据.