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


20

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

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

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

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

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

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


1
Проблема с некоторыми базами данных noSQL заключается в том, что они не могут быстро выполнять непредвиденные запросы во время «проектирования» для огромных наборов данных, таких как журналы событий: gamedev.stackexchange.com/q/4465/450. Имейте в виду, что для баз данных noSQL требуется то же самое. методы против внедрения запросов нормальные, чем обычные базы данных.
Хендрик Браммерманн

1
@nhnb: один хороший способ восстановить вашу точку зрения - это «использовать реляционную базу данных для данных отношений и использовать базу данных объектов / документов для данных объектов / документов». К сожалению, я не думаю, что большинство людей имеют опыт или проводят много времени, думая о моделировании, что приводит к плохим проектам независимо от того, какой выбор они выберут.

2
В ответ на ваш вопрос "Является ли NoSQL верным вариантом для веб-игр?" Я верю, что ответ - да. Ранее базы данных NoSQL использовались для сетевых игр (таких как FarmVille) и предлагают большую гибкость. Похоже, что основным предметом спора по этому вопросу является «что лучше (NoSQL или SQL)?». У каждой системы есть свои плюсы и минусы, но обе являются совершенно законными вариантами. Если вы ищете подробный список преимуществ одной системы над другой, вы, возможно, захотите заплатить Программистам StackExchange за это. :)
Ари Патрик

Ответы:


21

Подойдет ли база данных 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, как бы вы на высоком уровне смоделировали его с помощью nosql?
Пран

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

3
@Ari: Статических данных намного больше, но никто не заботится о пропускной способности записей в них, потому что никто не пишет в них - нет записей, нет транзакций, нет ACID, нет реального вопроса о базе данных, даже если вы случайно сохранили его в одной. Тогда на этот вопрос легко ответить - просто сохраните его в памяти. Конечно, «Как мы можем загрузить статические данные быстрее?» это интересный вопрос, но я не думаю, что это вообще связано с вопросами SQL против NoSQL. - Что касается операций с несколькими документами, означает ли это, что в вашей базе данных будет один документ, например, со всеми игроками?

2
@Ari: Пожалуйста, не путайте NoSQL, который является идеей, и MongoDB, который является конкретной базой данных. На моей последней работе мы поставили две игры в базу данных NoSQL и получили отличный параллелизм с низкой задержкой. Но наша база данных NoSQL также поддерживала многодокументные транзакции с блокировкой на уровне полей. NoSQL - это не единственная «вещь», подобная SQL, это просто относится к любой базе данных, не использующей SQL (и обычно не использующей реляционные схемы).

5
Просто мои $ .02, но "не производительный" не является недостатком RDBMS. Недостатком является хранение нереляционных данных в RDBMS, не настройка RDBMS, не понимание того, что делает ваш SQL, не индексация и т. Д. И т. Д. И т. Д. Если у вас есть реляционные данные, вы обнаружите, что RDBMS невероятно оптимизированы.
Робби

19

Пару слов защищают базы данных 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.


1
Это все веские причины избегать NoSQL до тех пор, пока он вам действительно не понадобится. Особенно № 3. Если у вас уже нет миллиардов пользователей (и вы не отказываетесь от чего-либо), вы, вероятно, будете намного более продуктивны с MySQL.
ojrac

5
1. Вы бы использовали: "для x в db.user.find ({" level ": {" $ gt ": 30}})" 2. Технически, то, что вы написали, также является сценарием, так что я не совсем уверен, в чем ваша точка зрения. 3. ОЧЕНЬ возможно создать MMO с использованием SQL, и на самом деле многие MMO были разработаны с использованием этой технологии. Технология NoSQL является довольно новой и уже была принята такими сервисами, как Amazon, Google и Facebook, благодаря своей производительности и гибкости. 4. В NoSQL вам нужно написать свои собственные ограничения, но это просто стоимость дополнительной гибкости.
Ари Патрик

2
Я согласен с твоим высказыванием мышления дважды. Это частично то, что я делаю здесь с этим вопросом :)
Пран

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

5
Что касается 3, проблема заключается не столько в том , что SQL является медленным , но SQL является лага . Вообще говоря, базы данных SQL получают отличную пропускную способность за счет задержки. Для сетевой игры это, вероятно, то, что вы хотите! Для сетевой игры в реальном времени это, вероятно, не так, и большинство MMO, подобных WoW, использующих SQL, используют перед ним слой кэширования, который устраняет большинство преимуществ SQL, поэтому NoSQL является большим шагом вперед для их.

18

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

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

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

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

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

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

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

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

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


1
+1 Спасибо за сравнение обоих вариантов. Кроме того, вы можете сказать, что статических данных не должно быть в базе данных.
Прана

1
+1 Однако я думаю, что вы не упомянули одного из главных плюсов (ну, за или против, в зависимости от перспективы) No SQL, а именно, что он не содержит схем, что позволяет хранить высокодинамичные данные. На самом деле я собираюсь использовать сочетание обоих для моего текущего проекта с PostgreSQL для вещей, которые хорошо вписываются в реляционную модель, и Mongo для полустатических вещей, которые этого не делают. (например, журнал, который может использоваться для генерации воспроизведения, где реляционно мне понадобится либо столбец, в котором хранится PK из одной из многих других таблиц, либо таблица с общими именами столбцов, например, param1 param2)
Davy8

1
@ Davy88: noSQL не обязательно не содержит схем, и наличие «высокодинамичной» базы данных на самом деле не является плюсом. Если все, что у вас есть, это суп из данных, вы не можете выполнять индексирование, вы не можете выполнять блокировку на уровне поля, и даже простые запросы становятся чреваты вопросами о том, что происходит, если ключ не существует.

@ user744, что делают те вещи, о которых ты говоришь?
expiredninja

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

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

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

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

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

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

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

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

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


Да, я тоже слышал о couchdb, на самом деле, даже на сайте mongodb, они обычно сравнивают его. Я думаю, что мне нужно исследовать couchdb vs mongodb.
Пран

2

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

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

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

так в итоге>

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


какие функции, по вашему мнению, влекут вас больше в NoSQL или на уровень персистентности, как мне нравится думать об этом?
expiredninja

1
может быть, система координат, если ваша игра основана на GPS, что может потребовать расширенного поиска. в основном, если вы хорошо разбираетесь в MySQL, то придерживайтесь его, возможно ли использовать его как nosql
Ronan Dejhero
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.