Question

我是社交游戏的开发者，我们有近2百万玩家（这个数字正在增长）。

主MySQL数据库服务器具有24 Gb RAM，如果数据库不适用于具有非常大的一个表，则数据库可以适合内存。目前它有近十亿的记录，其大小为33Gb。它具有以下模式：

CREATE TABLE `plant` (
  `player_id` int(10) unsigned NOT NULL DEFAULT '0',
  `id` mediumint(8) unsigned NOT NULL DEFAULT '0',
  `x` tinyint(3) unsigned NOT NULL DEFAULT '0',
  `y` tinyint(3) unsigned NOT NULL DEFAULT '0',
  `distort_step` tinyint(3) unsigned NOT NULL DEFAULT '0',
  `grow_step` tinyint(3) unsigned NOT NULL DEFAULT '0',
  `proto_id` int(10) unsigned DEFAULT '0',
  `yflip` tinyint(4) NOT NULL DEFAULT '0',
  `grow_start` int(10) unsigned NOT NULL DEFAULT '0',
  PRIMARY KEY (`player_id`,`id`)
) ENGINE=InnoDB

我正在考虑如何优化它的以下计划：

使用“archive_”前缀
通过哈希
找出那些没玩过游戏的非活跃玩家，比如一个月。
将他们的记录从大表复制到存档表
标记正在存档的播放器并改为使用存档表无论何时他/她登录
也可以选择通过哈希对原始表进行分区（可选）因为它可能导致大量的停机时间）
如果没有什么可以帮助考虑分片

你怎么看？这听起来像个好计划吗？

Answer 1

我认为你的建议是非常好的，它很简单，可能非常有效。你避开像分区这样的'可怕'的东西。当然，如果你期望有200万玩家一次玩，你需要重新考虑你的方法。

你甚至可以一路走下去，只跟踪哪些“植物”实际上正在积极地玩游戏。我假设你不会为那些现在没玩的玩家更新表格。

您甚至可以根据需要对存档表进行分区，例如通过player_id上的哈希或类似的东西进行分区。

Answer 2

分页表怎么样？然后你可以毫无问题地扩展。如果您担心与Sharding相关的繁重工作，请尝试使用ScaleBase获取透明的分片解决方案

计划优化对非常大的InnodDB表的访问

2 个答案: