Лидерборд дизайн и производительность в оракуле

Question

Я занимаюсь разработкой игры и использую таблицу лидеров, чтобы отслеживать счет игрока.Существует также требование отслеживать около 200 дополнительных статистических данных.Эти характеристики такие как: убийства, смерти, время игры, использованное оружие, полученные достижения и т. Д.

Что будет интересно игрокам, так это счет, убийства, смерти и время игры.Все остальные характеристики не обязательно должны отображаться в игре, но должны быть доступны, если я хочу их просмотреть или сравнить с другими игроками.Ожидаемое количество игроков, которые будут сохранены в этой таблице лидеров, составляет около 2 миллионов.

В настоящее время дизайн заключается в том, чтобы хранить идентификатор игрока вместе со всеми статистическими данными в одной таблице, например:

player_id, points, stat_1 .. stat_200, date_created, date_updated

Если я хочу показать отсортированную таблицу лидеров по точкам, мне нужно будет поставить индекс науказывает и делает сортировку по нему с помощью запроса выбора и ограничивает результаты, чтобы возвращать, скажем, 50 каждый раз.Есть также идеи, чтобы игрок мог сортировать таблицу лидеров по паре других характеристик, таких как время игры или смерти, максимум до, скажем, 5 сортируемых характеристик.

Число ожидаемых пользователей, играющих в игру, составляетоколо 40к одновременно.Может быть, четверть из них, но это действительно приблизительная фигура, будет активно просматривать список лидеров, остальные просто будут играть в игру и загружать свои результаты, когда они будут закончены.

У меня есть несколько вопросов об этом подходе ниже:

1. Кажется, но у меня есть сомнения, что консенсус в том, что списки лидеров с миллионами записей должныБыть сортируемым по паре статистических данных не очень хорошо масштабируется в РСУБД.Это правильно?

2. Сортирует ли список лидеров по точкам с помощью запроса выбора, предполагая, что у нас есть индекс, будет очень медленным, и если да, то как я могу обойти это?

3. Должен ли я разделить хранение дополнительных статистических данных, которые не должны сортироваться в отдельной таблице, или есть другой, еще лучший подход?

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

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

Cheers

Answer 1

Я недавно работал над игрой с таблицей лидеров, используя MS SQL Server, а не Oracle, и хотя количество записей и игроков не одинаково, вот что я узнал - в ответ на ваш вопросы:

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

2. Нет, это будет быстро.

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

4. Полагаю, вам нужно будет включить кэширование, чтобы достичь упомянутой шкалы; Я бы не стал кэшировать на уровне базы данных (ваша таблица уже фактически является денормализованной, плоской записью - я не думаю, что вы сможете разбить ее намного больше). Не знаю, какие у вас есть другие слои, но я бы посмотрел на то, насколько «кэшируемыми» ваши данные (кажется, что списки лидеров довольно статичны), и кеширую либо в слое непосредственно над базой данных, либо добавьте что-то вроде ehcache перемешать.

Общие баллы:

• Я бы попробовал это, чтобы понять, как это будет работать. Используйте что-то вроде dbmonster, чтобы заполнить тестовую систему миллионами записей, и запросите этого щенка, чтобы понять, что работает, а что нет.
• Как только вы это настроите, я бы потратил на более серьезное тестирование нагрузки и производительности, прежде чем принять решение о добавлении кэширования и т. Д. - чем сложнее вы делаете архитектуру, тем сложнее ее отлаживать, тем дороже она стоит это строить, и чем больше там пойти не так. Поэтому добавляйте кеширование только в том случае, если это действительно необходимо, потому что вы можете доказать - с помощью нагрузочных тестов и тестов производительности - что вы не можете достичь своих целей по времени отклика.
• Хотя это правда, что добавление индексов в таблицу замедляет операторы вставки / обновления / удаления, в большинстве случаев это незначительное наказание - я бы определенно не слишком беспокоился об этом на данном этапе.

Answer 2

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

2) Это будет очень быстро, пока индексы достаточно малы, чтобы поместиться в ОЗУ.После этого производительность занимает большой удар.

3) Иногда вы можете повысить производительность, если добавите все поля, которые вам нужны, в индекс, потому что тогда СУБД не нужно будет обращаться кстол вообще.Этот подход с наибольшей вероятностью сработает, если доступ к полям будет небольшим по сравнению с размером строки.

4) Возможно, Oracle хорошо подойдет для кеширования, но если у вас огромная нагрузкавсе пользователи, выполняющие один и тот же запрос, вероятно, лучше регулярно выполнять этот запрос и сохранять результат в памяти (или в файле с отображением в памяти).Например, если список рекордов доступен 50 раз в секунду, вы можете уменьшить нагрузку, вызванную этим вопросом, на 99%, выгружая его каждые 2 секунды.Мой совет: не делайте этого, если вам это не нужно.Сначала измерьте производительность и добавьте ее, если необходимо.

Answer 3

ме - миллионы записей?не большая таблица.

Я бы просто создал таблицу (избегайте именования "stat_1, stat_2" - дайте им правильные имена, например "Score", "kill_count" и т. д.), добавьте индексыведущие столбцы, по которым пользователи, скорее всего, захотят сортировать (таким образом, Oracle может избежать сортировки, используя индекс для доступа к таблице в отсортированном порядке).

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

Answer 4

Я не люблю таблицы с сотнями столбцов, но это может быть нормально.Лично я предпочел бы иметь отдельную таблицу идентификаторов и таблицу оценок, содержащую идентификатор, типы оценок и значения, которые индексируются только по столбцам идентификаторов.Если вы организуете их как кластер, родительские и дочерние записи все выбираются в 1 IO.

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

Это хорошо подходит для опции Oracle In-Memory Database Cache.См. кэши результатов ..... как насчет сильно измененных данных .Это разумный способ кэширования данных Oracle на сервере приложений.Вы создаете сетку кеша, состоящую как минимум из одного элемента сетки, и для лучшей производительности объединяете их с серверами приложений.Когда вы добавляете сервер приложений, вы автоматически добавляете членов Cache Grid.Он работает очень хорошо, это старая добрая технология TimesTen, которая интегрирована в базу данных.

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