Фрилансер Павел
IT инженер
pavel@wisetip.ru
root4web

Что такое MongoDB?

MongoDB – это нереляционная noSQL СуБД, которая хорошо горизонтально масштабируется (шардинг) и имеет schemaless структуру хранения. В связи с этим идеально подходит для работы с нереляционными данными. И вызывает множество проблем, если в один прекрасный момент вы осознаете, что данные у вас, как раз-таки, реляционные. Если у Вас большой опыт работы с базами данных, то прекрасно поняли о чем идет речь. Если Вы человек далекий от web и вообще от IT, но хотите узнать мою точку зрения без технических подробностей — листайте вниз, где выводы. Всех остальных прошу читать по порядку. =)

Реляционные и нереляционные базы данных

Слово «реляционные» происходит от английского «relation» – отношения. Предположим, у нас есть 2 таблицы: клиенты и заказы. Каждому клиенту может соответствовать один и более заказов. Такое отношение называется «один ко многим» и обозначается 1:N. По аналогии имеем также отношения «один к одному», «многие ко многим». Для объединения двух и более таблиц в один общий вывод применяются инструкции JOIN. Восновном используется INNER JOIN и LEFT JOIN. Вот как раз запросы с подобными конструкциями и есть основная «фишка» реляционных баз данных.

Что касается MongoDB – это типичный представитель НЕРЕЛЯЦИОННЫХ СуБД, то есть в ней нет аналогичных механизмов типа JOIN. А значит, в случае необходимости, придется заниматься объединением данных средствами кода приложения. Вот типичная ситуация: в реляционных БД клиенты хранятся в одельной таблице. В других таблицах просто заполняем ID клиента и когда нужно вывести список заказов с именами (логинами) клиентов - просто делаем JOIN. В MongoDB все будет посложнее... А как же быть? Ну поскольку БД нереляционная, предполагается хранение данных в полностью денормализованной форме.

Денормализация и нормальные формы.

Сначала поговорим о «нормальных формах». Их существует несколько и основная цель избавиться от избыточности данных. Говоря уж совсем просто: каждая строка в таблице должна быть уникальной. Каждый столбец — атомарным (логически неделимым на более простые составляющие). Таким образом, если мы храним в таблице пользователей ФИО, адрес, email и так далее, то в идеале эта информация больше нигде не должна встречаться в текстовом виде. Ни в какой другой таблице. Только id записи из таблицы с пользователями. Полностью нормализованная БД строго отвечает этим правилам.

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

В случае с MongoDB все данные полностью денормализованы, что вызывает большие неудобства при редактировании. Мы должны пробежаться по всем-всем документам (образно говоря - так называются «строки» в документарных БД) и заменить старую информацию на новую. В этом случае появляются проблемы целостности, точно такие же, если бы мы работали с кэшем. Инвалидация данных.

Для чего использовать MongoDB

Становится вполне овчевидным применение данной СуБД исходя из всего вышесказанного. MongoDB идеально подходит для хранения нереляционных данных. Когда сам документ представляет из себя наибольшую ценность. Является конечной сущностью и не нуждается ни в каких связях. На самом деле, довольно сложно представить себе такой тип данных. Вероятно это какие-то картотеки, справочники и т.д.

Зато очень легко представить реляционные данные. Взять хотя бы любую социальную сеть, где наибольшую ценность представляют из себя именно отношения (связи) объекта к другим сущностям. Зарегистрировался человек в социальной сети и он может выступать в качестве комментатора, друга, лайкера... В конце-концов в качестве своей прямой сущности — своей же собственной анкеы. Для хранения такого рода информации, MongoDB не подходит совершенно. Потому что здесь одни связи данных друг с другом. Естественно, наилучшим образом подойдет реляционная СуБД, такая как PostgreSQL или MySQL.

Выводы

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

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

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

Если вам говорят, что проект лучше строить на основе MongoDB в качестве основного хранилища данных — это повод хорошенько задуматься. И в первую очередь о квалификации разработчика. В подавляющем большинстве случаев гораздо правильнее выбрать реляционную БД. Например, MySQL.