Сравнение Redis и MySQL на задаче построения игровых рейтингов

В процессе разработки игр часто возникает задача построения рейтингов игроков. Особенно актуальна эта задача при разработке MMO-игр(MMO=massively multiplayer online) и игр в социальных сетях, так как игроков в таких играх довольно большое количество, и задача построения и отображения рейтинга становится не такой и простой.

Ключевыми аспектами при разработке подсистемы построения игровых рейтингов являются:

• выбор оптимальной схемы хранения и обработки данных
• удобство эксплуатации подсистемы и стоимость её поддержки
• производительность подсистемы на операциях обновления и получения рейтинга
• масштабируемость полученного решения

Для более детального сравнения сосредоточим своё внимание на одной из подзадач: построение глобального рейтинга по всем игровым персонажам. Рейтинг будем строить по одному игровому параметру – количество заработанных игровых денег.

Выбрать оптимальное хранилище данных сейчас не так и просто в связи с огромным обилием различных open-source СУБД, каждая их которых сочетает в себя как достоинства, так и недостатки. MySQL является основной СУБД, используемой в ряде проектов компании и он вышел в финал вне конкурса. В дополнение был проведен анализ имеющейся информации, а также ряд простых тестов производительности(бенчмарков), которые позволили выбрать из всех кандидатов именно Redis(REmote DIctionary Server).

Следующий шаг – это написание простенькой игровой подсистемы, которая будет решать одну из поставленных подзадач. После этого можно проводить детальный анализ по различным параметрам, как объективным: количество операций в единицу времени, объёмы потребляемой дисковой и оперативной памяти, потребление CPU, объём дискового I/O; так и субъективным: сложность кода, удобство сопровождения и доработки кода, удобство API, предоставляемой СУБД.

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

Но большая часть объективной информации получается все-таки экспериментальным путём, т.е. нужны хорошие бенчмарки. Для проверки производительности системы нужно спроектировать и разработать набор тестов, который позволит оценить и сравнить разработанные подсистемы по большинству объективных параметров. Разработанные тесты должны поддерживать запуск с различным уровнем параллелизма(concurrency), что позволит оценить масштабируемость системы.

Кратко о результатах сравнения. Сравнения написанного кода показало, что код работы с рейтингами MySQL и Redis, примерно одинаковой сложности. За исключением того факта, что запросы в MySQL гораздо более сложные, чем в Redis. Асимптотический анализ кода возможен только для Redis-версии, так как для каждой команды Redis можно узнать её стоимость из документации. Оценка алгоритмической сложности MySQL кода может быть только приблизительной, с использованием экспериментальных данных. Результат см. в сводной таблице big_o.jpeg:

Как видим, серьёзной проблемой MySQL является очень дорогое получение страницы рейтинга.

Результат запуска бенчмарков отражен в сводной таблице table.jpeg:

Как видно из таблицы, Redis значительно превосходит MySQL по производительности. На операциях вставки и обновления производительность выше почти в 5 раз, на операциях выборки превосходство просто подавляющее: 230 раз. При этом наличие необходимых индексов в MySQL таблице никак не влияет на производительность теста.

Несмотря на впечатляющие цифры на данном тесте, при анализе пригодности Redis к реализации других подзадач был выявлен ряд недостатков Redis: невозможность мультисортировки, избыточность данных при реализации рейтингов по уровню, проблемы с построением рейтинга среди друзей. Поэтому при решении задач построения различных игровых рейтингов оптимальным решением является использование этих двух СУБД в одной связке.