MongoDB или MySQL для сложной браузерной игры на Rails

Question

Я реализую браузерную игру с небольшой группой друзей, используя RoR, предназначенную для развертывания на Heroku. Мы реализовывали все, что касается баз данных на MySQL. Тем не менее, бесплатные / дешевые базы данных Myok в Heroku являются общими и неэффективными, а промежуточный уровень отсутствует; посвященные довольно дороги для нашего начала. Поэтому мы начали рассматривать предоставляемые решения MongoDB, которые намного более доступны при рассмотрении цен.

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

Следовательно, будут ли какие-либо проблемы с производительностью или проблемы с использованием MongoDB? Я знаю, что, хотя он может создавать отношения между своими коллекциями, это не означает 100%, верно? Должны ли мы придерживаться плохой и общей базы данных MySQL до тех пор, пока мы не сможем позволить себе выделенную базу данных или в ней нет необходимости, и мы сможем придерживаться MongoDB без особых проблем?

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

Answer 1

Скорее невозможно ответить. Только вы и ваша команда знаете вашу модель данных и знаете, может ли она вписаться во вложенный иерархический документ.

Тот факт, что у вас есть много ограничений внешнего ключа, таблиц, JOIN и т. Д., Не означает, что вы не можете изменить всю модель данных для работы с MongoDB (или любым другим NoSQL в этом отношении), но вам, вероятно, потребуется проделайте немало работы, чтобы изменить модель данных и шаблоны доступа.

К сожалению, как я уже говорил выше, мы не знаем, возможно ли это с вашим текущим дизайном приложения.

Выезд http://www.mongodb.org/display/DOCS/Schema+Design и http://www.slideshare.net/kbanker/mongodb-schema-design

Answer 2

Я работаю с mySQL и mongoDB для разных приложений.

Когда мы работаем с объектно-ориентированной структурой, мы обычно используем mongoDB поверх mySQL из-за того, что mongoDB является объектно-ориентированной.

Когда нам требуется больше реляционных данных (например, профилей пользователей, дружеских отношений и сообщений), мы используем mySQL, так как он определенно лучше для реляционных данных.

Моя команда считает, что первая неделя с mongoDB немного сложная (так как большинство из них используются в mySQL), но после этого они обычно предпочитают работать с ней, например, не требуются предопределенные схемы, просто начните с Коллекция. Порядок данных в mongoDB должен соблюдаться НАМНОГО больше, чем в mySQL. Итак, вы знаете, что мы используем jQuery AJAX со структурой JSON поверх PHP с mongoDB для текущего приложения, над которым мы работаем.

Техническое обслуживание и администрирование, большая часть множества вещей, но mongoDB действительно борется больше, если SOMEONE (я не называю имена Pablo) забывает что-то индексировать. Из-за этого у нас произошел сбой сервера monogDB через пару недель. Я перезапустил сервер и снова потерпел крах, поэтому мне пришлось перенаправить весь трафик на другой временный сервер, который собирался подключиться к сети в качестве резервного сервера для mongoDB, из-за этого все было готово для того, чтобы новый сервер принял место существующего сервера временно к счастью. Когда я запустил сервер без запросов, обнаружил проблему, добавил индекс, и как только я добавил его и снова включил, процессоры перешли с безумно высокого уровня в нормальный, с тех пор проблем не было.

Лично я стараюсь быть немного более активным с mongoDB, потому что возникающие проблемы могут быть более серьезными, чем mySQL, в том, что произошло с нашим сбоем, mySQL, вероятно, будет испытывать медлительность, но mongoDB в той же ситуации вылетал полностью.

Мне они оба нравятся, и я буду использовать их для перехода в будущее, но правильный выбор и выполнение основ действительно важны, особенно для mongoDB, по моему мнению.

Надеюсь, это дополнительное понимание немного поможет.

Answer 3

Приложение, которое зависит от большого количества реляционных данных, вероятно, не должно быть реализовано в нереляционной базе данных.