Яку Базу даних (RDBMS проти NoSQL проти BOTH) використовувати для багатокористувацької гри в реальному часі?

Я працюю над багатокористувацькою грою в реальному часі, для якої буде потрібна база даних (для таких функцій, як профілі гравців, друзі, розблокування, новини тощо). Це стандартна гра для ПК (не на базі браузера) і використовуватиме клієнт-сервер архітектури. Я новачок у використанні баз даних і провів деякі дослідження за останні кілька днів, коли я натрапив на бурхливу дискусію: RDBMS проти NoSQL. В даний час я схиляюся до NoSQL, але, прочитавши про використання для кожного (RDBMS і NoSQL), я спокусився використати і те, і інше. Я знаю, що це може здатися дивним, але дозвольте мені пояснити свою ситуацію:

У моєї команди є спільний веб-хостинг-пакет, який пропонує необмежену пам’ять і пропускну здатність mySQL. Єдине застереження, що ми можемо мати лише 25 підключень одночасно (правило спільного хостингу). Я маю намір використовувати це для свого веб-сайту (типовий спосіб використання без сумнівів), щоб публікувати оновлення новин, підтримувати функції спільноти (наприклад, коментарі, завантажувати фан-арт тощо) тощо. Це все добре і добре - але! ось дещо стає цікавим ... Я хочу показати цю саму інформацію, розміщену на моєму веб-сайті, в грі. Це означає використовувати mySQL як для мого веб-сайту, так і для моєї гри. На додаток до публікацій новин тощо, я планую використовувати його в грі для таких речей, як чат і список серверів. Я здебільшого мене турбує це правило-25-з'єднання.

Що змушує мене задати питання №1: Чи буде це спрацьовувати і чи є краща альтернатива?

Тепер, окрім цього, я читав про те, наскільки добре NoSQL працює і підходить для ігор в реальному часі (я можу помилятися, я пройшов величезну війну RDBMS проти NoSQL полум'я, щоб потрапити сюди і, ймовірно, був спалений). В основному, я хотів би використовувати MongoDB для всіх моїх ігрових об'єктів.

І знову, це буде корисно, якщо я надаю певний контекст: я знайшов хост (MongoLab), який пропонує пакет MongoDB 240 Мб безкоштовно, який я маю намір використовувати, поки не потрібно оновити. Враховуючи 240 Мб, я підрахував, що я зможу зберігати приблизно 60 000 гравців (якщо кожен гравець приблизно 4 КБ, і ми ігноруємо інші речі, які можуть бути збережені). Місце для зберігання та плата за більше у майбутньому (якщо наша гра буде успішною) не є проблемою. Єдина причина, по якій я зараз маю намір використовувати MongoDB для всіх моїх даних про ігрові об'єкти, - це те, наскільки часто до цього ігрового об’єкта будуть доступні дані (наприклад, кожного разу, коли гравець вбивається, бере предмет, вистрілює з рушниці тощо). також подобаються прямі документи без схем (які полегшують відображення даних об’єктів гри). Слід зазначити, що свого часу,

Я маю намір використовувати той самий MongoDB на своєму веб-сайті, щоб відображати інформацію про профіль гравця (я не переймаюся повною послідовністю, деяка затримка з оновленнями в грі нормальна). Що призводить мене до мого другого запитання, запитання №2: Це хороша ідея чи щось краще я повинен зробити?

У грі буде досвід запуску, подібний до цього:

1. Вхід клієнта (MongoDB)
2. Клієнт знаходиться на домашній сторінці г / чатів у грі (MySQL)
3. Клієнт переходить до списку серверів (MySQL)

4. Клієнт підключається до сервера і грає на ньому

5. Сервер повідомляє оновлення для всіх гравців (MongoDB)

Це якраз так, як я уявляв, що це буде працювати. Чи добре це вам здається чи у вас є пропозиції щодо вдосконалення цього плану?

Моя пропозиція полягає у тому, щоб ваша гра повідомляла створеному вами веб-сервісу, який сам займається запитом до бази даних. У цей момент дуже просто спробувати різні види баз даних, "перемикаючи" реалізацію веб-служб (ваш веб-сервіс завжди залишається однаковим, щоб гра не ламалася) і вирішити, яка з них підходить саме вам.

Також набагато безпечніше не піддавати свою базу даних безпосередньо в Інтернеті.

у нас може бути відкрито лише 25 підключень одночасно (правило спільного хостингу).

Цього більш ніж достатньо для вашої гри. Проблема полягає в тому, що якщо ваш веб-сайт використовує кілька підключень, ви можете закінчитися. Потрібно налаштувати свій веб-сервер, щоб він використовував лише невелику кількість, залишаючи решту для вашого ігрового сервера. Ваш ігровий сервер насправді не потребує більше ніж 1 з’єднання, але, можливо, виграєте від того, щоб мати декілька.

Тепер, окрім цього, я читав про те, наскільки добре NoSQL працює і підходить для ігор в реальному часі (я можу помилятися, я пройшов величезну війну RDBMS проти NoSQL полум'я, щоб потрапити сюди і, ймовірно, був спалений). В основному, я хотів би використовувати MongoDB для всіх моїх ігрових об'єктів.

Це трохи помилковий аргумент, оскільки жодна система не є достатньо швидкою, щоб використовувати її як основний склад для швидкої гри в режимі реального часу - вам дійсно потрібно зберігати та маніпулювати значеннями в пам'яті. Таким чином, ви потрапляєте в базу даних лише тоді, коли це абсолютно необхідно, що може просто врятувати весь персонаж так часто (наприклад, раз на хвилину), і в цей момент різниці швидкостей стають незначними.

Найсмішніше, що якщо ви налаштуєте MongoDB на максимальній швидкості, ви зможете довести його до того моменту, коли ви будете досить швидко виконувати синхронні записи з досить швидкої гри, але це коштуватиме цілісності даних, оскільки записи буферні. Це означає, що ви втрачаєте ці дані в разі аварії, тому виконувати запис взагалі мало, і це все повільніше, ніж якщо ви тільки що виконали редагування в пам'яті і зберегли їх згодом, так що ви отримаєте найгірше з обох світів .

Єдиною причиною, по якій я зараз маю намір використовувати MongoDB для всіх моїх даних про ігрові об’єкти, є те, як часто до цього даних ігрового об’єкта будуть доступні (наприклад, щоразу, коли гравець вбивається, бере предмет, вистрілює з рушниці тощо).

Запитайте себе, чому потрібно писати в базу даних, коли гравець стріляє з пістолета. Чому це не можна просто обробляти в пам'яті на ігровому сервері? Якщо ваша гра виходить з ладу і пізніше перезавантажується, і гравець дізнається, що у них на 3 кулі більше, ніж очікувалося, це критична бізнес-проблема?

Мені також подобаються прямі документи без схем (які полегшують відображення даних об’єктів гри).

Це набагато краща причина для вибору підходу NOSQL, ніж питання про продуктивність.

Я маю намір використовувати той самий MongoDB на своєму веб-сайті, щоб відображати інформацію про профіль гравця (я не переймаюся повною послідовністю, деяка затримка з оновленнями в грі нормальна).

Це добре, і розумно. Пізніше, можливо, ви захочете використовувати окремий екземпляр, щоб веб-читання не змагалися з іграми читання і запису, але ця проблема є тривіальною для вирішення порівняно з проблемою отримання достатньо популярної, щоб це була проблемою.

Особисто я просто вибрав би одну з двох баз даних, на основі якої одна робота буде для мене меншою роботою, і стандартизувати її - але немає причин, якщо ви не хочете тримати з двома, якщо вам це подобається.

Усі дані в режимі реального часу потрібно зберігати в пам'яті додатків, все інше було б нерозумно.

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

І як сказав bummzack, вам слід тримати все в одній мережі. Крім того, будьте уважні щодо безкоштовних матеріалів, 240 МБ безкоштовного сховища бази даних звучить добре, але оскільки машина, ймовірно, розділена між великою кількістю безкоштовних користувачів, сервіс може бути досить повільним.

Ви довіряєте вашим 60000 користувачів на базу даних? Якщо ні, то вам слід встановити ідею "доступ до бази даних від клієнта", якщо ваш рівень знань щодо безпеки програмного забезпечення баз даних не є найвищим рівнем, і ви впевнені, що можете вирішити будь-які проблеми, що призводять до цього.