Відповіді:
Ми, сподіваємось, Бен З дасть краще пояснення причин, ніж я можу, оскільки він насправді був оригінальним автором нашої бази даних. Коротка версія полягає в тому, що реляційні БД не дуже корисні для ігор, тому що вони не можуть ефективно зберігати структуровані ієрархічні дані, що становить переважну більшість даних, необхідних MMO для нормальної роботи. Ми вирішили створити користувальницьку базу даних об'єктів та частину розподіленої системи обробки транзакцій, яка зараз виробляється та використовує наші дві живі ігри.
Що стосується того, чи варто робити те саме? Напевно, ні, принаймні не спочатку. Я б все-таки виступав за те, щоб уникати SQL, але в світі "NoSQL" зараз існує ще багато варіантів, які не існували кілька років тому.
Однак, більшість ММО працюють на базах даних SQL (реляційні). Я знаю, що Єва працює на установці SQL Server, сидячи поверх декількох мультитуберкульозних RAMSAN (я, мабуть, ніколи в житті не матиму стільки грошей, скільки коштують ці речі).
EDIT: Сподіваємось, він не буде проти того, щоб я розміщував це тут, але це запис у блозі з деякими посиланнями та коментарями щодо презентації, яку ми дали на GDC'08 про нашу базу даних.
Гаразд ця відповідь - це більше спостереження.
Повне розкриття я не працював над MMORPG. Я працював над тим, що був у топ-10 найпопулярніших сайтів ще в 2009 році, і я працював в компанії з ігровими движками, яка думала, що вони роблять технологію MMORPG (я не знаю, чи постачається).
Якщо ви подивитесь на компанії, які досягли масштабних масштабів (Google, Facebook, Twitter тощо), я знаю, що вони не є ігровими компаніями, але їх варто подивитися в цьому просторі), є два моменти, які я вважаю важливими.
Велика помилка - це схопити якусь дорогу річ під ключ і очікувати, що вона магічно масштабує для вас. Це не працює так. Ключ розширення масштабів - відповідне вирішення кожного нового виклику. Вам потрібні гнучкі прості у використанні рішення, які ви можете легко переміщувати і виходити.
Тож моя порада вам буде, якщо ви починаєте, просто отримуйте те, що здається найменш головним болем.
В основному, існує цілий спектр підходів, і я думаю, що їх обирають більше на основі досвіду своїх розробників, а не властивостей бази даних. З одного боку, багато ММО використовують стандартні реляційні бази даних - наприклад. Темні віки Camelot використовуються / використовуються (вони все ще продовжуються?) MySQL , FreeRealms використовують модифікований Postgresql тощо.
Рухаючись по шкалі, у вас є Guild Wars: вони використовують SQL Server , але вони вкладають свої дані туди як єдиний BLOB. Це означає, що вони отримують переваги від своїх звичайних бінарних форматів із деякими перевагами, які надає база даних. Потрібно говорити, що ви, мабуть, бачите і деякі недоліки такого підходу, але для компанії, яка звикла працювати з плоскими файлами, це, мабуть, все-таки крок.
Тоді, мабуть, є місця, які використовують різні формалізовані підходи NoSQL, хоча це ще ранні дні. Farmville використовує мембрану , яку вони зробили для своєї мети, грунтуючись на певному запам'ятовуванні . Це ділиться багатьма функціями з подібними до MongoDB, CouchDB і т. Д. Знову за допомогою цих підходів ти зазвичай прокручуєш власні формати зберігання, але отримуєш переваги від розповсюдження, кешування, надмірності тощо.
Деякі повністю просувають свій власний NoSQL: Cryptic сказав, що вони зробили щось подібне, але також сказали, що не використовують його у виробництві. ( EDIT : але дивіться коментарі нижче.)
І тоді ви приїжджаєте до людей, які використовують плоский текст або двійкові файли - наскільки я розумію, старі ігри, такі як Ultima Online, Everquest і т. Д., Усі пішли по цьому маршруту, і для компанії, яка має досвід розробки ігор, але мало досвіду роботи з базою даних, це працює добре теж.
Зауважте також, що ви майже ніколи не займаєтеся написанням власної бази даних в якомусь слабкому розумінні цього терміна - в іграх ви завжди матимете за собою дані, якими потрібно керувати або в пам'яті, або на диску, таким чином, що вони не піддаються до загального програмного забезпечення. Ви не можете робити запити SQL кожен раз, коли вам потрібні деякі дані, тому вам потрібно буде відображати багато інформації в коді, незалежно від того, яким зворотним кінцем ви користуєтесь.
На Піратах Палаючого моря ми дивилися з MySQL (хоча, чесно кажучи, я вважав би за краще Postgres), і коли він почав падати під навантаженням, ми перейшли на Microsoft SQL Server. Чесно кажучи, я, мабуть, не піду цим шляхом у майбутньому. Більшість даних PotBS попередньо серіалізуються до того, як вони все одно збережуться, тому велика частина того, що знаходиться в БД, є не що інше, як перерослий запас ключів / цінностей. На додаток до цього, щоб досягти кращої продуктивності нашого шару стійкості та кращого контролю над тим, як кешувались дані в пам'яті, ми закінчили писати кеш-сервер, який сидів перед базою даних.
Отже, Кілотан дуже правий, ви не збираєтеся обіймати прокрутку свого власного на якомусь рівні. Сервери реляційних баз даних SQL не розроблені для того, як ігри використовують дані. Замість того, щоб припустити, що реляційні сервери БД є кінцевими базами даних, ми дійсно повинні були б подумати більше про те, які переваги ми шукали, перш ніж вибирати інструмент.
Наступного разу я роздивляюся деталі на зразок BerkleyDB або деяких інших БД стилів NoSQL.
Ще одне, що слід зазначити, якщо у вас є (відносно) статичний набір даних, не зберігайте його в базі даних! Немає дійсно вагомих причин зберігати визначення заклинань, визначень предметів, карт тощо в базі даних. Ви їх рідко запитуєте, крім імені. Я бачу, що багато людей стрибають у розробці ігор, зберігаючи ці речі поряд із збереженими даними про гравців, і це зовсім інший клас речей.
Для цього вам потрібен сховище даних, як файлова система. Поза розробкою вам не потрібна кислота, вам не потрібна CRUD, вам не потрібна база даних для такого роду даних. Всередині розробки вам потрібна база даних, але вам також потрібен VCS, і ваш вибір VCS зробить цей вибір бази даних для вас.
(Якщо ви працюєте над грою, де гравці можуть створювати власні заклинання або предмети чи квести, то, ці дані є такими ж, як і дані гравців, і вам знову потрібна база даних.)
MMORPG - це інтенсивні програми, які є величезним завданням. Якщо ви починаєте з розробки ігор, я настійно рекомендую вам зробити щось менше.
Це означає, що вам знадобляться два найвищі показники з вашого налаштування. Вам, очевидно, знадобиться ферма / вулик для серверів. Оскільки мережевий зв’язок є відносно дорогим (а більшість MMORPG в режимі реального часу), ви можете скопіювати свою центральну базу даних на кожен із своїх ігрових серверів (еквівалент реплікації з низькою затримкою в реальному часі у вашій базі даних на вибір).
Якщо кожен з ваших серверів обслуговує певний сегмент ігрового світу (як WoW працює); щось на кшталт розподілених розділених представлень . DPV дозволяють сегментувати рядки бази даних на різних серверах; відповідно до обмежень стовпців на кожному сервері. І MSSQL, і Oracle досить розумні, щоб спілкуватися лише з сервером, який містить дані, які входять до вашого пункту WHERE або ON. Я не впевнений, чи є у будь-яких пропозицій з відкритим кодом DPV.
Результатом цього всього є те, що не має значення, яку БД ви використовуєте , просто використовуйте один з хорошим ім'ям: MSSQL, Oracle, MySQL, PostgreSQL. Напишіть свою базу даних в ANSI SQL і подивіться, яка система працює найкраще - це єдиний спосіб дізнатися.
Маршрут NoSQL також може бути хорошою ідеєю, оскільки він розроблений для високої одночасності. Пропозиція Прані може зробити трюк.
Я використовував MongoDB (NoSQL), це дуже швидкий сховище документів, до якого можна отримати доступ через TCP. Спробувати! Це приголомшливо!
Написання власного БД є непростим завданням. Я пропоную вам спочатку вивчити, що вже там, і якщо ви не можете знайти жодну річ, яка відповідає вашому певному набору критеріїв, побудуйте свій власний. О, і не забудьте відкрити його. :)
Я думаю, це дуже сильно залежить від того, який тип даних вам потрібно зберігати та під якою формою.
Я думаю, що більшість людей там використовують "стандартні" бази даних SQL для "динамічних" даних, таких як інформація про програвача, будь то SQL Server, MySQL, PostgreSQL.
Однак "внутрішні" дані (стан світу, вміст, ....) можна зберігати під будь-якою формою, і я гадаю, що більшість компаній записують принаймні частково власні системи баз даних для цієї частини, що відповідають їх конкретним потребам .
Це питання досить старе, але моя ідея, як впоратися з ним, така ж справедлива, як і задалася, як і сьогодні.
Якщо ви використовуєте реляційну базу даних, вам потрібно зменшити навантаження на неї, тому ця ідея повинна допомогти.
Зберігайте всю загальнодоступну інформацію в локальній БД на кожній клієнтській системі, а також у БД серверів.
Зберігайте всі таблиці з елементами в базі даних клієнта. Замість того, щоб клієнт дивився на сервер, коли наводиш курсор на цю зброю для статистики, клієнт просто перевіряє локальну базу даних щодо статистики. Сервер має власну базу даних для виведення статистики під час обчислення і просто передає клієнтам шкоду та здоров'я.
Найгірше ця ідея полягає в тому, що кожен може побачити статистику всієї зброї, якщо їм вдасться потрапити в базу даних клієнтів. не важливо, хоча причина, навіть якщо вони змінюють значення, значення бази даних на сервері - це те, що робить обчислення в грі.