Какие базы данных обычно используются в MMORPG? [закрыто]

По какой-то причине люди пишут свою собственную БД?

62 голоса | спросил Kim 6 AM00000060000003531 2010, 06:19:35

10 ответов


39

Мы сделали, мы надеемся, что Бен З даст лучшее объяснение причин, чем я могу, так как он был на самом деле оригинальным автором нашей базы данных. Краткая версия заключается в том, что реляционные БД не очень полезны для игр, потому что они не могут эффективно хранить сильно структурированные иерархические данные, что составляет подавляющее большинство данных, необходимых MMO для нормальной работы. Мы решили создать базу данных пользовательских объектов и часть системы обработки распределенных транзакций, которая сейчас находится в производстве и включает в себя две наши живые игры.

Что делать, если вы должны сделать то же самое? Наверное, нет, по крайней мере, не поначалу. Я бы по-прежнему защищал SQL, но в мире «NoSQL» есть еще много вариантов, которых не было несколько лет назад.

Тем не менее, большинство MMO работают в SQL (реляционных) базах данных. Я знаю, что Eve работает на установке SQL Server, сидящей на нескольких мульти-TB RAMSAN (у меня, вероятно, никогда в моей жизни не будет столько денег, сколько это стоит).

EDIT: Надеюсь, он не будет возражать, если я опубликую здесь, но это представляет собой запись в блоге с некоторыми ссылками и комментариями о презентации, которую мы дали в GDC'08 о нашей базе данных.

ответил coderanger 6 AM00000060000001431 2010, 06:27:14
36

Хорошо, что этот ответ - скорее наблюдение.

Полное раскрытие информации Я не работал над MMORPG. Я работал над тем, что было одним из 10 самых посещаемых сайтов еще в 2009 году, и я работал в игровой движковой компании, которая думала, что они делают технологию MMORPG (я не знаю, если она отправлена).

Если вы посмотрите на компании, достигшие масштабного масштаба (Google, Facebook, Twitter и т. д., я знаю, что они не игровые компании, но их стоит посмотреть в этом пространстве) есть две вещи, которые, по моему мнению, важны .

  1. Они начали с того, что захватили все, что было дешево и легко получить сами.
  2. В конечном итоге им пришлось переварить много своих технологий самостоятельно. (И иногда аппаратное обеспечение)

Большая ошибка состоит в том, чтобы захватить какую-то дорогую вещь «под ключ» и ожидать, что она волшебная шкала для вас. Это не работает. Ключом к расширению является проблема с каждой новой задачей. Вам нужны гибкие простые в использовании решения, которые вы можете легко и быстро перемещать.

Итак, мой совет вам будет, если вы начнете, просто получите то, что кажется наименьшей головной болью.

ответил Jonathan Fischoff 6 AM00000090000004831 2010, 09:11:48
25

В принципе, существует целый ряд подходов, и я думаю, что они выбираются в большей степени на опыте своих разработчиков, а также на свойствах базы данных. С одной стороны, многие ММО используют стандартные реляционные базы данных - например. Темные времена Камелота используются /используются (они все еще идут?) MySQL , FreeRealms использует измененный < a href = "http://www.enterprisedb.com/company/news_events/press_releases/2010_09.do"> Postgresql и т. д.

Двигаясь по шкале, у вас есть Guild Wars: они используют SQL Server , но они помещают свои данные там как один BLOB. Это означает, что они получают преимущества своих обычных двоичных форматов с некоторыми преимуществами, предоставляемыми базой данных. Излишне говорить, что вы, вероятно, можете увидеть и некоторые недостатки этого подхода, но для компании, используемой для работы с плоскими файлами, вероятно, это еще один шаг.

Тогда, вероятно, есть некоторые места, использующие различные формализованные подходы NoSQL, хотя пока еще рано. Фармвилл использует membase , который они сделали для этой цели, по-видимому, на основе memcached. У этого есть много особенностей с подобными MongoDB, CouchDB и т. Д. Снова с этими подходами вы, как правило, сворачиваете свои собственные форматы хранения, но получаете преимущества распространения, кэширования, резервирования и т. Д.

Некоторые полностью загружают свой NoSQL: Cryptic говорят, что они сделали что-то подобное , но также сказал, что они не используют его в производстве. ( EDIT : но см. комментарии ниже.)

И тогда вы приходите к людям, которые используют плоские текстовые или двоичные файлы, - как я понимаю, старые игры, такие как Ultima Online, Everquest и т. д., пошли по этому маршруту, а для компании с опытом разработки игр, но с небольшим опытом работы с базами данных это тоже хорошо работает.

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

ответил Kylotan 6 PM00000050000000431 2010, 17:35:04
10

В «Пиратах горящего моря» мы устарели от MySQL (хотя, честно говоря, я бы предпочел Postgres), и когда он начал падать под нагрузкой, мы переключились на Microsoft SQL Server. Честно говоря, я, вероятно, больше не вернусь к этому маршруту в будущем. Большинство данных PotBS предварительно сериализуются до того, как они сохраняются в любом случае, поэтому большая часть того, что находится в БД, является не чем иным, как заросшим хранилищем ключей /значений. Кроме того, чтобы получить лучшую производительность из нашего уровня персистентности и лучше контролировать, как данные были кэшированы в памяти, мы закончили писать сервер кэширования, который сидел перед базой данных.

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

В следующий раз я бы посмотрел больше на такие вещи, как BerkleyDB или некоторые другие DB в стиле NoSQL.

ответил justinian 7 AM00000030000002631 2010, 03:45:26
10

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

Для этого вам понадобится хранилище данных, например файловая система. Вне разработки вам не нужна ACID, вам не нужен CRUD, вам не нужна база данных для такого рода данных. Внутри разработки вам нужна база данных, но вам также нужен VCS, и ваш выбор VCS сделает для вас выбор базы данных.

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

ответил 8 PM00000030000000431 2010, 15:14:04
5

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

Это говорит о том, что вам понадобится две характеристики сжатия из вашей настройки. Очевидно, вам понадобится серверная ферма /улей. Поскольку сетевая связь относительно дорога (и большинство MMORPG - это в реальном времени), вы можете захотеть реплицировать свою центральную базу данных на каждый из ваших игровых серверов (эквивалент репликации в режиме реального времени с низкой задержкой в ​​выбранной вами базе данных).

Если каждый из серверов обслуживает определенный сегмент игрового мира (например, WoW работает); что-то вроде распределенных разделенных видов . DPV позволяют сегментировать строки вашей базы данных на разных серверах; в соответствии с ограничениями на столбцы на каждом сервере. Оба MSSQL и Oracle достаточно умны, чтобы разговаривать только с сервером, который содержит данные, которые входят в предложение WHERE или ON. Я не уверен, что в любом из предложений с открытым исходным кодом есть DPV.

Конечным результатом всего этого является то, что не имеет значения, какой DB вы используете , просто используйте его с хорошим именем: MSSQL, Oracle, MySQL, PostgreSQL. Напишите свою базу данных в ANSI SQL и посмотрите, какая система работает наилучшим образом - это единственный способ узнать.

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

ответил Jonathan Dickinson 6 PM00000010000005131 2010, 13:21:51
5

Я использовал MongoDB (NoSQL), это очень быстрое хранилище документов, к которому можно получить доступ через TCP. Попробуй! Это потрясающе!

Написание собственной БД - непростая задача. Я предлагаю вам сначала изучить, что уже есть, и если вы не можете найти что-либо, что соответствует вашему конкретному набору критериев, создайте свои собственные. О, и не забудьте открыть его. :)

ответил Ariejan 26 +04002010-10-26T21:14:02+04:00312010bEurope/MoscowTue, 26 Oct 2010 21:14:02 +0400 2010, 21:14:02
0

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

Я думаю, что большинство людей используют «стандартные» базы данных SQL для «динамических» данных, таких как информация о игроках, будь то SQL Server, MySQL, PostgreSQL.

Однако, «внутренние» данные (состояние мира, контент, ....) могут храниться в любой форме, и я предполагаю, что большинство компаний пишут по крайней мере частично настраиваемые системы баз данных для этой части, подходящие для их конкретные потребности.

ответил Axelle Ziegler 6 AM000000100000004231 2010, 10:47:42
0

Ну, это на самом деле зависит от вашего приложения - вот в чем дело. Я работаю, где мы разрабатываем социальные RPG, и мы используем Google App Engine в качестве бэкэнд

ответил pr4n 6 AM000000110000000531 2010, 11:30:05
0

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

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

Хранить всю общедоступную информацию в локальной БД в каждой клиентской системе, а также в БД серверов.

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

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

ответил FissionFlame 26 +04002013-10-26T20:05:12+04:00312013bEurope/MoscowSat, 26 Oct 2013 20:05:12 +0400 2013, 20:05:12

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132