Сегодня много дискуссий о том, что лучше - MySQL или PostgreSQL? Однако перед тем, как выбирать именно реляционную базу данных для своего проекта, стоит понять, является ли реляционная база данных наилучшим решением для него. В рамках этого доклада мы сравним наиболее популярную реляционную базу данных с открытым кодом с наиболее популярным хранилищем документов с открытым кодом. Мы определим, в каких случаях эффективнее всего работает MySQL, а в каких - MongoDB. Мы также рассмотрим ситуации, в которых ни одна из этих баз данных не будет лучшим решением и в которых целесообразно остановить свой выбор на других технологиях.

1. MySQL vs MongoDB
Что лучше использовать в каких случаях
Петр Зайцев
CEO, Percona
7 November 2016

2. 2
MySQL vs MongoDB
VS

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

4. 4
Открытые Базы Данных ?
Многие лидирующие компании и другие организации
выбирают Открытые технологии в первую очередь
Не требуется лицензия – легко экспериментировать
Вопросы адекватное поддержки встают позже при
запуске приложения

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

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

7. 7
Несколько баз данных. Несколько подходов
Выбирается Несколько
«Баз Данных» чтобы
использовать их
сильные стороны
Найти баланс так как
много технологий
сложно поддерживать

8. 8
Подходы к Архитектуре
Основное Операционное Хранилище
данных + дополнительные сервисы
Микросервисы с разными
Основными Хранилищами

9. 9
Пример
Основное Хранилище на MySQL
Redis/Memcache для кэширования
Elastic Search/Sphinx для поиска
Kafka для передачи данных в систему аналитики

10. 10
Выбор для Основного Хранилища Данных
Реляционное
(SQL)
Не
Реляционное
(NoSQL)

11. 11
NoSQL – Модели данных
Key Value
•Memcache
Document
•MongoDB
Wide Column
•Cassandra

12. 12
Почему MySQL vs MongoDB

13. 13
Почему MySQL vs MongoDB
В Percona мы наиболее плотно занимаемся этими
технологиями
Обе технологии изначально ориентированы на
разработчиков простых приложений
MongoDB изначально фокусировалась на пользователях
MySQL

14. 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. 15
Для полной прозрачности
Я знаю MySQL куда
лучше чем MongoDB и
лучше знаю как работать
с его недостатками

16. 16
Выбор MySQL vs MongoDB
Опыт и предпочтения команды
Подход к разработке и цикл жизни приложения
Модель Данных
Транзакции и Консистентность (ACID)
Производительность
Масштабируемость
Администрирование

17. 17
Опыт и предпочтение Команды
Ключевой вопрос!
Многие задачи можно решить разными способами
Оригинальная разработка и сопровождение

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

19. 19
Подход к Разработке и Жизненный Цикл Приложений
Быстрая Разработка или Больший Контроль
У данных всегда есть схема
Если с данными работает одно приложение то схему можно держать в приложении если нет то в
базе
Время Жизни приложений
Время Активной Разработки приложений

20. 20
Разработка MySQL vs MongoDB
MySQL
• Реляционная структура требует
большего планирования и
контроля
• Данные легко использовать из
разных приложений
• Много приложений 15+ лет
• Гибкость
MongoDB
• Скорость разработки
• Не нужно синхронизировать
схему в базе данных и
приложении
• Понятный путь к
масштабируемости
• Простые предписанные
решения

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

22. 22
Модель Данных MySQL vs MongoDB
MySQL
• Реляционная модель данных
• Легко отображать связи
между данными
• Изменение данных в одном
месте
• Результат всегда таблица
MongoDB
• Модель данных основанная
на документах
• Просто отображать данные
веб приложений
• Не требуется сложных JOIN
• Результат список документов
(разной структуры)

23. 23
Модель Данных Пример – Контакт Лист
Реляционная База Данных
• Имя, Фамилия, Дата рождения
• У человека может быть
несколько телефонов и адресов
• Надо создать для них отдельные
таблицы
• Массивы JSON –
нетрадиционные расширения
Документориентированная база
данных
• Хранится все в одной
«коллекции»
• Массивы, вложенные
документы

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

25. 25
CRUD
CREATE – Создавать документ
READ – Читать документ
UPDATE – Изменять документ
DELETE – Удалять документ

26. 26
SQL vs CRUD - Insert
• SQL • CRUD

27. 27
SQL vs CRUD Update

28. 28
SQL vs CRUD - Delete

29. 29
SQL vs CRUD - Search

30. 30
SQL vs CRUD - Count

31. 31
SQL vs CRUD - Aggregation

32. 32
Транзакции и Консистентность (ACID)
Какие операции могут быть атомарными (A)
Гарантируют ли операции консистентое состояние базы данных (C)
Как разные операции изолируются друг от друга (I)
Насколько надежно сохраняются результаты операции (D)

33. 33
Транзакции и Консистентность
MySQL
• Поддерживает транзакции
произвольного размера
• Атомарность в смысле транзакций
• Консистентность на уровне транзакций
для одного узла.
• Выбор уровней изоляции READ
UNCOMMITTED … SERIALIZABLE
• Конфигурируется на уровне узла (для
одиночного узла и репликации)
MongoDB
• Не поддерживает транзакции но
атомарные операции над документом
• Консистентность на уровне документов.
Гибкая консистентность в кластере
• На уроне документов. Чтение
нескольких документов «Изолировано»
от обновлений
• Можно управлять сохранением данных
для одного узла и репликации на уровне
операций

34. 34
Производительность
Производительность очень сложно сравнивать
напрямую
Зависит от дизайна приложения в первую очередь
Так как MongoDB хорошо масштабируется меньше
внимания уделяется эффективности

35. 35
Производительность MySQL vs MongoDB
Mark Callaghan: http://bit.ly/2epDJqD

36. 36
Масштабируемость
Насколько легко сделать из маленького приложения
большое
Масштабируемость в рамках одной машины и многих
машин
Масштабируемость в рамках чтения, записи, объема
данных

37. 37
Масштабируемость MySQL vs MongoDB
MySQL
• Хорошая масштабируемость в рамках
одного узла
• Легко масштабировать «средние»
приложения
• Масштабирование чтения репликацией
• Масштабирование записи и размера
данных через Шардинг
• Шардинг выполняется в ручную и часто
требует привлечения разработчиков
MongoDB
• Изначальный фокус на
масштабируемости на многих узлах
• Обычно используется шардинг
изначально
• Встроенный и простой шардинг
• Шардинг - основной способ
масштабируемости

38. 38
Администрирование
О чем НЕ думают разработчики
По крайней мере не в первую очередь
Автоматизация деплоймента
Резервное копирование
Обновление Версий
Мониторинг
Восстановление при сбоях
Анализ производительности

39. 39
Администрирование MySQL vs MongoDB
MySQL
• Гибкость
• Много разных подходов и решений
• Есть Open Source реализации для
всего
• Много вариантов порождает
сложность
MongoDB
• Минимизация администрирования
• Автоматическое восстановление
при сбоях
• Идея – дать один стандартный
подход
• Мало хороших Open Source
решений
• Сильная привязка к MongoDB Ops
Manager в подходах

40. 40
Это было в прошлом
MySQL
• Поддержка только
реляционной структуры
• Поддержка только языка SQL
для интерфейса
MongoDB
• Большие проблемы с
производительностью записи в
MMAP
• Неэффективное использование
дискового простанства MMAP
• Нет контроля схемы
• Нет аналога “JOIN”

41. 41
Типичный пример: MySQL
• Важны полноценные транзакции
• Реляционная модель хорошо подходит
• Полезно обновление данных в одном месте
• Не очень большой объем данных и операций – не
нужен шардинг
• Постоянная разработка приложения в течение многих
лет
• Многие приложения используют и изменяют одни и
те же данные
Сайт
Электронной
Коммерции

42. 42
Типичный пример: MongoDB
• Масштабируемость очень важна, если игра
«выстрелит»
• Единственное приложение использует данные
• Схема данных сложная и не хорошо ложится на
реляционную
• Консистентность данны на уровне объектов
достаточна
• Не очень активная разработка после запуска игры
Бэкенд
большой
онлайн
игры

43. 43
Дополнительная Информация
• http://www.mongodb-is-web-scale.com/

44. 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. 45

46. Thank You!