Ответ - да, это верный вариант, но нет, вероятно, это не очень хорошая идея .
Есть две основные проблемы с SQL, которые NoSQL пытается решить, когда дело доходит до игр.
Первый - это задержка или задержка. В каком-то смысле базы данных SQL работают невероятно быстро, обрабатывая тысячи и более транзакций за десятые доли секунды. С другой стороны, они невероятно медленные, потому что обработка всего нескольких транзакций может занять столько же времени. Для большинства применений базы данных это не имеет значения, но в играх есть компонент реального времени, поэтому речь идет не только о количестве транзакций, которые вы можете совершать в секунду, но и о среднем времени, которое требуется для ответа на транзакцию базы данных.
Эта задержка является серьезной проблемой для игр в реальном времени. Многие разработчики, которым нужны большие базы данных (обычно для MMO), создают слой кэширования, который расположен между базой данных и игровыми серверами, чтобы избежать этих сбоев, а затем периодически очищают кэш. Проблема? Вы просто отбросили основные причины использования базы данных - атомарность, согласованность, изоляция и долговечность .
Но эта проблема не относится к веб-играм. У вас уже есть соединение с высокой задержкой между игроком и игрой, так что вы могли бы также получить пропускную способность, предоставляемую SQL, а также преимущества зрелого, хорошо известного программного обеспечения.
Вторая проблема, однако, относится к вам, и это несоответствие объектно-реляционного импеданса . Игры работают с объектами, базы данных - со строками. Если вам повезет, объект можно превратить в ряд, просто перечислив его поля, но большую часть времени объекты являются иерархическими, и вам нужно каким-то образом сгладить их, чтобы поместить их в строки.
Базы данных на основе документов, такие как CouchDB и MongoDB, решают эту проблему, выдвигая документ в объект верхнего уровня, а не в строку (в этом случае «документ» является синонимом «объекта»). Но при этом они теряют многие преимущества баз данных SQL. Пропускная способность намного ниже, а алгоритмы блокировки становятся намного сложнее.
Хорошей новостью является то, что уже есть много инструментов объектно-реляционного отображения (ORM) , доступных для любого языка, который вы используете. Они позволяют довольно прозрачно переводить объекты в память и строки в базе данных. Эти инструменты обычно не подходят для крупномасштабных игр в реальном времени, потому что они могут представлять худшие аспекты производительности баз данных SQL и NoSQL. Но это хорошо для веб-игры - в худшем случае, когда вы сталкиваетесь с проблемами производительности, вы можете вернуться к транзакциям по старинке. Проблема с задержкой не повредит вам, а увеличенная пропускная способность поможет вам.
Наконец, чтобы подчеркнуть мысль, которую я сделал в другом месте : речь идет не о статических игровых данных. Я не говорю о ваших описаниях предметов, о вашем оружии, о спрайтах или о чем-либо здесь. Я имею в виду реальные изменчивые игровые данные, например, что находится в инвентаре игрока или какова его статистика. Все, что вам нужно для статических данных - это хранилище данных. Возможно, получается, что проще всего использовать для этого ту же базу данных, что и хранилище данных, потому что у вас отличный ORM; может быть, вам просто нужна файловая система. Это две отдельные проблемы, и один ответ не должен (и, вероятно, не будет) соответствовать обоим случаям.