MongoDB, MySQL или что-то третье для моего проекта?

Question

Хорошо, ребята.

Я начал разрабатывать небольшой проект для свободного времени, который может когда-нибудь стать большим.Прежде чем я действительно начну, я хочу быть уверенным, что я начинаю с правильной настройки.Итак, я прихожу к вам.

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

До сих пор я планировал использовать MySQL, но мой друг, который является частью проекта, sugested MongoDB вместо.Он говорит мне, что это увеличит производительность и будет более масштабируемым.С другой стороны, я думаю, что для того, чтобы получить все задачи, назначенные конкретному пользователю, или всех пользователей, назначенных на конкретную задачу, нужно использовать объединения, которых нет в MongoDB (или которые громоздки какнасколько я понял).

Теперь мой вопрос к вам: «Какую систему БД вы бы предложили. MySQL или MongoDB или третий вариант? И почему?»

Спасибо за ваше времяи ваша помощь.

Мортен

Answer 1

Мы используем MySQL в IGN для хранения отношений между людьми (многие-ко-многим, как в вашем случае использования), и имеем около 5 миллионов записей в таблице отношений.У нас есть 4 сервера MySQL в кластере, и чтения распределены по 3 ведомым MySQL.Кстати, вы всегда можете денормализовать, чтобы оптимизировать чтение и штрафные записи, помимо прочего, исходя из тяжести чтения / записи вашей системы.

Мы используем шаблон DAO с Spring, поэтому нам довольно легко поменять поставщиков БД с помощью конфигурации (и, при необходимости, написав реализацию DAO Mongo / MySQL).Мы перевели деятельность (как в социальных сетях) в Монго почти год назад, но отношения с людьми в MySQL живут хорошо.

Answer 2

Комментарий к вашему сообщению Джонаса говорит сам за себя,

При необходимости вы всегда можете масштабировать позже.

Это.

Я очень склонен думать, что If you don't have scaling problems, don't worry too much (if at all) about scaling problems. Почему бы не использовать самое простое, умное и чистое для доставки функций, которые платят клиенты (по крайней мере, в моем случае! ) Такой подход экономит много времени и энергии и подходит для 9 проектов из 10.

Изучать технологию, потому что она отлично масштабируется. Быть привязанным к неизученной технологии и неизвестной технологии, потому что она масштабируется в будущем проекте, не так уж велика. Есть много других факторов, кроме масштабируемости, при использовании сторонних материалов.

MySQL может показаться хорошим выбором. MySQL более зрелый и имеет множество клиентских библиотек, ORM и других экономящих время технологий. MySQL может обрабатывать миллионы (миллиарды, если у вас есть оперативная память) строк. Мне еще не приходилось сталкиваться с проектом, с которым он не мог справиться, и я видел несколько довольно впечатляющих наборов данных!

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

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

Мои 2 цента, счастливого кодирования!

Answer 3

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

Выберите базы данных с открытым исходным кодом либо MySQL, либо Postgres, в зависимости от того, с кем ваша команда лучше всего знакома и как она интегрируется в остальную часть вашего стека инфраструктуры.

Убедитесь, что вы проектируете свою модель данных правильно, что наиболее важно - отношения между сущностями.

Удачи!

Answer 4

MySQL

Любой из них, вероятно, сработает для ваших целей, но ваша база данных выглядит относительно жесткой по своей структуре, с чем хорошо работает SQL. Поэтому я бы порекомендовал MySQL . Отношение «многие ко многим» относительно легко реализовать и получить к нему доступ.

Вы можете немного снизить производительность, но, по моему опыту, это, как правило, не очень заметно в приложениях меньшего масштаба (т.е. в базах данных с менее чем миллионами записей). Однако я согласен с комментарием @Jonas Elfström: между вашим приложением и базой данных должен быть уровень абстракции, поэтому, если масштабирование станет проблемой, вы сможете решить ее без особых проблем.