Что быстрее mysql или mongodb
Национальная библиотека им. Н. Э. Баумана
Bauman National Library
Персональные инструменты
Сравнение производительности MongoDB vs MySQL
Если посмотреть DB-Engines Ranking, то можно увидеть, что в течение многих лет популярность open source баз данных растет, а коммерческих — постепенно снижается. [1] Для многих приложений используют несколько различных баз данных для того, чтобы задействовать их сильные стороны. Ни одна база данных не оптимизирована для всех возможных потребностей. С одной стороны, это хороший выбор, с другой — нужно пытаться найти баланс, так как чем больше разных технологий задействовано в компании, тем сложнее их поддерживать, особенно если компания не очень большая.
Для того, чтобы сузить круг используемых баз данных, можно определиться с основным операционным хранилищем и использовать вместе с ним какие-то дополнительные сервисы. Например, для кэширования или полнотекстового поиска. При выборе основного операционного хранилища возникает два основных варианта: с одной стороны — проверенные временем реляционные СУБД, с другой — различные нереляционные подходы к хранению данных.
Эти рассуждения и подводят нас к сравнению именно MySQL и MongoDB, которые, согласно DB-Engines Ranking, являются самыми популярными представителями реляционных и нереляционных баз данных соответственно. К тому же компания MongoDB изначально очень активно фокусировалась на пользователях MySQL, поэтому очень часто у людей есть опыт использования и выбор между этими двумя технологиями.
В данной статье мы сравним производительность этих двух баз данных.
Содержание
Сравнение основных возможностей
MongoDB (от англ. humongous — огромный) — документоориентированная система управления базами данных (СУБД) с открытым исходным кодом, не требующая описания схемы таблиц. Классифицирована как NoSQL, использует JSON-подобные документы и схему базы данных. [2]
MySQL — свободная реляционная система управления базами данных. Разработку и поддержку MySQL осуществляет корпорация Oracle, получившая права на торговую марку вместе с поглощённой Sun Microsystems. [3]
Ниже представлена сравнительная таблица двух баз данных.
Как уже было сказано ранее, при разработке MongoDB учитывалось большое число пользователей MySQL. Для упрощения последними восприятия новой СУБД, на сайте MongoDB приводится таблица с аналогиями понятиям из MySQL:
В дальнейшем мы также будем держать в уме эти соответствия, дабы не проговаривать одно и то же в терминах двух СУБД.
Критерии сравнения
Мы будем сравнивать скорость добавления, поиска, изменения и удаления записей из одной таблицы. Предварительно можно предположить, что результаты будут сопоставимы, так как MongoDB и разрабатывалась для работы с разнородными документами без связей между ними.
Выбор структуры таблиц и обоснование
Условно структуру таблиц запишем следующим образом: Таблица 1 (text_foreignKey):
Таблица 2 (mainKey_value):
Первая таблица будет состоять из 30000 записей с одинаковым текстом и случайным внешним ключом в диапазоне от 1 до 100000. Вторая таблица будет состоять из 100000 записей, поля mainKey и value каждой строки будут равны между собой и принимать значения от 1 до 100000.
Текст в первой таблице нужен исключительно для увеличения объема записываемых данных. Атрибут mainKey второй таблицы имеет такое название, чтобы подчеркнуть, что он не является первичным ключом. Не сделали мы его первичным ключом из тех соображений, что это замедлит скорость выполнения операций в MySQL из-за дополнительной проверки целостности. Поля mainKey и value принимают одинаковые значения лишь для упрощения восприятия, концептуально это ни на что не влияет.
Следует отметить, что таблица 2 у нас больше таблицы 1. Сделали мы ее такой из нескольких соображений. Во-первых, это должно сделать поиск по mainKey немного сложнее. Во-вторых, вследствие первого факта, это позволит несколько усложнить процедуру join-а двух таблиц.
Описание тестов
Мы проведем следующие тесты:
MongoDB против MySQL: какую базу данных использовать
MySQL — это реляционная база данных, которая существует уже некоторое время. Но с учетом требований разнообразия и масштабируемости MongoDB стала популярной. Оба предлагают высокую производительность и аналогичные функции.
В этом руководстве мы рассмотрим основы MySQL и MongoDB, а затем расскажем о различиях между ними и о том, что вы должны использовать для различных случаев использования.
Что такое MongoDB?
MongoDB, разработанная в 2007 году, представляет собой популярную систему управления нереляционными базами данных (СУБД) NoSQL, в которой для хранения данных используются документы вместо таблиц или строк. Эта модель данных позволяет манипулировать связанными данными за одну операцию с базой данных.
Документы MongoDM — это документы и файлы, подобные JSON, и они поддерживают JavaScript (JS). Поля документа могут различаться, что упрощает изменение структуры с течением времени.
MongoDB считается schema-less, поскольку для нее не требуется заранее заданная схема базы данных. MongoDB использует гибкие пары ключ-значение, называемые документами, для хранения данных.
Поскольку MongoDB не содержит схемы, вам не нужно определять фиксированную структуру. Разработчикам легко использовать и изучать его, то есть его могут использовать как администраторы, так и разработчики. Он поддерживает все основные языки программирования и операционные системы, включая Mac, Linux и Windows.
MongoDB предлагает большую надежность и эффективность, позволяя удовлетворить ваши потребности в скорости и хранении. Поскольку это распределенная база данных, она отличается высокой доступностью, горизонтальным масштабированием и географическим распределением.
Основные области применения MongoDB:MongoDB широко используется для больших данных, поскольку его нереляционная структура идеально подходит для этого. Он также используется для клиентской аналитики, систем управления контентом, интеграции данных в реальном времени, управления данными о продуктах, мобильности и масштабирования.
Ограничения MongoDB
Что такое MySQL?
MySQL — это система управления реляционными базами данных (СУБД) с открытым исходным кодом, которая хранит данные в таблицах и строках. Он использует SQL (язык структурированных запросов) для передачи данных и доступа к ним. Операции JOIN упрощают запросы и корреляцию. Он следует архитектуре клиент-сервер и поддерживает многопоточность.
С момента создания базы данных MySQL у нее есть огромное сообщество, обширное тестирование и стабильность. Он доступен для всех основных платформ вместе с коннекторами для многих языков, включая C, Java, C ++, Python и PHP.
Общие варианты использования MySQL:
MySQL обычно используется для критически важных веб-сайтов с высокой посещаемостью, приложений электронной коммерции, хранилищ данных и приложений для ведения журналов.
Ограничения MySQL
Ограничения MySQL такие же, как и у любой другой СУБД, включая:
Различия между MongoDB и MySQL
В этом разделе мы рассмотрим некоторые из основных различий между MongoDB и MySQL.
Представление данных
MongoDB представляет данные как документы JSON, тогда как MySQL представляет данные в строках и таблицах.
В MongoDB это будет выглядеть следующим образом:
Встраивание данных
MySQL не предлагает никаких вариантов для вложения или встраивания данных. Вы можете использовать JOIN, но они могут привести к увеличению размера таблиц с ненужными полями. Соединения также могут быть трудоемкими и требовательными к производительности.
MongoDB позволяет вставлять связанные данные. У вас также есть возможность ссылаться на данные из другого документа, если вы чувствуете, что документ может слишком сильно увеличиться. Пример включает:
Язык запроса
MySQL использует SQL, тогда как MongoDB использует MQL, язык запросов MongoDB. В этом разделе мы сравним некоторые общие операции с базой данных в таблице Employee.
Выбор данных в MySQL
Вставка данных в MySQL
Обновление данных в MySQL
Выбор данных в MongoDB *
Вставка данных в MongoDB
Обновление данных в MongoDB
Оптимизация индекса
Обе базы данных используют индексы для оптимизации. Если MySQL не находит релевантного индекса для запроса, он ищет всю таблицу.
MongoDB просматривает каждый документ в коллекции, если нет индексов.
Развертывание базы данных
MySQL имеет двоичные файлы для большинства операционных систем, поэтому он может быть развернут изначально, MongoDB, с другой стороны, больше подходит для распределенных сред.
Скорость и производительность
Поскольку MongoDB — это база данных NoSQL, она быстрее MySQL.
Группировка данных
MongoDB хранит документы, принадлежащие одному классу или группе в коллекции. MySQL хранит строки похожих типов в таблице.
Кластеризация/репликация
MySQL поддерживает репликацию master-slave и master-master, позволяя воспроизводить данные из нескольких основных баз данных параллельно. MongoDB, с другой стороны, поддерживает встроенное сегментирование, репликацию и автоматические выборы.
Шардинг позволяет осуществлять горизонтальное масштабирование, а автоматические выборы позволяют настраивать вторичные базы данных, которые вступят во владение, если ваша первичная база данных выйдет из строя.
Безопасность
MySQL использует модель безопасности на основе привилегий, которая аутентифицирует пользователей и дает им привилегии для определенных операций с базой данных. На транспортном уровне он использует закодированные соединения между серверами и клиентами.
MongoDB использует аутентификацию на основе ролей с гибкими привилегиями. Она использует уровни транспорта и сокетов для кодирования и декодирования, обеспечивая доступ к базе данных только предполагаемым пользователям.
Масштабируемость
MySQL масштабируется по вертикали, что означает, что вы можете увеличить нагрузку на один сервер, увеличив ОЗУ или характеристики ЦП. MongoDB масштабируется по горизонтали, то есть вы можете создать кластер MongoDB с несколькими серверами, добавив больше серверов в свою базу данных.
Поддержка и документация
MySQL предлагает пожизненную поддержку на трех уровнях:
Для каждого уровня он предлагает круглосуточную техническую поддержку, а также доступ к патчам, исправлениям ошибок, выпускам обслуживания и обновлениям. Документация MySQL поддерживается корпорацией Oracle.
MongoDB предлагает поддержку корпоративного уровня. Это дает вам возможность обновлять версии в удобном для вас темпе. Документация MongoDB поддерживается MongoDB, Inc.
Когда использовать MongoDB или MySQL
MySQL — хороший выбор, если:
MySQL — хороший выбор, если вы работаете с устаревшим приложением, которое требует многострочных транзакций и имеет структурированные данные с четкой схемой.
MongoDB — хороший выбор, если:
MongoDB может быть правильным выбором, если вы работаете с аналитикой в реальном времени, мобильными приложениями, Интернетом вещей и т.д., где у вас могут быть структурированные или неструктурированные данные, которые могут быстро расти.
Что учить дальше
В этой статье мы рассмотрели основы MySQL и MongoDB, а также некоторые ключевые различия между ними. Далее вам предстоит многому научиться, вы можете начать с: против нереляционных баз данных
MySQL и MongoDB — когда и что лучше использовать
Петр Зайцев показывает разницу между MySQL и MongoDB. Это — расшифровка доклада с Highload++ 2016.
Если посмотреть такой известный DB-Engines Ranking, то можно увидеть, что в течении многих лет популярность open source баз данных растет, а коммерческих — постепенно снижается.
Что еще более интересно: если посмотреть на вот это отношение для разных типов баз данных, то видно, что для многих типов — таких, как колунарные базы данных, time series, document stories — open source базы данных наиболее популярны. Только для более старых технологий, таких как реляционные базы данных, или еще более древних, как multivalue база данных, коммерческие лицензии значительно популярнее.
Мы видим, что для многих приложений используют несколько баз данных для того, чтобы задействовать их сильные стороны. Ни одна база данных не оптимизирована для всех всевозможных юзкейсов. Даже если это PostgreSQL [смех на сцене и в зале].
С одной стороны, это хороший выбор, с другой — нужно пытаться найти баланс, так как чем у нас больше разных технологий, тем сложнее их поддерживать, особенно, если компания не очень большая.
Часто что видим, что люди приходят на такие конференции, слушают Facebook или «Яндекс» и говорят: «Ух ты! Сколько вот люди делают интересного. У них технологий разных используется штук 20, и еще штук 10 они написали сами». А потом они тот же самый подход пытаются использовать в своем стартапе из 10 человек, что работает, разумеется, не очень хорошо. Это как раз тот случай, где размер имеет значение.
Подходы к архитектуре
Очень часто мы видим, что используется основное операционное хранилище и какие-то дополнительные сервисы. Например, для кэширования или полнотекстового поиска.
Другой подход к архитектуре с использованием разных баз данных — это микросервисы, у каждого из которых может быть своя база данных, которая лучше оптимизирована для задач именно этого сервиса. Как пример: основное хранилище может быть на MySQL, Redis и Memcache — для кэширования, Elastic Search или родной Sphinx — для поиска. И что-то вроде Kafka — чтобы передавать данные в систему аналитики, которая часто делалась на чём-то вроде Hadoop.
Если мы говорим про основное операционное хранилище, наверное, у нас есть два выбора. С одной стороны, мы можем выбрать реляционные базы данных, с языком SQL. С другой стороны — что-то нереляционное, а дальше уже смотреть на подвиды, которые доступы в данном случае.
Если говорить про NoSQL-модели данных, то их тоже достаточно много. Наиболее типичные — это либо key value, либо document, либо wide column базы данных. Примеры: Memcache, MongoDB, Cassandra, соответственно.
Почему в данном случае мы сравниваем именно MySQL и MongoDB? На самом деле причин несколько. Если посмотреть на Ranking баз данных, то мы видим, что MySQL, согласно этому рейтингу, — наиболее популярная реляционная база данных, а MongoDB — наиболее популярная нереляционная база данных. Поэтому их разумно сравнивать.
А ещё у меня есть наибольший опыт в использовании этих двух баз данных. Мы в Percona занимаемся плотно именно с ними, работаем с многими клиентами, помогаем им сделать такой выбор. Еще одна причина: обе технологии изначально ориентированы на разработчиков простых приложений. Для тех людей, для которых PostgreSQL — это слишком сложно.
Компания MongoDB изначально очень активно фокусировалась на пользователях MySQL. Поэтому очень часто у людей есть опыт использования и выбор между этими двумя технологиями.
В Percona кроме того, что мы занимаемся поддержкой, консалтингом для этих технологий, у нас есть достаточно много написанного open source софта для обеих технологий. На слайде можно посмотреть. Подробно я рассказывать об этом не буду.
Что следует обо мне лично: я занимаюсь MySQL значительно больше, чем MongoDB. Несмотря на то, что я постараюсь предоставить сбалансированный обзор с моей стороны, у меня могут быть какие-то предрасположенности к MySQL, так как его тараканы я знаю лучше.
Выбор MySQL и MongoDB
Вот список разных вопросов, которые на мой взгляд имеет смысл рассматривать. Сейчас из них рассмотрим каждый более детально.
Что наиболее важно на мой взгляд — это учитывать, какие есть опыт и предпочтения команды. Для многих задач подходят оба решения. Их можно сделать и так, и так, может быть несколько сложнее, может быть несколько проще. Но если у вас команда, которая долго работала с SQL-базами данных и понимает реляционную алгебру и прочее, может быть сложно перетягивать и заставлять их использовать нереляционные базы данных, такие как MongoDB, где нет даже полноценной транзакции.
И наоборот: если есть какая-то команда, которая использует и хорошо знает MongoDB, SQL-язык может быть для неё сложен. Также имеет смысл рассматривать как оригинальную разработку, так и дальнейшее сопровождение и администрирование, поскольку всё это в итоге важно в цикле приложения.
Какие есть преимущества у данных систем?
Если говорить про MySQL — это проверенная технология. Понятно, что MySQL используется крупными компаниями более 15 лет. Так как он использует стандарт SQL, есть возможность достаточно простой миграции на другие SQL-базы данных, если захочется. Есть возможность транзакций. Поддерживаются сложные запросы, включая аналитику. И так далее.
Подход к разработке и жизненный цикл приложений
Если говорить про приложения, где используется MongoDB, и на чём они фокусируются — это очень быстрая разработка. Потому что всё можно постоянно менять, не нужно постоянно заботиться о строгом формате документа.
Второй момент — это схема данных. Здесь нужно понимать, что у данных всегда есть схема, вопрос лишь в том, где она реализуется. Вы можете реализовывать схему данных у себя в приложении, потому что каким-то же образом вы эти данные используете. Либо эта схема реализуется на уровне базы данных.
Очень часто если у вас есть какое-то приложение, с данными в базе данных работает только это приложение. Например, мы сохраняем данные из этого приложения в эту базу данных. Схема на уровне приложения работает хорошо. Если у нас одни и те же данные используются многими приложениями, то это очень неудобно, сложно контролировать.
Здесь возникает также вопрос времени жизни приложения. С MongoDB хорошо делать приложения, у которых очень ограниченный цикл жизни. То есть если мы делаем приложение, которое живёт недолго, например, сайт для запуска фильма или олимпиады. Мы пожили несколько месяцев после этого, и это приложение практически не используется. Если приложение живёт дольше, то тут уже другой вопрос.
Если говорить про распределение преимуществ и недостатков MySQL и MongoDB с точки зрения цикла разработки приложения, то их можно представить так:
Модель данных очень сильно зависит от приложения и опыта команды. Было бы странным сказать, что у нас реляционный или нереляционный подход к базам данных лучше и лучше всегда.
Если сравнивать их между собой, то понятно, что у нас есть. В MySQL — реляционная база данных. Мы можем с помощью реляционной базы данных легко отображать связи между таблицами. Нормализуя данные, мы можем заставлять изменения данных происходить атомарно в одном месте. Когда данные у нас денормализованы, нам не нужно при каких-то изменениях бежать и модифицировать кучу документов.
Хорошо это или плохо? Результат — всегда таблица. С одной стороны, это просто, с другой — некоторые структуры данных не всегда хорошо ложатся на таблицу, нам может быть неудобно с этим работать.
Это всё в теории. Если говорить о практическом использовании MySQL, мы знаем, что часто денормализуем данные, иногда для некоторых приложений мы используем что-то подобное: храним JSON, XML или другую структуру в колонках приложения.
У MongoDB структура данных основана на документах. Данные многих веб-приложений отображать очень просто. Потому что если храним структуру — что-то вроде ассоциированного массива приложения, то это очень просто и понятно для разработчика сериализуется в JSON-документ. Раскладывать такое в реляционной базе данных по разным табличкам — задача более нетривиальная.
Результаты как список документов, у которых может быть совершенно разная структура — более гибкое решение.
Следует сказать, что это всё в строго реляционной теории — некоторые базы данных поддерживают массивы. В MySQL поддерживается формат JSON, в который можно засунуть такие вещи, как несколько email-адресов. Или многие годы люди серилизовали это ручками: надо нам сохранить несколько email-адресов, то давайте запишем их через запятую, и дальше приложение разберётся. Но как-то это не очень кошерно.
Термины
Интересно, что между MySQL и MongoDB — вообще, между реляционными и нереляционными СУБД — что-то совпадает, что-то различается. Например, в обоих случаях мы говорим о базах данных, но то, что мы называем таблицей в реляционной базе данных, часто в нереляционной называется коллекцией. То, что в MySQL — колонка, в MongoDB — поле. И так далее.
Что касается доступа: там, где мы к реляционным данным используем язык SQL, в MongoDB и многих других NoSQL-базах данных используется такой стандарт, как CRUD. Этот стандарт говорит, что есть операции для создания, чтения, удаления и обновления документов.
Как у нас могут выглядеть наиболее типичные задачи по работе с документами в MySQL и MongoDB:
Вот пример вставки.
Если вы разработчик, который знаком с языком JavaScript, то такой синтаксис, который предоставляет CRUD (MongoDB), для вас будет более естественным, чем синтаксис SQL.
На мой взгляд, когда у нас есть простейшие операции: поиск, вставка, они все работают достаточно хорошо. Когда речь идёт о более интересных операциях выборки, на мой взгляд, язык SQL куда более читаемый.
> вместо простого знака «>». Не очень читаемо, на мой взгляд.
Достаточно легко с помощью интерфейса делать такие вещи, как подсчёт числа строк в таблице или коллекции.
Следующий момент — это транзакции и консистентность (ACID). Если пойти и почитать документацию MongoDB, там будет: «Мы поддерживаем ACID-транзакции, но с ограничением». На мой взгляд, стоит сказать: «ACID мы не поддерживаем, но поддерживаем другие минимальные нетранзакционные гарантии».
Какая у нас между ними разница?
Мы можем сконфигурировать у InnoDB, как работать с лог-файлом: сохранять его на диск при коммите транзакции или же делать это периодически. Мы можем сконфигурировать репликацию, включить, например, Semisynchronous Replication, когда у нас данные будут считаться сохранёнными только тогда, когда их копия будет принята на одном из slave’ов.
MongoDB не поддерживает транзакции, но он поддерживает атомарные операции над документом. Это значит, что с точки зрения одного документа операция у нас будет атомарна. Если у нас операция изменяет несколько документов, и во время этой операции произойдет какой-то сбой внутри, то какие-то из этих документов могут быть изменены, а какие-то — не изменены.
Консистентность тоже делается на уровне документов. В кластере мы можем выбирать гибкую консистентность. Мы можем указать, какие мы хотим гарантии — гарантии, что у нас данные были записаны только на один узел, или они были реплицированы на все узлы кластеров. Чтение консистентности тоже происходит на уровне документа.
Есть такой вариант обновления isolated, который позволяет выполнить обновление изолированно от других транзакций, но он очень неэффективен — он переключает базы данных в монопольный режим доступа, поэтому он используется достаточно редко. На мой взгляд, если говорить про транзакции и консистентность, то MongoDB достаточна убогая.
Производительность
Производительность очень сложно сравнивать напрямую, потому что мы часто делаем разные схемы баз данных, дизайн приложения. Но если говорить в целом, MongoDB изначально была сделана, чтобы хорошо масштабироваться на много узлов через шардинг, поэтому эффективности было уделено меньше внимания.
Это результаты бенчмарка, который делал Марк Каллаган. Здесь видно, что с точки зрения использования процессора, ввода/вывода MySQL — как InnoDB, так и MyRocks — использует значительно меньше процессора и дискового ввода/вывода на операции бенчмарка Linkbench от Facebook.
Что такое масштабируемость в данном контексте? То, насколько легко нам взять наше маленькое приложение и масштабировать его на многие миллионы, может быть, даже на миллиарды пользователей.
Масштабируемость бывает разная. Она бывает средняя, в рамках одной машины, когда мы хотим поддерживать приложения среднего размера, либо масштабируемость на кластере, когда у нас приложения уже очень большие, когда понятно, что даже одна самая мощная машина не справится.
Также имеет смысл говорить о том, масштабируем ли мы чтение, запись или объем данных. В разных приложениях их приоритеты могут различаться, но в целом, если приложение очень большое, обычно им приходится работать со всеми из этих вещей.
В MySQL в новых версиях весьма хорошая масштабируемость в рамках одного узла для LTP-нагрузок. Если у нас маленькие транзакции, есть какое-нибудь железо, в котором 64 процессора, то масштабируется достаточно хорошо. Аналитика или сложные запросы масштабируются плохо, потому что MySQL может использовать для одного запроса только один поток, что плохо.
Традиционно чтение в MySQL масштабируется с репликацией, запись и размер данных — через шардинг. Если смотреть на все большие компании — Facebook, Twitter — они все используют шардинг. Традиционно шардинг в MySQL используется вручную. Есть некоторые фреймворки для этого. Например, Vitess — это фреймворк, который Google использует для scaling сервиса YouTube, они его выпустили в open source. До этого был framework Jetpants. Стандартного решения для шардинга MySQL не предлагает, часто переход на шардинг требует внимания от разработчиков.
В MongoDB фокус изначально был в масштабируемости на многих узлах. Даже в случаях с маленьким приложением многим рекомендуется использовать шардинг с самого начала. Может, всего пару replica set, потом вы будете расти вместе со своим приложением.
В шардинге MongoDB есть некоторые ограничения: не все операторы с ним работают, например, есть isolated-вариант для обеспечения консистентности. Она не работает если использовать шардинг. Но при этом многие основные операции хорошо работают в шардингом, поэтому людям позволяется scale’ить приложения значительно лучше. На мой взгляд, шардинг и вообще репликация в MongoDB сделаны куда лучше, чем MySQL, значительно проще в использовании для пользователя.
Администрирование
Администрирование – это все те вещи, о которых не думают разработчики. По крайней мере в первую очередь. Администрирование — это то, что нам приложение придётся бэкапить, обновлять версии, мониторить, восстановливать при сбоях и так далее.
MySQL достаточно гибок, у него есть много разных подходов. Есть хорошие open source реализации всего, но это множество вариантов порождает сложность. Я часто общаюсь с пользователями, которые только начинают изучать MySQL. Они говорят: «Ёлки-палки, сколько же у вас всего вариантов. Вот только репликация — какую мне использовать: statement-репликацию, raw-репликацию, или mix? А еще есть gtid и стандартная репликация. Почему нельзя сказать „просто работай“?»
В MongoDB всё больше ориентированно на то, что оно работает каким-то одним стандартным образом — есть минимизация администрирования. Но понятно, что это происходит при потере гибкости. Коммьюнити open source решений для MongoDB значительно меньше. Многие вещи в MongoDB с точки зрения рекомендаций достаточно жестко привязаны к Ops Manager — коммерческой разработке MongoDB.
Как в MongoDB, так и в MySQL есть мифы, которые были в прошлом, которые были исправлены, но у людей хорошая память, особенно если что-то не работает. Помню, в MySQL после того как появились транзакции с InnoDB, люди мне лет десять говорили: «А в MySQL нет же транзакций?»
В MongoDB было много разных проблем с производительностью MMAP storage engine: гигантские блокировки, неэффективное использование дискового пространства. Сейчас в стандартном движке WiredTiger уже нет многих из этих проблем. Есть другие проблемы, но не эти.
«Нет контроля схемы» — ещё такой миф. В новых версиях MongoDB можно для каждой коллекции определить на JSON структуру, где данные будут валидироваться. Данные, которые мы пытаемся вставить, и они не соответствуют какому-то формату, можно выкидывать.
«Нет аналога JOIN » — то же самое. В MongoDB это появилось, но нескольких ограниченных вещах. Только на уровне одного шарда и только если мы используем Aggregation Framework, а не в стандартных запросах.
Какие у нас есть мифы в MySQL? Здесь я буду говорить больше о поддержке NoMySQL решений в MySQL, об этом я буду говорить завтра. Следует сказать, что MySQL сейчас тоже можно использовать через интерфейс CRUD’a, использовать в NoSQL режиме примерно как MongoDB.
Типичный пример, где используется MySQL-решение — это сайт электронной коммерции. Когда у нас идёт вопрос о деньгах, часто мы хотим полноценные транзакции и консистентность. Для таких вещей хорошо подходит реляционная структура, которая была проработана, и commerce на реляционных базах данных уже делается многие десятилетия. Так что можно взять один из готовых подходов к структуре данных и использовать его.
Обычно с точки зрения e-commerce объем данных у нас не такой большой, так что даже достаточно большие магазины могут долго работать без шардинга. Приложения у нас постоянно разрабатываются и усовершенствуется на протяжении многих лет. И у этого приложения много компонент, которые работают с одними и теми же данными: кто-то рассчитывает, где цены поменять, кто-то ещё что-то делает.
MongoDB часто задействуется как бэкенд больших онлайн-игр. Electronic Arts для очень многих игр использует MongoDB. Почему? Потому что масштабируемость важна. Если какая-то игра хорошо выстрелит, её приходится масштабировать значительно больше, чем предполагалось.
С другой стороны, если не выстрелит, нам хотелось бы, чтобы инфраструктуру можно было бы уменьшить. Во многих играх это идет так: мы запустили игру, у нее есть какой-то пик, приходится делать большой кластер. Потом игра уже выходит из популярности, для неё бэкенд нужно сжимать, сохранять и использовать. В данном случае есть одно приложение (игра), база данных, с одной стороны, несложная, с другой — сильно привязанная к приложению, в котором хранятся все важные для игры параметры.
Часто консистентность базы данных на уровне объектов здесь достаточна, потому что многие вопросы консистентости решаются на уровне приложения. Например, данные одного игрока сохраняет только один application service.