noSQL - чи допустимий варіант для веб-ігор? [зачинено]

Не маючи можливості та нудьги, ми з другом вирішили зробити веб-гру. Це перша «гра», яку я буду робити, оскільки зазвичай я програмую веб-програми на джанго.

Я вирішив використовувати ту саму основу для гри, але я не зовсім впевнений у зберіганні даних, оскільки не можу передбачити майбутні вимоги та проблеми, пов’язані з БД. Останнім часом рух noSQL набирає сили, і я хотів би вивчити цю область.

Тому у мене є такі питання:

• Чи підходить noSQL сховище даних (на основі документів, наприклад MongoDB), для веб-гри?
• Які проблеми можуть виникнути при використанні звичайних RDBMS, таких як MySQL?
• Як застрахувати узгодженість даних між користувачами MongoDB, під час гри або під час приурочених подій, таких як завдання на платформі?

Огляд гри: Типова пригодницька гра, в якій гравець бореться з монстрами та отримує предмети тощо.

• Деякі дані є статичними для всіх гравців: предметів, зброї, зілля, карт тощо.
• Деякі дані, прив’язані до гравця: інвентар, показники (статистика), прогрес тощо.
• Гравець, можливо, повинен знати статистику та стан іншого гравця
• Заплановані завдання виконуватимуться через певний проміжок часу

Чи підходить база даних noSQL для веб-гри?

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

Які проблеми можуть виникнути при використанні звичайної RDBMS?

Є два основні недоліки використання реляційних баз даних:

• Відсутність гнучкості в моделюванні даних
• Продуктивність

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

weapon_type_id | weapon_type
1 | sharp

weapon_id | weapon| weapon_type_id | damage
1 | Short Sword | 1 | 5

potion_type_id | potion_type
1 | HP
2 | Mana

potion_id | potion| potion_type_id | modifier
1 | Healing Elixer | 1| 5
2 | Mana Drainer | 2| -5

Тепер подумайте, як вам потрібно змінити модель, щоб відповідати, зробіть наступне:

• Додати новий тип елемента
• Створіть зброю з декількох типів зброї
• Створіть предмет зілля, який також можна використовувати як зброю

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

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

db.itemTypes

name: Weapon
types: Sharp

name: Potion
types: HP, Mana

db.items

name: Short Sword
weapon
    type: Sharp (db.itemTypes reference)
    damage: 5

name: Healing Elixer
potion
    type:  HP (db.itemTypes reference)
    modifier: 5

name: Mana Drainer
potion
    type:  Mana (db.itemTypes reference)
    modifier: -5  

name:  Healing Potion Sword
potion
    type: HP (db.itemTypes reference)
    modifier: 10
weapon
    type: Sharp (db.itemTypes reference)
    damage: 15

Є багато хороших статей про продуктивність баз даних NoSQL vs SQL, але ось одна, яка надає приклади додатків, щоб ви могли виконати власні тести: MongoDB vs. SQL Server 2008 Showdowndown

Як забезпечити послідовність даних серед користувачів MongoDB?

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

Правка: Наведено приклад NoSQL бази даних елементів

Пару слів захищають бази даних SQL.

1 - Якщо у вас є база даних SQL, ви можете працювати зі своїми даними не лише первинним ключем. Більшість запитів у MMO йде PK, але коли вам потрібно знайти всіх користувачів рівнем> 30, що ви будете робити у світі NoSQL?

2 - Якщо у вас є мова SQL, ви можете створити «виправлення» для відновлення зламаних даних. Наприклад: "update player_items set flag = 0 where item_type_id = 100". Як виправити це в NoSQL? Я думаю, вам доведеться зробити сценарій, який буде аналізувати всі ваші дані ...

3 - бази даних SQL не такі повільні, як можна подумати. Мої колеги створюють веб-гру MMO-гру, яка робить 5000 транзакцій в секунду в MySQL. Вам недостатньо? Якщо ні, ви можете використовувати шарнінг для масштабування вашої бази даних.

4 - SQL має обмеження для зовнішніх ключів та такі добрі речі, які допоможуть вам знайти помилки у вашому коді.

NoSQL - це не срібна куля. Він вирішує лише пару проблем і приносить багато нових проблем. Тому моя порада - подумайте двічі, перш ніж вибирати NoSQL.

Відповідь - так, це вірний варіант, але ні, це, мабуть, не чудова ідея .

Є дві основні проблеми з SQL, з якими NoSQL намагається вирішити, коли мова йде про ігри.

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

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

Але ця проблема не стосується веб-ігор. У вас вже є високий латентний зв’язок між програвачем та грою, тому ви можете також отримати пропускну здатність, яку надає SQL, а також переваги зрілого, добре відомого програмного забезпечення.

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

Бази даних на основі документів, як CouchDB та MongoDB, вирішують цю проблему, просуваючи документ до об'єкта верхнього рівня, а не до рядка ("документ" у цьому випадку є синонімом "об'єкт"). Але, роблячи це, вони втрачають багато переваг баз даних SQL. Пропускна здатність значно нижча, а алгоритми блокування значно ускладнюються.

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

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

• Чи підходить noSQL сховище даних (на основі документів, наприклад MongoDB), для веб-гри?

Я б радив поглянути на couchdb

Її інтерфейс на основі JavaScript, тому він буде добре поєднуватися з іграми на базі HTML5 / javascript.

Він також може працювати "офлайн" (створюючи локальну копію db), а потім згодом синхронізувати себе із сервером (ви можете використовувати це для встановлених підземелля, наприклад)

• Які проблеми можуть виникнути при використанні звичайних RDBMS, таких як MySQL?

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

Наприклад, подивіться, як виконуються " запити " в couchdb. Все робиться в JavaScript.

• Як застрахувати узгодженість даних між користувачами MongoDB, під час гри або під час приурочених подій, таких як завдання на платформі?

Процес "синхронізації" баз даних називається реплікацією в мові couchdb. Ви також багато побачите термін послідовність . Є кілька вбудованих сервісів, які займаються реплікацією та послідовністю. Див., Наприклад, процес додаткової реплікації .

Залежно від того, що є у вашій грі, ви можете використати і те, і з'єднати їх через моделі вашої гри. Наприклад, програвач може і повинен бути в RDB (інформація про вхід), але інвентар / змінне сховище гравця може перейти до noSQL, тому ваш модуль програвача може login()використовувати RDB та fetchInventory()використовувати noSQL за допомогою первинного ключа.

Карти, наприклад, краще зберігати в NoSQL (координати => масив різних об'єктів, наприклад). Я не уявляю, як зберігати те, що містить область в RDB (крім серіалізованої рядки, яку потрібно повністю несеріалізувати, щоб прочитати якусь частину? Більше ЦП і оперативна пам’ять витрачається!) Добре, що ви все ще можете зберегти області в RDB, наприклад, область "місто X" містить такі кординати / блок ([3,4], [8,7] ...)

ви могли б і, ймовірно, повинні використовувати і те, і інше, і заглянути в енергонезалежне сховище, як memcache, який вам може знадобитися, або деякі тимчасові дані (було б швидше, ніж використання жорсткого диска точно!

тому в підсумку>

це залежить від того, що ви хочете мати у своїй грі! жир