Ответы:
Мы надеялись, что мы дадим лучшее объяснение причин, чем я, потому что он был фактически автором нашей базы данных. Короче говоря, реляционные БД не очень полезны для игр, потому что они не могут эффективно хранить сильно структурированные иерархические данные, которые составляют подавляющее большинство данных, необходимых ММО для нормальной работы. Мы решили создать базу данных пользовательских объектов и часть распределенной системы обработки транзакций, которая в настоящее время находится в производстве и приводит в действие наши две живые игры.
Что касается, если вы должны сделать то же самое? Наверное, нет, по крайней мере, на первый взгляд. Я бы по-прежнему выступал за то, чтобы избегать SQL, но теперь в мире «NoSQL» есть еще много вариантов, которых не было несколько лет назад.
Тем не менее, большинство ММО работают на SQL (реляционных) базах данных. Я знаю, что Ева работает над установкой SQL Server, расположенной поверх нескольких мультитабсивных RAMSAN (у меня, вероятно, никогда в жизни не будет столько денег, сколько стоят эти вещи).
РЕДАКТИРОВАТЬ: Надеюсь, он не будет возражать, чтобы я разместил это здесь, но это запись в блоге с некоторыми ссылками и комментариями о презентации, которую мы дали на GDC'08 о нашей базе данных.
Хорошо, этот ответ - скорее наблюдение.
Полное раскрытие Я не работал над MMORPG. Я работал над тем, что было одним из 10 самых посещаемых сайтов в 2009 году, и я работал в компании, занимающейся разработкой игровых движков, которая думала, что они делают MMORPG tech (я не знаю, поставлялся ли она).
Если вы посмотрите на компании, которые достигли огромного масштаба (Google, Facebook, Twitter и т. Д., Я знаю, что они не являются игровыми компаниями, но их стоит посмотреть в этом пространстве), есть две вещи, которые я считаю важными.
Большая ошибка - взять какую-нибудь дорогую вещь под ключ и ожидать, что она будет волшебно масштабирована для вас. Это не работает таким образом. Ключом к расширению является правильное решение каждой новой задачи. Вам нужны гибкие, простые в использовании решения, в которые вы можете легко входить и выходить.
Так что мой совет вам будет, если вы начинаете, просто получите то, что кажется наименее головной болью для решения.
По сути, существует целый ряд подходов, и я думаю, что они выбираются на основе опыта их разработчиков, а также свойств базы данных. С одной стороны, многие НММ используют стандартные реляционные базы данных - например, Dark Ages of Camelot использовал / использует (они все еще собираются?) MySQL , FreeRealms используют модифицированный Postgresql и т. Д.
Двигаясь по шкале, вы получаете Guild Wars: они используют SQL Server , но хранят свои данные там как один большой двоичный объект. Это означает, что они получают преимущества своих обычных двоичных форматов с некоторыми преимуществами, которые предоставляет база данных. Излишне говорить, что вы, вероятно, также можете видеть некоторые недостатки этого подхода, но для компании, привыкшей работать с плоскими файлами, это, вероятно, еще шаг вперед.
Тогда, вероятно, есть места, где используются различные формализованные подходы NoSQL, хотя это еще рано. Фармвилл использует мембрану , которую они сделали для этой цели, по-видимому, на основе memcached. Это разделяет многие функции с такими как MongoDB, CouchDB и т. Д. Опять же, с этими подходами вы, как правило, переходите на собственные форматы хранения, но получаете преимущества распределения, кэширования, избыточности и т. Д.
Некоторые полностью внедряют свой собственный NoSQL: Cryptic сказал, что они сделали что-то подобное, но также сказал, что они не использовали его в производстве. ( РЕДАКТИРОВАТЬ : но см. Комментарии ниже.)
А потом вы приходите к людям, которые используют текстовые или двоичные файлы - насколько я понимаю, старые игры, такие как Ultima Online, Everquest и т. Д., Пошли по этому пути, и для компании с опытом разработки игр, но с небольшим опытом работы с базами данных, это хорошо работает слишком.
Также обратите внимание, что вы почти никогда не пишете свою собственную базу данных в каком-то свободном смысле этого слова - в играх вы всегда будете иметь заказные данные, которые вам понадобятся для управления как в памяти, так и на диске способами, которые не поддаются самим себе. к универсальному программному обеспечению. Вы не можете выполнять SQL-запросы каждый раз, когда вам нужны какие-либо данные, поэтому вам нужно будет отражать большую часть вашей информации в коде, независимо от того, какой сервер вы используете.
На Пиратах Пылающего Моря мы смотрели на MySQL (хотя, честно говоря, я бы предпочел Postgres), и когда он начал падать под нагрузкой, мы переключились на Microsoft SQL Server. Честно говоря, тем не менее, я, вероятно, не буду идти этим путем снова в будущем. В большинстве случаев данные PotBS предварительно сериализуются до того, как они сохраняются, поэтому большая часть того, что находится в БД, представляет собой не что иное, как заросшее хранилище ключей / значений. Вдобавок ко всему, чтобы повысить производительность нашего уровня персистентности и лучше контролировать процесс кэширования данных в памяти, мы закончили тем, что создали сервер кэширования, который располагался перед базой данных.
Так что Килотан совершенно прав, вы не будете крутиться на каком-то уровне. Серверы реляционных баз данных SQL не предназначены для использования данными в играх. Вместо того, чтобы предполагать, что реляционные серверы БД являются конечной базой данных, нам действительно следовало бы задуматься о том, какие преимущества мы ищем, прежде чем выбрать инструмент.
В следующий раз я бы больше посмотрел на такие вещи, как BerkleyDB или некоторые другие базы данных в стиле NoSQL.
Еще одна вещь, на которую следует обратить внимание: если у вас есть (относительно) статический набор данных, не храните его в базе данных! Нет действительно веской причины хранить ваши определения заклинаний, определения предметов, карты и т. Д. В базе данных. Вы редко спрашиваете их, кроме как по имени. Я вижу, что многие люди прыгают в разработку игр, храня эти вещи вместе с постоянными данными игроков, и это совершенно другой класс вещей.
Вам нужно хранилище данных, например, файловая система, для них. За пределами разработки вам не нужен ACID, вам не нужен CRUD, вам не нужна база данных для такого рода данных. Внутри разработки вам нужна база данных, но в любом случае вам также нужна VCS, и ваш выбор VCS сделает этот выбор базы данных за вас.
(Если вы работаете над игрой, в которой игроки могут создавать собственные заклинания, предметы или квесты, тогда эти данные будут такими же, как данные игроков, и вам снова понадобится база данных.)
MMORPGs - это интенсивные приложения и огромная задача. Если вы начинаете с разработки игр, я настоятельно рекомендую вам сделать что-то меньшее.
Тем не менее, вам понадобится два максимальных показателя производительности. Вам, очевидно, понадобится серверная ферма / улей. Поскольку сетевое взаимодействие относительно дорого (и большинство MMORPG работают в режиме реального времени), вы можете захотеть реплицировать вашу центральную базу данных на каждый из ваших игровых серверов (эквивалент репликации в реальном времени с низкой задержкой в выбранной вами базе данных).
Если каждый из ваших серверов обслуживает определенный сегмент игрового мира (как работает WoW); что-то вроде распределенных разделенных представлений . DPV позволяют сегментировать строки базы данных на разных серверах; в соответствии с ограничениями на столбцы на каждом сервере. И MSSQL, и Oracle достаточно умны, чтобы общаться только с сервером, содержащим данные, которые попадают в предложение WHERE или ON. Я не уверен, что какие-либо предложения с открытым исходным кодом имеют DPV.
Итогом этого является то, что не имеет значения, какую БД вы используете , просто используйте одно с хорошим именем: MSSQL, Oracle, MySQL, PostgreSQL. Напишите свою базу данных на языке ANSI SQL и посмотрите, какая система работает лучше всего - это единственный способ выяснить это.
Маршрут NoSQL также может быть хорошей идеей, поскольку он рассчитан на высокий уровень параллелизма. Предложение Пранни может помочь.
Я использовал MongoDB (NoSQL), это очень быстрое хранилище документов, доступ к которому можно получить через TCP. Попробуйте! Это круто!
Написание вашей собственной БД является непростой задачей. Я предлагаю вам сначала изучить то, что уже есть, и если вы не можете найти ничего, что соответствует вашему определенному набору критериев, создайте свой собственный. О, и не забудьте открыть его. :)
Я предполагаю, что это в значительной степени зависит от того, какие данные вам нужны и в какой форме.
Я думаю, что большинство людей используют «стандартные» базы данных SQL для «динамических» данных, таких как информация об игроке, будь то SQL Server, MySQL, PostgreSQL.
Тем не менее, «внутренние» данные (состояние мира, контент, ....) могут храниться в любой форме, и я предполагаю, что большинство компаний напишут хотя бы частично пользовательские системы баз данных для этой части, соответствующие их конкретным потребностям. ,
Этот вопрос довольно старый, но моя идея о том, как справиться с ним, так же актуальна, как и его задавали сегодня.
Если вы используете реляционную базу данных, вам нужно уменьшить нагрузку на нее, поэтому эта идея должна помочь.
Храните всю общедоступную информацию в локальной БД в каждой клиентской системе, а также в БД серверов.
Сохраните все таблицы с элементами в клиентской базе данных. Вместо того, чтобы клиент смотрел на сервер при наведении указателя мыши на это оружие, он просто проверяет статистику в локальной базе данных. Сервер имеет собственную базу данных для сбора статистики при расчете и просто передает урон и здоровье, оставшиеся клиентам.
Наихудший случай с этой идеей состоит в том, что каждый может увидеть статистику для всех видов оружия, если им удастся попасть в базу данных клиентов. это не имеет значения, потому что даже если они меняют значения, значения базы данных на сервере - это то, что вычисляет в игре.