Попробовать
демоверсию
Бесплатная демоверсия позволяет ознакомиться со всеми возможностями нашего биллинга
+7 499 940-95-05

За и против: Когда стоит и не стоит использовать MongoDB

Разработчик и сотрудник проекта CloudBoost.io Наваз Дандала (Nawaz Dhandala) написал материал о том, почему в некторых случаях не стоит использовать MongoDB. Мы в "Латере" уже много лет работаем с этой СУБД, поэтому решили представить и свое мнение по данному вопросу.

Дандала сразу оговаривается, что работал со многими СУБД (как SQLб, так и NoSQL) и считает MongoDB отличным инструментом, однако существуют сценарии, в которых его применение нецелесообразно.

Документоориентированные СУБД такие, как MongoDB, прекрасно справляются с хранением JSON-данных, сгруппированных в «коллекции». В таком формате можно хранить любые JSON-документы и удобно категоризировать и по коллекциям. Содержащийся в MongoDB JSON-документ называется двоичным JSON или BSON и, как любой другой документ этого формата, является неструктурированным. Поэтому, в отличии от традиционных СУБД, в коллекциях можно сохранять любые виды данных, и эта гибкость сочетается с горизонтальной масштабируемостью базы данных. Эта возможность нравится многим разработчикам, однако «не все так однозначно».

Если MongoDB такая классная, почему ее не используют все и всегда?

Выбор СУБД зависит в том числе и от того, что за приложение планируется создать. То есть базу данных выбирают не разработчики, а сам продукт, убежден Дандала. Он приводит пример, подтверждающий этот тезис.

При создании приложения, концепция которого подразумевает работу с документами, MongoDB будет хорошим выбором. К такому типу приложений можно отнести, к примеру, движок блог-платформы, где каждый автор сможет иметь по несколько блогов, и каждый из них будет содержать множество комментариев. База данных для обслуживания такого приложения должна быть легко расширяемой, и здесь MongoDB подойдет как нельзя лучше.

Однако, необходимо отметить, что у MongoDB нет связей между документами и “коллекциями” (частично это компенсируется Database Reference — ссылками в СУБД, но это не полностью решает проблему). В итоге, возникает ситуация, при которой имеется некий набор данных, который никак не связан с другой информацией в базе, и не существует никакого способа объединить данные из различных документов. В SQL-системах это было бы элементарной задачей. 

Здесь возникает другой вопрос — если в MongoDB нет связей и возможностей по объединению двух таблиц, то зачем ее тогда вообще использовать? Ответ — потому что эта СУБД отлично масштабируется, и по сравнению с традиционными SQL-системами, гораздо быстрее осуществляет чтение и запись.MongoDB прекрасно подходит для приложений, в которых практически не используются данные с зависимостями и необходима масштабируемость базы данных. 

Многие разработчики применяют MongoDB и для хранения связанных данных, реализуя объединения вручную в коде — этого достаточно в сценариях «одноуровневого» объединения или малого количества связей. То есть данный метод далеко не универсален.

Так какую СУБД выбрать?

Существует огромное количество различных СУБД, и каждая из них соответствует определённому набору требований, которые разработчики предъявляют к своему приложению: 

  • Документоориентированные СУБД (к примеру, MongoDB): Как уже сказано выше, документоориентированные СУБД используются для хранения JSON-документов в “коллекциях” и осуществления запросов по нужным полям. Можно использовать эту базу данных для создания приложений, в которых не будет содержаться слишком большого количества связей. Хорошим примером такого приложения является движок для блог-платформы или хранения каталога продуктов.
  • Графовые СУБД (например Neo4j): Графовая СУБД используется для хранения между субъектами, где узлы являются субъектами, а грани — связями. Например, если разработчики создают социальную сеть, и один пользователь подписывается на другого, то пользователи являются узлами, а их “подписка” — связью. Такие СУБД прекрасно справляются с образованием связей, даже если глубина таких связей более ста уровней. Этот инструмент столь эффективен, что может даже позволяет выявлять мошенничество в сфере электронной коммерции.
  • Кэш (например Redis): Такие СУБД используются, когда требуется крайне быстрый доступ к данным. Если создается приложение для интернет-торговли, в котором есть подгружаемые на каждой страницы категории, то вместо обращения к базе данных при каждом чтении, что крайне затратно, можно хранить данные в кэше. Он позволяет быстро осуществлять операции чтения/записи. Дандала советует применять СУБД, использующие кэш, в качестве оболочки для обработки часто запрашиваемых данных, избавляющей от необходимости совершения частых запросов к самой базе.
  • Поисковые СУБД (например ElasticSearch): В случае необходимости осуществления полнотекстового поиска по базе данных (например поиск продукции в ecommerce-приложении), то хорошей идее будет использование поисковой СУБД вроде ElasticSearch. Эта система способна искать по огромному массиву данных и обладает обширной функциональностью — например, СУБД умеет осуществлять поиск по именованным категориям.
  • Строковые СУБД (например Cassandra): СУБД Cassandra используется для хранения последовательных данных, логов, или огромного объема информации, который может генерироваться автоматически — к примеру, каким-нибудь датчиками. Если разработчики собираются использовать СУБД для записи больших массивов данных и при этом планируется, что будет намного меньше обращений для чтения и данные не будут иметь связи и объединения, тогда Cassandra будет хорошим выбором, уверен Дандала.
 
Использование комбинации баз данных
 

 

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

Например, если в приложении есть функция поиска, то его можно реализовать с помощью ElasticSearch, а уже для хранения данных без связей лучше подойдет MongoDB. Если речь иет о проекте в сфере «интернета вещей», где огромное количество всевозможных устройств и датчиков генерируют гигантские объёмы данных, вполне разумно будет использовать Cassandra.

Принцип, при котором используются несколько СУБД для работы в одном приложении, называется “Polyglot Persistence”. В этой статье можно почитать о плюсах и минусах такого подхода.

Наш опыт

Наша биллинговая система «Гидра» использует для учета первичных данных и хранения финансовой информации реляционную СУБД. Она идеально подходит для этих целей. Но некоторые модули Гидры, например, RADIUS-сервер, работают под высокой нагрузкой и могут получать тысячи запросов в секунду с жесткими ограничениями на время обработки запроса. Кроме того, в БД нашего автономного RADIUS-сервера данные хранятся в виде набора AVP (attribute/value pair). В таком сценарии реляционная СУБД уже не выглядит лучшим решением, и тут на помощь приходит MongoDB с ее хранилищем документов произвольной структуры, быстрой выдачей ответа и горизонтальной масштабируемостью.

При эксплуатации более чем на 100 инсталляциях Гидры на протяжении последних 5 лет серьезных проблем с Mongo мы не обнаружили. Но пара нюансов все же есть. Во-первых, после внезапного отключения сервера БД хоть и восстанавливается благодаря журналу, но происходит это медленно. К счастью, необходимость в этом возникает нечасто. Во-вторых, даже при небольшом размере БД редко используемые данные сбрасываются на диск и когда запрос к ним все же приходит, их извлечение занимает много времени. В результате нарушаются ограничения на время выполнения запроса.

Все это относится к движку MMAPv1, который применяется в Mongo по умолчанию. С другими (WiredTiger и InMemory) мы пока не экспериментировали — проблемы не настолько серьезны.

Подписывайтесь на наш блог, чтобы не пропустить ничего интересного!

26.03.2016

Другие публикации

По определению консалтинговой компании Deloitte, текущий период в мировой экономике характеризуется неопределенностью. Поэтому бизнес во всем мире стремится к оптимизации и снижению издержек. Сегодня мы рассмотрим несколько способов, с помощью которых компании из разных стран экономят уже сейчас.
В новой версии Гидры мы по традиции продолжили работу над коммерческими возможностями биллинга. Встречайте контрактные тарифы! Другие мелкие улучшения упрощают интеграцию Гидры с внешними системами.
Компании из самых разных отраслей бизнеса сталкиваются с часто повторяющимися бизнес-процессами, связанными с обработкой заявок. В большинстве отраслей выполнение типовых работ и услуг — это сложный и разветвленный бизнес-процесс. Мы много размышляли об этих проблемах и создали инструмент, который каждая компания могла бы легко адаптировать под себя — новый продукт Гидра OMS
В одном из наших постов мы уже описывали ситуацию, в которой бесконтрольный рост таблиц в базе данных одной компании-пользователя нашей системы привел к настоящему DoS. Сегодня речь пойдет о еще одном интересном случае внезапного сбоя, который сделал «день смеха» 1 апреля этого года совсем не смешным для службы поддержки «Латеры».
В Instagram развертывание backend-кода (основная программно-аппаратная часть, с которой работают клиенты) происходит от 30 до 50 раз в день, каждый раз, когда инженеры подтверждают изменение оригинала. И, по большей части, без участия человека — сложно в это поверить, особенно учитывая масштабы соцсети, но факт остается фактом.
В этой заметке речь пойдет о масштабировании. Разработчики open-source почтового приложения Nylas опубликовали в своем блоге материал о том, как им удалось масштабировать систему в 20 раз за три недели с помощью инструмента ProxySQL. Для этого им пришлось переехать с Amazon RDS на MySQL на EC2.
Интересный материал о работе с JSON, и в частности, о применении ограничений опубликовал в своем блоге разработчик Магнус Хагандер (Magnus Hagander) — в нашем блоге мы решили представить его основные идеи.
Успешно завершили интеграцию биллинга Гидра с порталом NEXT TV.
В этой заметке мы рассказываем о плюсах и минусах денормализации баз данных. Разработчик баз данных и финансовый аналитик Эмил Дркушич (Emil Drkušić) написал в блоге компании Vertabelo материал о том, зачем, как и когда использовать этот подход. Мы представляем вашему вниманию главные тезисы этой заметки и делимся своим опытом.
Разработчики из американской компании Gaslight написали интересный материал о том, почему организация, известная своей любовью к Ruby и Ruby on Rails, решила инвестировать в освоение новых технологий — например, Clojure. Мы тоже работаем с этим языком программирования, поэтому решили выделить главные тезисы команды Gaslight в отдельный материал.
Немецкий журналист и хакер Ляйф Риге (Leif Ryge) написал для издания Ars Technica интересный материал о том, что современный подход к организации обновлений программного обеспечениях несет в себе серьезные риски информационной безопасности. Мы представляем вашему вниманию главные мысли этой заметки.
Инженер проекта Haleby.se написал материал, в котором рассказал о причинах выбора в качестве инструмента оркестрации Docker-контейнеров технологии Kubernetes. Мы представляем основные мысли этой заметки.
Адаптация заметки бывшего сотрудника Amazon про то, почему плохие продукты пользуются большим успехом, опубликованная в авторской колонке Дмитрия Копловича на Rusbase.
Поучительная история из жизни нашей техподдержки про то почему операторам нужно мониторить размеры таблиц в своих базах.
Инженер компании Akalak & Neo Technology Горка Садаковски (Gorka Sadakowski) написал интересный материал о том, как использование графовых баз данных может в режиме реального времени предотвращать мошенничество в сфере электронной коммерции. Мы представляем вашему вниманию основные мысли этой заметки.
Платежные протоколы уязвимы — об этом рассказали немецкие исследователи информационной безопасности на конференции Chaos Computing Club. Предлагаем вам адаптированный перевод их выступления.
Наша адаптация заметки разработчика и системного архитектора Михаэля Виттига о наиболее распространенных ошибках в использовании Amazon Web Services.
Наш адаптированный перевод заметки главного разработчика Azure Джеффа Уилкокса, о том, как более двух тысяч членов команды проекта переезжали на GitHub.
Представляем вашему вниманию адаптированный перевод одной из глав книги «Архитектура open-source-приложений», в которой описываются предпосылки появления, архитектура и организация работы популярного веб-сервера nginx.
Наш сегодняшний пост посвящен тому как мы писали софт для контроля работы удаленных сотрудников.
Сегодня мы расскажем про устройство системы подпольного банкинга Хавала, которая возникла еще в VIII веке и до сих пор пользуется большой популярности в странах Среднего Востока, Азии и Африки.
Мы уже рассказывали о том какие проблемы могут возникнуть у компании при саомостоятельной разработке сложных систем. Сегодня мы поговорим о том, как мы работали над повышением отказоустойчивости «Гидры».
Адаптированный перевод заметки главного инженера LinkedIn Джоша Клемма о процессе масштабирования инфраструктуры социальной сети.
Адаптированный перевод заметки инженера финансового стартапа Stripe о том, как его команда мигрировала огромное количество записей в базе данных.
По нашим оценкам, около половины российских операторов связи используют самописный (или переписанный до неузнаваемости простенький «покупной») софт. Сегодня мы поговорим о возможных минусах такого подхода.
Появились маркетинговые инструменты для сегментации абонентской базы, управления скидками и пакетными предложениями.
Подробнее читайте в блоге.
В новой версии мы полностью переработали механизм работы с услугами. Это сразу дало несколько серьезных улучшений, но полностью все заложенные в новой версии возможности будут раскрыты в следующих версиях.
В новой версии была полностью переработана система прав доступа. Новая система уникальна и позволяет реализовать самые смелые замыслы по разграничению доступа сотрудников к биллингу.

Начните знакомство с Гидрой прямо сейчас

Попробовать демоверсию Купить Гидру

Оформление демоверсии

Пожалуйста, укажите реальный email, на него придут данные для доступа в демо.
Все поля являются обязательными для заполнения.
.hydra-billing.com

Для вас будет развернута персональная облачная версия Гидры.
Нажимая кнопку "создать демоверсию" вы соглашаетесь с
Политикой обработки персональных данных.

Мы можем вам перезвонить

Нажимая кнопку "отправить" вы соглашаетесь с
Политикой обработки персональных данных.

Напишите нам!

Ваша компания

Услуги, которые вы предоставляете:

Нажимая кнопку "отправить" вы соглашаетесь с
Политикой обработки персональных данных.

Скачать буклет

Ваш адрес:

Хотите узнать больше?

Рассылка делается примерно раз в месяц. Мы обещаем бережно хранить ваш электронный адрес и никому его не выдавать даже под пытками.