MySQL® и MongoDB® - когда что лучше использовать? / Петр Зайцев (Percona)
Download as PPTX, PDF2 likes5,415 views
Документ обсуждает сравнительные аспекты использования MySQL и MongoDB, подчеркивая, что выбор между ними зависит от законодательства команды, подхода к разработке и требований к данным. Он выделяет сильные и слабые стороны обеих технологий, включая производительность, масштабируемость и структуру данных. Кроме того, документ предлагает рекомендации по выбору подходящей базы данных в зависимости от конкретных сценариев использования.
MySQL® и MongoDB® - когда что лучше использовать? / Петр Зайцев (Percona)
- 1. MySQL vs MongoDB Что лучше использовать в каких случаях Петр Зайцев CEO, Percona 7 November 2016
- 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 • Масштабируемость очень важна, если игра «выстрелит» • Единственное приложение использует данные • Схема данных сложная и не хорошо ложится на реляционную • Консистентность данны на уровне объектов достаточна • Не очень активная разработка после запуска игры Бэкенд большой онлайн игры
- 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!