Опция NoSql для MMORPG

Question

Мне было интересно, какие преимущества может иметь опция nosql вместо или в сочетании с rdbms для типичной MMORPG. В частности, мне любопытно, как целостность данных сохраняется в nosql.

Я приведу несколько примеров, где я немного запутался относительно того, как будет работать логика сервера:

Сценарий 1: допустим, игроки A и B атакуют игрока C одновременно. Параметр player_stats.kill_count обновляется в зависимости от того, кто из игроков убил игрока C. Обычно этот запрос AttackPlayerRequest можно обработать следующим образом:

Начать транзакцию { attacker.health = newAttackerHealth

defender.health = newDefenderHealth

если защитник. Здоровье == 0 { attacker.stats.kills + = 1 } }

Сценарий 2: Игрок А продает предмет продавцу NPC и быстро пытается сбросить тот же предмет из своего инвентаря на землю. (Даже если ваш пользовательский интерфейс запрещает это, они, безусловно, могут просто помещать события в провод).

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

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

Answer 1

Все зависит от того, как работает ваша игра.

NoSQL

Farmville на Facebook использует NoSQL. Farmville действует как 1 огромный сервер, на котором все находятся. Допустим, Farmville использует 3 компьютера в своем кластере баз данных. Компьютер 1 в Сан-Диего. Компьютер 2 в Нью-Йорке. Компьютер 3 в Москве. Я вхожу в Facebook из Сан-Диего, поэтому я подключитесь к базе данных здесь. Я поднимаюсь и выхожу. В конце концов Компьютер 1 расскажет компьютерам 2 и 3 о том, как я выровнялся, но может пройти около часа, прежде чем кто-то в России увидит эти изменения в моей учетной записи.

Масштабирование NoSQL так же просто, как добавление другого компьютера в кластер и указание веб-сайту в этом регионе использовать этот компьютер.

SQL

Есть несколько способов заставить SQL работать, но я объясню способ сделать его похожим на NoSQL

В каждом дата-центре будет 10 игровых серверов, каждый со своей базой данных SQL + 1 база данных субмастера. База данных субмастера поделилась информацией между всеми 10 серверами, поэтому если вы войдете на сервер 1 и создадите персонажа Джона Доу, а затем выйдете из системы, сервер 10 получит вашего персонажа, если вы войдете на этот сервер следующим.

Sub Master затем делится своей информацией с Master Server в вашем главном офисе. Мастер-сервер затем поделится Джоном До с каждым другим субмастером во всех других дата-центрах, и эти субмастера обновят свои игровые серверы. Эта конфигурация позволит вам войти на сервер Weed в Сан-Франциско, сыграть вашего персонажа, выйти из системы, войти на сервер Vodka в Москве и по-прежнему видеть вашего персонажа.

Такие игры, как World of Warcraft, используют SQL, но доступны только некоторые части базы данных. Это позволяет уменьшить размер базы данных на каждом компьютере, а также снизить требования к оборудованию.

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

Answer 2

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

Это много данных, но не так много, как каждое боевое взаимодействие.

Answer 3

MMORPG, которые беспокоятся о задержке, обычно работают на одном сервере и хранят все, кроме информации об объектной модели, в оперативной памяти.Все, что связано с боевой средой, беспокоится о задержке.

Все, что использует жесткий диск, будь то RDBMS или NoSQL, является плохой идеей в боевой среде.Обновлять и обмениваться данными настройки, положения, вектора движения, вектора ориентации, здоровья, мощности и т. Д. Данных между 10 000 пользователей на одном сервере с помощью любого механизма, использующего HHD, просто глупо, если вы беспокоитесь о задержке.Даже если на простой арене сражаются 2 человека, задержка все еще остается проблемой, и вы должны работать на одном сервере и хранить все в памяти.Все, что будет отображаться, должно быть на вашем ПК или в памяти вашего ПК.

MMORPG, которые не беспокоятся о задержке, могут работать на нескольких серверах и любой базе данных (NoSQL, MySQL и т. Д.)...)

Если вы делаете игру наподобие Farmville или Neopets, то да, NoSQL или MySQL становятся допустимыми вариантами.

Answer 4

Насколько я понимаю, технология nosql - это то, что вы используете в контексте пакетных заданий, а не в контексте реального времени. На самом деле реализация H-base с открытым исходным кодом находится поверх распределенной файловой системы hadoop (hdfs), которая в основном используется только для чтения.

Идея состоит в том, что вы «ищете» запись, перебирая весь набор данных, который вы храните «на диске» (фактически в распределенной файловой системе). Для наборов данных petascale невозможно хранить данные в памяти, поэтому вы используете огромное количество операций чтения с диска, чтобы вообще иметь возможность «искать» данные. Распределенная природа гарантирует (или способствует), что это происходит своевременно.

Принцип состоит в том, что вы переносите обработку на распределенные данные, а не извлекаете данные из очень большой базы данных, отправляете их по сети, а затем обрабатываете на локальном узле. Pig (http://pig.apache.org/) и Hive (http://hive.apache.org/)) - это интерфейсы поверх hdf, которые допускают SQL-подобные запросы, но в фоновом режиме они используют задания mapreduce. Взаимодействие медленное, но это не главное. что огромный набор данных может быть обработан вообще.

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

Наборы данных Hdfs в основном обрабатываются в определенный момент времени, после чего результаты публикуются в одном пакете. Например, на сайте социальной сети вы будете ежедневно собирать все данные о соединениях, искать все новые соединения между людьми, а после завершения операции для всех людей в наборе данных результаты будут опубликованы в типичной форме. 'X теперь соединен с Y' сообщениями. Это не происходит в режиме реального времени.