|
MySQL vs MongoDB для браузерной игры
|
|
| Folleah | Дата: Четверг, 24 Апреля 2014, 18:25 | Сообщение # 1 |
Архитектор
Сейчас нет на сайте
| Собственно, какая бд будет лучше для клиент-серверной браузерной онлайн игры?
P.S. Я вкурсе, что это две разные базы данных, с разной структурой и архитектурой. Имеется ввиду простота использования и взаимодействия с сервером, подача игровых данных в БД, взятие, скорость работы всего этого.
Сообщение отредактировал Folleah - Четверг, 24 Апреля 2014, 18:29 |
|
|
| |
| last2424 | Дата: Четверг, 24 Апреля 2014, 18:46 | Сообщение # 2 |
30 мл. блоков
Сейчас нет на сайте
| Folleah, MySQL и только MySQL.
Минусов не вижу.
Предупреждение: всё что я написал в зачёркнутом виде является шуткой и никак не пытает обидеть того к кому обращаются.(нет)
|
|
|
| |
| Folleah | Дата: Четверг, 24 Апреля 2014, 18:54 | Сообщение # 3 |
|
Архитектор
Сейчас нет на сайте
| last2424, а я только собрался копать доки Mongo  Подожду ещё советов, но если MySQL действительно так хорош, буду использовать его, т.к. к нему уже привык.
|
|
|
| |
| Assasin | Дата: Четверг, 24 Апреля 2014, 20:40 | Сообщение # 4 |
web-coder
Сейчас нет на сайте
| Работал только с MySQL, так что кроме неё посоветовать нечего.
|
|
|
| |
| Tiendil | Дата: Четверг, 24 Апреля 2014, 23:06 | Сообщение # 5 |
участник
Сейчас нет на сайте
| Цитата Folleah (  ) Собственно, какая бд будет лучше для клиент-серверной браузерной онлайн игры?
Та, которая будет лучше знакома разработчкиам.
При правильной архитектуре вы в базу не упрётесь.
Но учитывайте, что многие фреймворки для веба заточены на работу с реляционными БД. И если вы будете их использовать, то придётся использовать реляционную БД. А использовать их вы будете, т.к. вам как минимум нужен форум и сайт. Плодить же зоопарк из баз данных — плохая идея.
Участвовал в разработке Order of War (C++ UI & логика) и WoT (Python портал worldoftanks.ru почти всё :-) )
Текущий проект: the-tale.org - indie mmozpg
|
|
|
| |
| Folleah | Дата: Пятница, 25 Апреля 2014, 08:00 | Сообщение # 6 |
|
Архитектор
Сейчас нет на сайте
| Tiendil, верно, но сайт будет взаимодействовать с сервером (как и приложение), так что тут можно опять использовать nosql БД, а форум - тут отдельной БД легче реализовать, как и поступает большинство проектов. Конечно, mysql удобен, но упор в серверах сделан на nosql (в сторону асинхронности), поэтому выбор БД вызывает у меня противоречивые чувства. Вот так
|
|
|
| |
| Tiendil | Дата: Пятница, 25 Апреля 2014, 09:54 | Сообщение # 7 |
|
участник
Сейчас нет на сайте
| Цитата Folleah ( ) Tiendil, верно, но сайт будет взаимодействовать с сервером (как и приложение), так что тут можно опять использовать nosql БД, а форум - тут отдельной БД легче реализовать, как и поступает большинство проектов. Конечно, mysql удобен, но упор в серверах сделан на nosql (в сторону асинхронности)
Т.е. вы будете сайт с нуля делать? или использовать фреймворк, работающий с NoSQL? Сайт же, это не только посадочная страница, это и CMS и всякие вспомогательные сервисы.
Отдельная БД для форума — нормально, отдельная СУБД — много.
Ну и как-то не слышал об особых сверхпреимуществах NoSQL в асинхронности.
Участвовал в разработке Order of War (C++ UI & логика) и WoT (Python портал worldoftanks.ru почти всё :-) )
Текущий проект: the-tale.org - indie mmozpg
|
|
|
| |
| mbit | Дата: Пятница, 25 Апреля 2014, 12:17 | Сообщение # 8 |
|
частый гость
Сейчас нет на сайте
| На самом деле всё зависит от Вашей архитектуры проекта и от предполагаемой нагрузки. По своему опыту могу сказать - если Ваша игра будет пользоваться бешенным спросом и регулярным онлайном с Запросами в БД более 4000 в сек. то только NoSQL - в Вашем случае это MongoDB. В других же случаях - реляционные базы (MySQL) справятся со своей задачей на ура (при правильном проектировании естественно).
Сообщение отредактировал mbit - Пятница, 25 Апреля 2014, 12:19 |
|
|
| |
| Folleah | Дата: Пятница, 25 Апреля 2014, 15:07 | Сообщение # 9 |
|
Архитектор
Сейчас нет на сайте
| Цитата Tiendil ( ) Сайт же, это не только посадочная страница, это и CMS и всякие вспомогательные сервисы.
Я вкурсе, я как бэ веб-девелопер.
Цитата mbit ( ) По своему опыту могу сказать - если Ваша игра будет пользоваться бешенным спросом и регулярным онлайном с Запросами в БД более 4000 в сек. то только NoSQL - в Вашем случае это MongoDB. В других же случаях - реляционные базы (MySQL) справятся со своей задачей на ура (при правильном проектировании естественно).
ВОТ! Об этом и речь, запросов будет много, это же онлайн игра, какой-то игрок вылетел, сотня заходит, запись статистики у другого - это все может быть в один момент.
|
|
|
| |
| maker-rus | Дата: Пятница, 02 Мая 2014, 16:12 | Сообщение # 10 |
Гений
Сейчас нет на сайте
| Цитата Folleah ( ) ВОТ! Об этом и речь, запросов будет много, это же онлайн игра, какой-то игрок вылетел, сотня заходит, запись статистики у другого - это все может быть в один момент.
Тогда готовь деньги,на SSD и не одну штуку (потому лететь будут на раз), потому что диски грузить будет адски, если ты собрался nosql юзать с огромным количеством запросов. 
|
|
|
| |
| HerrPotapov | Дата: Пятница, 02 Мая 2014, 23:34 | Сообщение # 11 |
|
заслуженный участник
Сейчас нет на сайте
| Folleah, в порядке эксперимента я бы тебе рекомендовал попробовать сделать небольшую игру с Mongo. Серьезный проект - наверное не стоит, если знания у тебя на уровне "хотел почитать доки".
Сам я немного в монго разбираюсь, доки читал, удачно подвернувшуюся конференцию посетил, послушал доклады от разработчиков. Штука очень интересная, но вообще насколько мне известно основной сценарий использования для NoSQL вообще - сбор больших объемов данных. Т.е. данные сначала складываются как придется в монго, потом прогоняются через фильтры и то что осталось закидывается для долговременного хранения в обычную SQL базу данных.
Плюс еще один сценарий - быстрое прототипирование. В коллекциях (на языке SQL - таблицы) нет четкой структуры, поэтому два документа (запись в таблице) из одной коллекции могут иметь разный набор полей. Ну например
Код {"name": "Alex", "age": 20, "hobbies": ["programming", "skiing"]}
(да-да, массивы тоже разрешены и в общем случае нужно использовать именно их, а не нормализовывать данные) и
Код {"first_name": "Alex", "second_name": "Potapov", "birthdate": "2.2.1950"}
Это позволяет просто менять в коде структуру и не парится о том что происходит в самой БД. Только потом нужно очень аккуратно с этими данными работать =)
Самый большой минус монго - отсутствие JOIN. Точнее они есть, но противоречат концепции, поэтому работают чертовски медленно и неэффективно.
Самый большой плюс - горизонтальное масштабирование "из коробки". Почти никакой настройки не требуются, все просто работает.
Discord: alpotapov#1741
Интервью с разработчиком WarCastle - Читаем и вникаем!
|
|
|
| |
