MongoDB + Socket.io лучше, чем MySQL + Socket.io для приложения реального времени?

Question

Я создаю приложение в реальном времени и мне интересно, стоит ли мне переходить с MySQL на MongoDB.В моем приложении происходит множество записей, хотя случаи чтения еще выше.В настоящее время я использую XHR на стороне клиент-сервер, но почти также перешел на Socket.io.

Из-за моих исследований я хочу перейти на MongoDB + Socket.io, но хотел узнать мнение сообщества.

обновление В настоящее время я определяю «лучше» более быстрым приложением, если это имеет смысл.Я вроде могу жить без sql, я думаю.В настоящее время используется 0 JOIN и т. Д. Но я пытался выяснить, есть ли у кого-нибудь опыт перехода с MySQL на MongoDB для «универсального» приложения реального времени.

Спасибо.

Answer 1

Это зависит от того, как вы определяете «лучше».

Если реляционная модель и наборы более важны для вас, MySQL «лучше», чем MongoDB.

Если вы можете отказаться ACID , и ваши данные в большей степени основаны на документах, MongoDB "лучше", чем MySQL.

Сложно ответить в любом случае, но особенно если не знать больше о ваших сценариях использования.

Answer 2

Возможно, уже поздно, чтобы добавить это, но у меня был некоторый опыт работы с аналитическим приложением в реальном времени, переходящим с mySQL на mongodb. По моему опыту, MySQL был намного быстрее и отзывчивее, потому что мое приложение было НАПИСАНО ТЯЖЕЛЫМ. Используя innodb, я смог получить блокировки на уровне строк, тогда как при использовании mongodb мне приходилось иметь дело с глобальной блокировкой. Не уверен, что они решили проблему "глобальной" блокировки.

Мое окончательное решение заключалось в использовании innodb и выпуска MySQL в Percona.

Answer 3

MongoDB не является системой управления реляционными базами данных.Сказать, что MongoDB лучше, чем любая СУБД, без предварительного указания данных, показывает реальный недостаток знаний.

В MongoDB не существует ключевых ограничений.Нет никаких проверок ссылочной целостности.Мы используем MongoDB для хранения больших двоичных объектов и храним ключи MongoDB в SQL Server.Это здорово, но я бы никогда не заменил нормализованный экземпляр SQL Server или MySQL RDBMS на MongoDB.

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

Подумайте о том, что происходит со временем, когда вы добавляете / удаляете свойства из вашего JSON или добавляете / удаляете справочные данные на основе меняющихся бизнес-правил.Подумайте о том, как это преобразование будет выглядеть в MongoDB по сравнению с экземпляром RDBMS.

Я знаю, что звучу довольно критично по отношению к MongoDB, но я не хочу этого делать.Мы используем его, и он хорошо работает для наших нужд, но это не замена СУРБД.Больше дополнения.