MySQL vs MongoDBЧто лучше использовать в каких случаях

Петр Зайцев

CEO, Percona

7 November 2016

2

MySQL vs MongoDB

VS

3

Реальный Выбор

Какие из открытых баз данных имеет смысл использовать для проекта

4

Открытые Базы Данных ?

Многие лидирующие компании и другие организации выбирают Открытые технологии в первую очередь

Не требуется лицензия – легко экспериментировать

Вопросы адекватное поддержки встают позже при запуске приложения

5

Тренд популярности открытых баз данных

6

Открытые БД доминируют в новых подходах

7

Несколько баз данных. Несколько подходов

Выбирается Несколько «Баз Данных» чтобы

использовать их сильные стороны

Найти баланс так как много технологий

сложно поддерживать

8

Подходы к Архитектуре

Основное Операционное Хранилище данных + дополнительные сервисы

Микросервисы с разными Основными Хранилищами

9

Пример

Основное Хранилище на MySQL

Redis/Memcache для кэширования

Elastic Search/Sphinx для поиска

Kafka для передачи данных в систему аналитики

10

Выбор для Основного Хранилища Данных

Реляционное (SQL) Не Реляционное (NoSQL)

11

NoSQL – Модели данных

Key Value

•Memcache

Document

•MongoDB

Wide Column

•Cassandra

12

Почему MySQL vs MongoDB

13

Почему MySQL vs MongoDB

В Percona мы наиболее плотно занимаемся этими технологиями

Обе технологии изначально ориентированы на разработчиков простых приложений

MongoDB изначально фокусировалась на пользователях MySQL

14

MySQL & MongoDB в Percona

MySQL•Percona Server for MySQL•Percona XtraDB Cluster•Percona Toolkit•Percona Xtrabackup•Percona Monitoring and Management•RocksDB Storage Engine (MyRocks в разработке)•TokuDB Storage Engine

MongoDB•Percona Server for MongoDB•MongoDB Consistent Backup (built in)•Percona Toolkit for MongoDB (в разработке)•Percona Monitoring and Management•RocksDB Storage Engine (MongoRocks)•Percona Memory Storage Engine

15

Для полной прозрачности

Я знаю MySQL куда лучше чем MongoDB и

лучше знаю как работать с его недостатками

16

Выбор MySQL vs MongoDB

Опыт и предпочтения команды

Подход к разработке и цикл жизни приложения

Модель Данных

Транзакции и Консистентность (ACID)

Производительность

Масштабируемость

Администрирование

17

Опыт и предпочтение Команды

Ключевой вопрос!

Многие задачи можно решить разными способами

Оригинальная разработка и сопровождение

18

Опыт и Предпочтения Команды

MySQL•Проверенные технологии•SQL стандарт •Возможность миграции на другие SQL базы данных•Транзакции •Возможности тонкой настройки•Сложные запросы через SQL

MongoDB•Гибкий JSON формат документов•Не нужно учить сложный SQL•Простые запросы реже создают проблемы •Можно динамически менять схему документа•Встроенная Масштабируемость•Сложные запросы на стороне приложения

19

Подход к Разработке и Жизненный Цикл Приложений

Быстрая Разработка или Больший Контроль

У данных всегда есть схема

Если с данными работает одно приложение то схему можно держать в приложении если нет то в базе

Время Жизни приложений

Время Активной Разработки приложений

20

Разработка MySQL vs MongoDB

MySQL

• Реляционная структура требует большего планирования и контроля

• Данные легко использовать из разных приложений

• Много приложений 15+ лет • Гибкость

MongoDB

• Скорость разработки• Не нужно синхронизировать

схему в базе данных и приложении

• Понятный путь к масштабируемости

• Простые предписанные решения

21

Модель данных

Оптимальная модель зависит от приложения и опыта команды

22

Модель Данных MySQL vs MongoDB

MySQL•Реляционная модель данных•Легко отображать связи между данными•Изменение данных в одном месте•Результат всегда таблица

MongoDB•Модель данных основанная на документах•Просто отображать данные веб приложений•Не требуется сложных JOIN•Результат список документов (разной структуры)

23

Модель Данных Пример – Контакт Лист

Реляционная База Данных

• Имя, Фамилия, Дата рождения • У человека может быть

несколько телефонов и адресов • Надо создать для них отдельные

таблицы• Массивы JSON –

нетрадиционные расширения

Документориентированная база данных

• Хранится все в одной «коллекции»

• Массивы, вложенные документы

24

Термины

MySQL•База Данных•Таблица•Строка•Колонка•Индекс•Первичный Ключ•JOIN•Ограничения (Check Constraints)

MongoDB•База Данных•Коллекция•Документ•Поле•Индекс•Первичный Ключ•Сcылка или Встроенный Документ•Правила Валидации

25

CRUD

CREATE – Создавать документ

READ – Читать документ

UPDATE – Изменять документ

DELETE – Удалять документ

26

SQL vs CRUD - Insert

• SQL • CRUD

27

SQL vs CRUD Update

28

SQL vs CRUD - Delete

29

SQL vs CRUD - Search

30

SQL vs CRUD - Count

31

SQL vs CRUD - Aggregation

32

Транзакции и Консистентность (ACID)

Какие операции могут быть атомарными (A)

Гарантируют ли операции консистентое состояние базы данных (C)

Как разные операции изолируются друг от друга (I)

Насколько надежно сохраняются результаты операции (D)

33

Транзакции и Консистентность

MySQL

• Поддерживает транзакции произвольного размера

• Атомарность в смысле транзакций• Консистентность на уровне транзакций

для одного узла.• Выбор уровней изоляции READ

UNCOMMITTED … SERIALIZABLE • Конфигурируется на уровне узла (для

одиночного узла и репликации)

MongoDB

• Не поддерживает транзакции но атомарные операции над документом

• Консистентность на уровне документов. Гибкая консистентность в кластере

• На уроне документов. Чтение нескольких документов «Изолировано» от обновлений

• Можно управлять сохранением данных для одного узла и репликации на уровне операций

34

Производительность

Производительность очень сложно сравнивать напрямую

Зависит от дизайна приложения в первую очередь

Так как MongoDB хорошо масштабируется меньше внимания уделяется эффективности

35

Производительность MySQL vs MongoDB

Mark Callaghan: http://bit.ly/2epDJqD

36

Масштабируемость

Насколько легко сделать из маленького приложения большое

Масштабируемость в рамках одной машины и многих машин

Масштабируемость в рамках чтения, записи, объема данных

37

Масштабируемость MySQL vs MongoDB

MySQL

• Хорошая масштабируемость в рамках одного узла

• Легко масштабировать «средние» приложения

• Масштабирование чтения репликацией• Масштабирование записи и размера

данных через Шардинг• Шардинг выполняется в ручную и часто

требует привлечения разработчиков

MongoDB

• Изначальный фокус на масштабируемости на многих узлах

• Обычно используется шардинг изначально

• Встроенный и простой шардинг• Шардинг - основной способ

масштабируемости

38

Администрирование

О чем НЕ думают разработчики

По крайней мере не в первую очередь

Автоматизация деплоймента

Резервное копирование

Обновление Версий

Мониторинг

Восстановление при сбоях

Анализ производительности

39

Администрирование MySQL vs MongoDB

MySQL

• Гибкость• Много разных подходов и решений • Есть Open Source реализации для

всего• Много вариантов порождает

сложность

MongoDB

• Минимизация администрирования • Автоматическое восстановление

при сбоях• Идея – дать один стандартный

подход • Мало хороших Open Source

решений• Сильная привязка к MongoDB Ops

Manager в подходах

40

Это было в прошлом

MySQL

• Поддержка только реляционной структуры

• Поддержка только языка SQL для интерфейса

MongoDB

• Большие проблемы с производительностью записи в MMAP

• Неэффективное использование дискового простанства MMAP

• Нет контроля схемы • Нет аналога “JOIN”

41

Типичный пример: MySQL

• Важны полноценные транзакции• Реляционная модель хорошо подходит • Полезно обновление данных в одном месте • Не очень большой объем данных и операций – не

нужен шардинг• Постоянная разработка приложения в течение многих

лет• Многие приложения используют и изменяют одни и

те же данные

Сайт Электронно

й Коммерции

42

Типичный пример: MongoDB

• Масштабируемость очень важна, если игра «выстрелит»

• Единственное приложение использует данные • Схема данных сложная и не хорошо ложится на

реляционную• Консистентность данны на уровне объектов

достаточна • Не очень активная разработка после запуска игры

Бэкенд большо

й онлайн

игры

43

Дополнительная Информация

• http://www.mongodb-is-web-scale.com/

44

Percona Live: Call for Papers Deadline - November 13

Percona Live Santa Clara to take place April 24-27 in Santa Clara, CA.

Submission Guidelines:http://bit.ly/2exss8u

Submission Form: http://bit.ly/2e01oT2

45

Thank You!