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

Петр ЗайцевCEO, Percona

7 November 2016

2

MySQL vs MongoDB

VS

3

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

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

проекта

4

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

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

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

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

5

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

6

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

7

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

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

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

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

8

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

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

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

9

Пример

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

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

ElasticSearch/Sphinxдляпоиска

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

10

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

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

НеРеляционное

(NoSQL)

11

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

KeyValue

•Memcache

Document

•MongoDB

WideColumn

•Cassandra

12

Почему MySQL vs MongoDB

13

Почему MySQL vs MongoDB

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

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

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

14

MySQL & MongoDB в Percona

MySQL

• PerconaServerforMySQL• PerconaXtraDBCluster• PerconaToolkit• PerconaXtrabackup• PerconaMonitoringandManagement

• RocksDBStorageEngine(MyRocksвразработке)

• TokuDBStorageEngine

MongoDB

• PerconaServerforMongoDB• MongoDBConsistentBackup(builtin)• PerconaToolkitforMongoDB(вразработке)

• PerconaMonitoringandManagement

• RocksDBStorageEngine(MongoRocks)

• PerconaMemoryStorageEngine

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• Ограничения(CheckConstraints)

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

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

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

• ВыборуровнейизоляцииREADUNCOMMITTED…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

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

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

MongoDB

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

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

• МалохорошихOpenSourceрешений

• Сильнаяпривязкак MongoDBOpsManagerвподходах

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

PerconaLiveSantaClaratotakeplaceApril24-27inSantaClara,CA.

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

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

45

Thank You!