Joshua Butcher - Базы данных в онлайн играх (перевод с. англ.

Базы данных в онлайн играх

Автор: Joshua Butcher

Перевод: Черняев Антон

Источник: http://www.severalnines.com/sites/default/files/docs/Severalnines_WP_Databases_Social_Gaming.pdf

1. Введение

Многопользовательские онлайн игры являются многопользовательскими видео играми, способными поддерживать тысячи игроков одновременно. Они играют через интернет и подключаются через персональные компьютеры, игровые приставки или даже смартфоны. Игра позволяет игрокам всего мира взаимодействовать, сотрудничать и конкурировать друг с другом на большом пространстве. С появлением платформы социальных сетей, наблюдался взрыв казуальных игр, названных социальными играми. MMOG фактически переехала от сообщества хардкор геймеров в сообщество мейнстрима. Например, Веселая ферма имеет 228 миллионов активных пользователей и 23 миллиона ежедневных пользователей, в основном из Азии. World of Warcraft имеет более 11 миллионов активных пользователей ежемесячно.

Caprica, приквел к популярному и культовому сериалу «Звездный крейсер «Галактика», исследует будущее онлайн игр и их потенциал. То, что кажется выдумкой, скоро может стать игровой реальностью. Sony Playstation Home представляет собой виртуальный мир, где пользователи эволюционируют в сложной онлайн игре с миллионами людей со всего мира. Пользователи имеют свои собственные аватары, собственные квартиры, где они могут оборудовать ее с помощью собственной купленной виртуальной фурнитурой. Они идут посмотреть последние фильмы из «реального» мира – с помощью Playstation Home. Похоже, что мы в одном шаге от параллельного виртуального мира Caprica и набирающих сознания роботов.

Однако в современных онлайн играх существует необходимость в мощных системах баз данных, чтобы контролировать всю виртуальную активность.

MMOG содержит большое количество пользователей и все эти игроки могут взаимодействовать друг с другом в любой момент времени. Из-за масштаба игровая вселенная может быть разбита на куски несколькими способами. Один из путей это когда осколки мира, уменьшенные вселенные, развернуты на сервере. Другой способ - это удерживать определенное число пользователей на завершенной вселенной или игровом поле. Другие игры могли бы фигурировать как одна вселенная, которая разделена и размещена на различных серверах. Игроки, которые входят в определенный сервер, будут находиться в одной части Вселенной, они будут нуждаться в переключении серверов, чтобы попасть в другую часть мира.

MMOG – приложения работающие с данными, и здесь используются базы данных, чтобы удовлетворить жесткие требования с точки зрения производительности, доступности и масштабируемости.

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

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

2. Технические и бизнес проблемы

Взрыв социальных игр произошел несколько лет назад, и есть несколько возможных объяснений этому:

Легкое обучение и игра
Скорее всего в эти игры будет играть мейнстрим, чем хардкорный игрок
Вирусные социальные сети способствовали распространению социальных игр по аудитории
Использование социального графа для получения совместного удовольствия с реальными друзьями
Использование социальных связей и коммуникаций API, чтобы сделать игру более привлекательной.
Аудитория: дети являются наибольшими потребителями игр, будь то в офлайн или онлайн режиме. Они играют на своих

Создание инфраструктуры для обработки социальной MMOG является сложной задачей, и включает в себя:

Расширяемость и эластичность по требованию. Трудно предсказать успех новой игры, однако успешная игра может привлечь внимание миллиона игроков.
Высокая доступность: игроки со всего мира, играющие в любое время дня. Таким образом, система должна работать 24*7.
Данные должны распространяться по всему миру.
Предсказуемость задержки.
Управляемость: сервер COTS может обрабатывать около 10000 пользователей, значит для миллиона пользователей понадобится 100 серверов.
Стоимость: Онлайн игры являются конкурентоспособной промышленностью, начиная от свободно распространяемой до игры, с оплатой 15$ для каждого игрока. Эффективные операции также являются важной бизнес целью. Существует такой подход: игра бесплатна, но некоторые ее части являются платными (обмундирование, увеличение количества опыта и т.д.).

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

3. Моделирование данных и осколков

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

Для массовых игр на уровне базы данных необходимо решить следующие требования:

До 30000 TPS на миллион одновременных пользователей
Масштаб от нескольких тысяч пользователей до 2-3 миллионов одновременных пользователей
Высокая доступность
Синхронная репликация данных для сессии
Нет потери данных для пользователей, которые потеряли связь
Ведение архива сроком на семь лет
Разделение данных для экстремальных скоростей там, где это необходимо
Предсказуемость задержки для сглаживания геймплея

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

Сохраняемость данных имеет важное значение для соблюдения правовых норм, когда речь идет о:

Счетах
инвентаризации
наименовании персонажа
информации об учетных записях

Сохраняемость данных имеет важное значение для профессиональной репутации, когда речь идет о:

данные о трофеях
обмен сообщениями

Скорость имеет важное значение для:

данные сессии
данные персонажа
инвентаризация
leaderboards

Целостность данных является обязательным для:

сессии
leaderboards

Целостность для leaderboards является произвольной, потому что там должны быть постоянные данные, которые могут использоваться для восстановления leaderboards, если они будут потеряны.

Разработчики игр также хотят хранить данные в базах данных, таких как JSON или в каком-нибудь другом сериализированном С/С++ объекте. Приложение должно иметь возможность прочитать в одной BLOB и не нужно конвертировать поле базы данных в C/C++/Java поле. Такая практика может обескуражить. Например, разработчики игр могут использовать сервер базы данных для посылки запросов на специфические части данных внутри JSON/BLOB.

Другую вещь, которую необходимо учитывать, это то, что MMOG – мир, который компании хотят ласкать снова и снова. Это значит, что это мир, и все, что находится в виртуальном мире реально для пользователя. Это значит игровые компании не хотят терять своих клиентов.

Следующая секция – рекомендации того как разбить схему каждой части записей на каждом мастер/раб кластере. Типичное копирование включает одного мастера и минимум двух рабов на каждом из центров данных. Избыточность позволяет разработчику взять одного раба офлайн для технического обслуживания, резервного копирования, создания нового мастера/раба и т.д., пока раб служит для подачи живого трафика.

3.1 Игровые аккаунты (юридическая ответственность)

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

Игровые аккаунты это не профиль пользователей. Это очень важно в наши дни. Единственный игровой аккаунт может иметь много профилей связанных с ним.

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

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

Задержка репликации между центрами обработки данных отлична, потому что пользователи должны коннектится только к одному дата-центру в некий промежуток времени и получать доступ к услугам в любой момент – даже при сбое. Любые обновления главного сервера должны быть доступ как можно быстрее, чтобы рабы могли считывать быстрее информацию.

Типичная конфигурация оборудования может выглядеть следующим образом:

Мастер: 16G RAM, 4 Disk RAID-10

Раб: 3x16G of RAM, 4 Disk RAID-10

3.2 Профиль пользователя (юридическая ответственность)

Примечание: компания несет ответственность за данную информацию

Профиль пользователя – персонаж, созданный в MMOG. В эти дни, MMO игры имеют более пяти персонажей.

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

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

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

Типичная конфигурация оборудования может выглядеть следующим образом:

Мастер: 16G RAM, 4 Disk RAID-10

Раб: 3x16G of RAM, 4 Disk RAID-10

3.3 Подключение друзей

Эти данные распределены сайтом игры. Например, в Ultima Online, Вы можете получить доступ к информации о персонаже с помощью сайта, и в некоторых случаях изменить ее. Это также способ сказать: «Эй, посмотри на характеристики моего персонажа» друзьям или на социальных сайтах разместив ссылку на персонажа, без необходимости запуска игры, чтобы увидеть этот персонаж/ аватар.

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

Так же, как для аккаунта и информации о профиле, задержка репликации будет замечательной, так как пользователи подключены только к одному серверу в некий момент времени.

Это было бы хорошей идеей, чтобы ограничить количество друзей на профиль пользователя, чтобы было легче предсказать, как эти данные должны масштабироваться. Эти данные должны быть легко доступными, для их считывания из базы данных как можно быстрее. Эти данные могут быть в кэше локального сервера игры, хотя лучше использовать кэширование уровня, как Memcached или Redis.

Типичная конфигурация оборудования может выглядеть следующим образом:

Мастер: 16G RAM, 4 Disk RAID-10

Раб: 3x16G of RAM, 4 Disk RAID-10

3.4 Обмен сообщениями (в игре) (юридическая ответственность)

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

Игроки могут посылать сообщения друг другу, но не должны быть подключены одновременно для того, чтобы общаться. Они могут оставить автоматические сообщения друг другу, пока игра запущена.

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

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

Количество сообщений будет расти и срок их жизни можно ограничить, например 30 дней, или когда аккаунт был признан не активным в течении 6 месяцев. Использование шаблонов сообщений будет меняться, некоторые игры используют много сообщений, некоторые используют их редко. В некоторых случаях, разработчики игр могут использовать кэширование. Memcached является хорошей рекомендацией здесь.

Типичная конфигурация оборудования может выглядеть следующим образом:

Мастер: 32G RAM, 6 Disk RAID-10

Раб: 3x16G of RAM, 6 Disk RAID-10

3.5 Счета (юридическая ответственность)

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

Данная информация не должна использоваться совместно с игровым сервером и должна быть одной из менее используемой информацией.

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

Рекомендуемая конфигурация может выглядеть следующим образом.

Мастер (Чтение/Запись): 16G RAM,8 Disk RAID-10

Раб (Резервное копирование): 1x16G of RAM, 4 Disk RAID-10

3.6 Права (пособия, пользовательское соглашение)

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

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

Это будут одни из самых маленьких и наименее используемых данных. Пособия считываются из базы данных игровым сервером только при входе в систему, так что игровой сервер знает, к чему пользователь имеет доступ.

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

Этот продукт, как правило, живет на аппаратных учетных записях пользователей.

3.7 Сессии

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

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

Рекомендуемая конфигурация может выглядеть следующим образом.

Мульти-Мастер: 20 х 32G RAM,6 Disk RAID-10

3.8 Инвентарь

Данные инвентаря также ценны для пользователя, как и данные о счете. Здесь описывается, как пользователь взаимодействует с внешней средой. Данные инвентаря – это виртуальные вещи, которые уникально представляют цифровую жизнь игрока в игре.

Разработчики игры, как правило, кэшируют эти данные в банке памяти сервера. Диски должны быть щедрыми в скорости и объеме, потому что инвентаризация пользователя может занимать большое пространство, и проверять каждые Х минут для множественных пользователей, что может увеличивать нагрузку на диск.

Эти данные обычно кэшируются сервером MMOG на осколке. Они не могут быть прочитаны, если были загружены. Игровой сервер будет кэшировать состояние данные об инвентаре каждые Х минут. Все это будет хорошо до тех пор, пока кусок сервера не упадет.

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

Рекомендуемая конфигурация может выглядеть следующим образом.

Мастер: 16 RAM,6 Disk RAID-10

Раб: 3x16G of RAM, 6 Disk RAID-10

3.9 Leaderboards

Leaderboards в конце дня изменчив. Люди хотят знать, как они делают что-то против кого-то, но leaderboards постоянно меняется постоянно, он больше не действителен. Они могут быть восстановлены, если потерпят крах.

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

3.10 Достижения/ Трофеи

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

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

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

Рекомендуемая конфигурация может выглядеть следующим образом.

Мастер: 16G RAM,6 Disk RAID-10

Раб: 3x16G of RAM, 6 Disk RAID-10