1

我是一个社交游戏的开发者，我们有将近 200 万玩家（而且这个数字还在增长）。

主 MySQL DB 服务器有 24 Gb RAM，如果不是一个非常大的表，数据库可以放入内存中。目前它有近 10 亿条记录，其大小为 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

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

  1. 添加带有“archive_”前缀的类似表

  2. 通过哈希对这个新表进行分区

  3. 找出没有玩游戏的不活跃玩家，比如一个月。

  4. 将他们的记录从大表复制到存档表

  5. 标记正在存档的玩家并在他/她登录时使用存档表而不是原始表

  6. 也可以选择通过哈希对原始表进行分区（可选，因为它可能会导致大量停机）

  7. 如果没有什么有助于考虑分片

你怎么看待这件事？这听起来像是一个好计划吗？

4

2 回答 2

1

我认为您的建议是一个非常好的建议，它很简单并且可能非常有效。你避开像分区这样的“可怕”的东西。当然，如果您希望有 200 万玩家同时玩，您将需要重新考虑您的方法。

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

您甚至可以按照您认为合适的方式对存档表进行分区，例如通过 player_id 上的哈希或类似的方式。

于 2011-04-25T10:44:16.667 回答
0

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

于 2011-06-15T13:55:29.073 回答