MySQL InnoDB большой стол: осколок или добавить больше оперативной памяти?

Question

Ребята, я разработчик социальной игры, и в ней уже 700 000 игроков, и каждый день регистрируется около 7 000 новых игроков, около 5 000 игроков постоянно онлайн.

Сервер БД работает на довольно мощном оборудовании: 16-ядерный ЦП, 24 ГБ ОЗУ, RAID-10 с BBU на 4 дисках SAS.Я использую сервер Percona (исправлен MySQL-5.1), и в настоящее время буферный пул InnoDB составляет 18 Гб (хотя согласно innotop доступно только несколько свободных буферов).Сервер БД работает довольно хорошо (2k QPS, iostat% util - 10-15%, почти всегда 0 процессов в состоянии "b" в vmstat, loadavg - 5-6).Однако время от времени (каждые несколько минут) я получаю около 10-100 медленных запросов (где каждый может длиться около 5-6 секунд).

В базе данных MySQL есть одна большая таблица InnoDB, которая занимает больше всего места.У него около 300 миллионов строк, его размер около 20 Гб.Конечно, эта таблица постепенно растет ... Я начинаю беспокоиться, что это негативно влияет на общую производительность базы данных.В ближайшем будущем мне придется с этим что-то делать, но я не уверен, что именно.

В основном вопрос сводится к тому, стоит ли осколок или просто добавить больше оперативной памяти.Последнее проще, конечно.Похоже, я могу добавить до 256 Гб оперативной памяти.Но вопрос в том, стоит ли мне уделять больше времени внедрению шардинга, поскольку он более масштабируемый?

Answer 1

Шардинг кажется разумным, если вам нужно все 300 м + рядов. Сейчас может быть трудно измениться, но когда ваш стол будет расти и расти, наступит момент, когда никакое количество барана не решит вашу проблему. С такими огромными объемами данных, возможно, стоит использовать что-то вроде couch db, поскольку вы можете хранить документы с данными, а не с строками, т. Е. 1 документ может содержать все записи для отдельного пользователя.

Answer 2

I'm getting about 10-100 slow queries(where each may last about 5-6 seconds).

Цитата комментария: Database is properly normalized. The database has many tables, one of them is really huge and has nothing to do with normalization. Когда я читаю это, я бы сказал, что это связано с вашими запросами .. не имеет никакого отношения к вашему оборудованию .. Средние компании мечтают о том, какой у вас сервер!

Если вы пишете плохие запросы, не имеет значения, насколько хорошо нормализуются ваши таблицы, это будет медленным.может быть, у вас есть что-то о этом , это почти аналогичный вопрос с ответом (база данных медленная и все в таком духе).

Также думали об архивировании некоторых вещей?Например, из этих 300 миллионов он начался с идентификатора 1, так что этот идентификатор все еще используется?если нет, то почему бы не заархивировать его в другую базу данных или таблицу (я бы порекомендовал базу данных).Я также считаю, что не каждый 700k пользователей регистрируется каждый день (если вы получили уважение! Но я в это не верю).

Вы также сказали «Эта таблица содержит предметы, специфичные для игрока», какие именно предметы?

Еще один вопрос, можете ли вы опубликовать некоторые из ваших «медленных» запросов?

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

Answer 3

Похоже, ваша основная таблица базы данных может использовать некоторую нормализацию. Вся ли ваша информация содержится в этой одной таблице, или вы можете разделить ее на меньшие таблицы? Нормализация может вызвать небольшой скачок производительности, но по мере роста вашей таблицы это будет перегружено дополнительной обработкой, связанной с доступом к огромной монолитной таблице.