noSQL - это правильный вариант для веб-игры? [закрыто]

Из-за возможности и скуки мы с другом решили сделать веб-игру. Это первая «игра», которую я буду делать, так как обычно я программирую веб-приложения на django.

Я решил использовать ту же платформу для игры, но я не совсем уверен насчет хранения данных, так как не могу предвидеть будущие требования и проблемы, связанные с БД. В последнее время движение noSQL набирает силу, и я хотел бы изучить эту область.

Поэтому у меня есть следующие вопросы:

• Подойдет ли хранилище данных noSQL (на основе документов, например MongoDB) для сетевой игры?
• Какие проблемы могут возникнуть при использовании обычной СУБД, такой как MySQL?
• Как обеспечить согласованность данных среди пользователей с MongoDB, во время игры или во время событий, таких как задания cron?

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

• Некоторые данные статичны для всех игроков: предметы, оружие, зелье, карты и т. Д.
• Некоторые данные, привязанные к игроку: инвентарь, метрики (статистика), прогресс и т. Д.
• Игроку может потребоваться узнать статистику и состояние другого игрока.
• Запланированные задачи будут выполняться в определенный промежуток времени

Подойдет ли база данных noSQL для сетевой игры?

Абсолютно! Вообще говоря, нереляционные базы данных (такие как MongoDB) намного лучше для игр, поскольку они более гибки в том, как они моделируют данные, и при этом более производительны, чем реляционные базы данных (такие как SQL), что делает их «беспроигрышными» выбор.

Какие проблемы могут возникнуть при использовании обычной СУБД?

Есть два основных недостатка использования реляционных баз данных:

• Отсутствие гибкости в моделировании данных
• Производительность

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

weapon_type_id | weapon_type
1 | sharp

weapon_id | weapon| weapon_type_id | damage
1 | Short Sword | 1 | 5

potion_type_id | potion_type
1 | HP
2 | Mana

potion_id | potion| potion_type_id | modifier
1 | Healing Elixer | 1| 5
2 | Mana Drainer | 2| -5

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

• Добавить новый тип элемента
• Создать оружие с несколькими типами оружия
• Создать зелье, которое также можно использовать как оружие.

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

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

db.itemTypes

name: Weapon
types: Sharp

name: Potion
types: HP, Mana

db.items

name: Short Sword
weapon
    type: Sharp (db.itemTypes reference)
    damage: 5

name: Healing Elixer
potion
    type:  HP (db.itemTypes reference)
    modifier: 5

name: Mana Drainer
potion
    type:  Mana (db.itemTypes reference)
    modifier: -5  

name:  Healing Potion Sword
potion
    type: HP (db.itemTypes reference)
    modifier: 10
weapon
    type: Sharp (db.itemTypes reference)
    damage: 15

Есть много хороших статей о производительности баз данных NoSQL vs SQL, но вот одна из них, которая содержит примеры приложений, позволяющих выполнять собственные тесты: MongoDB против производительности SQL Server 2008 Showdown

Как обеспечить согласованность данных среди пользователей с MongoDB?

MongoDB поддерживает элементарные операции чтения / записи для отдельных объектов данных (документов), поэтому результаты запроса из MongoDB всегда должны быть точными с тем, что хранится в базе данных.

Изменить: Предоставлен пример NoSQL базы данных элементов

Пару слов защищают базы данных SQL.

1 - Если у вас есть база данных SQL, вы можете работать со своими данными не только по первичному ключу. Большинство запросов в MMO выполняется по PK, но когда вам нужно найти всех пользователей с уровнем> 30, что вы будете делать в мире NoSQL?

2 - Если у вас есть язык SQL, вы можете создавать «исправления» для восстановления поврежденных данных. Например: «обновить player_items установить флаг = 0, где item_type_id = 100». Как вы можете это исправить в NoSQL? Я думаю, вам придется сделать скрипт, который будет анализировать все ваши данные ...

3 - базы данных SQL не такие медленные, как вы думаете. Мои коллеги создают MMO-игру, основанную на сети, которая совершает 5000 транзакций в секунду в MySQL. Вам этого мало? Если нет, вы можете использовать шардинг для масштабирования вашей базы данных.

4 - SQL имеет ограничения внешнего ключа и такие хорошие вещи, которые помогут вам находить ошибки в вашем коде.

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

Ответ - да, это верный вариант, но нет, вероятно, это не очень хорошая идея .

Есть две основные проблемы с SQL, которые NoSQL пытается решить, когда дело доходит до игр.

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

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

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

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

Базы данных на основе документов, такие как CouchDB и MongoDB, решают эту проблему, выдвигая документ в объект верхнего уровня, а не в строку (в этом случае «документ» является синонимом «объекта»). Но при этом они теряют многие преимущества баз данных SQL. Пропускная способность намного ниже, а алгоритмы блокировки становятся намного сложнее.

Хорошей новостью является то, что уже есть много инструментов объектно-реляционного отображения (ORM) , доступных для любого языка, который вы используете. Они позволяют довольно прозрачно переводить объекты в память и строки в базе данных. Эти инструменты обычно не подходят для крупномасштабных игр в реальном времени, потому что они могут представлять худшие аспекты производительности баз данных SQL и NoSQL. Но это хорошо для веб-игры - в худшем случае, когда вы сталкиваетесь с проблемами производительности, вы можете вернуться к транзакциям по старинке. Проблема с задержкой не повредит вам, а увеличенная пропускная способность поможет вам.

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

• Подойдет ли хранилище данных noSQL (на основе документов, например MongoDB) для сетевой игры?

Я бы посоветовал взглянуть на couchdb

Его интерфейс основан на javascript, поэтому он будет хорошо сочетаться с играми на основе HTML5 / javascript.

Он также может работать в автономном режиме (создавая локальную копию БД), а затем синхронизироваться с сервером позже (вы можете использовать это, например, для подземелий с инстансом)

• Какие проблемы могут возникнуть при использовании обычной СУБД, такой как MySQL?

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

Например, посмотрите, как выполняются « запросы » в couchdb. Все сделано в JavaScript.

• Как обеспечить согласованность данных среди пользователей с MongoDB, во время игры или во время событий, таких как задания cron?

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

В зависимости от того, что у вас есть в вашей игре, вы можете использовать оба и соединять их через модели в вашей игре. Например, игрок может и должен находиться в RDB (информация для входа в систему), но инвентарь игрока / хранилище переменных может перейти в noSQL, поэтому ваш модуль игрока может login()использовать RDB и fetchInventory()использовать noSQL по первичному ключу.

Карты, например, лучше сохранять в NoSQL (например, координаты => массив различных объектов). Я не представляю, как сохранить то, что содержит область в RDB (кроме сериализованной строки, которую необходимо полностью десериализовать, чтобы прочитать некоторую часть большего количества ЦП). и ОЗУ потрачено впустую!) ну, вы все равно можете сохранить области в RDB, например, область "город X" содержит следующие кординаты / блок ([3,4], [8,7] ...)

вы могли бы и, вероятно, должны использовать оба, и взглянуть на энергозависимое хранилище, такое как memcache, которое вам может понадобиться, или некоторые временные данные (наверняка будет быстрее, чем использование жесткого диска! и экономит вам много ЦП, но не ОЗУ)

так в итоге>

это зависит от того, что вы хотите иметь в своей игре! cheerz