Планирование оптимизации доступа к действительно большому столу InnodDB - PullRequest
Новая
       26

Планирование оптимизации доступа к действительно большому столу InnodDB

1 голос
/ 25 апреля 2011

Я разработчик социальной игры, в которой у нас почти 2 миллиона игроков (и это число растет).

Главный сервер БД MySQL имеет 24 ГБ ОЗУ, и база данных может поместиться в память, если бы не одна таблица, которая имеет действительно большой размер.В настоящее время он имеет почти миллиард записей и его размер составляет 33 Гб.Он имеет следующую схему: 

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. Если ничего не помогаетподумай о шарде

Что ты думаешь об этом?Это похоже на хороший план?

Ответы [ 2 ]

1 голос
/ 25 апреля 2011

Я думаю, что ваше предложение очень хорошее, простое и, вероятно, очень эффективное.Вы держитесь подальше от «страшных» вещей, таких как разбиение.Конечно, если вы ожидаете, что 2 миллиона игроков будут играть одновременно, вам нужно переосмыслить свой подход.

Вы можете даже пройти весь путь и только отслеживать, какие «растения» действительно активно играют в игру.игра ПРЯМО СЕЙЧАС.Я предполагаю, что вы никогда не будете обновлять таблицу для игроков, которые сейчас не играют.

Вы даже можете разделить архивные таблицы, как считаете нужным, например, путем хеширования на player_id или чего-то подобного.

0 голосов
/ 15 июня 2011

Как насчет шардинга стола?Тогда вы можете масштабировать без каких-либо проблем.Если вы беспокоитесь о тяжелом подъеме, связанном с Sharding, попробуйте ScaleBase для прозрачного решения для шардинга

...