Привет, Хабр! На прошлой неделе прошла конференция Percona Live Data Performance Conference 2016. Как обычно, тонны новой информации, и я всё ещё разбираю свои заметки и пролистываю слайды докладов, на которые попасть не удалось. Сообщество MySQL довольно открыто к представителям «параллельных» сообществ и проектов. Естественно были доклады об Oracle MySQL, MariaDB и Percona Server, но были также доклады и о MongoDB, Redis, Tarantool, Hadoop, Cassandra, Scylla, Ignite, HBase, ActorDB, SQLite, ToroDB, Tempesta DB и даже доклад об оптимизации PostgreSQL, несколько обобщённый для MySQL и других СУБД.

Сотрудники Oracle делились планами о MySQL 8 неожиданно щедро как в докладах, так и в кулуарах. Мне эта информация показалась достаточно интересной, поэтому я решил составить краткую сводку из услышанного.

Да, со следующей версии MySQL изменяется схема нумерации релизов. Следующий основной релиз будет называться MySQL 8, и все последующие основные релизы будут нумероваться 9, 10 и т.д. Это сделано во-первых потому, что MySQL будет объединён с MySQL Cluster (который в данным момент имеет номер релиза 7.5), а во-вторых для упрощения нумерации, чтобы основные релизы (5.5, 5.6, 5.7) не выглядяли как корректирующие.

Rapid plugins

По словам команды разработчиков MySQL пользователи хотят более гибкий цикл разработки, чтобы новую функциональность не нужно было ждать до следующего основного релиза. Многие пользователи готовы протестировать новую функциональность, даже если она сыровата, но чтобы при возникновении проблем её можно было бы отключить.

Предлагаемое решение этой задачи называется труднопереводимым термином rapid plugins. Суть в том, что в тех случаях, когда это возможно, новая функциональность будет выпускаться в виде подключаемых модулей. Версии модулей будут совпадать с версией сервера, и как я понял, никакой совместимости этих модулей между разными версиями сервера не обещают. Т.е. это сделано исключительно для того, чтобы изолировать новые функции от старых, и их можно было подключать/отключать по желанию.

Собственно говоря, эта новая возможность уже обкатывается на текущем стабильном релизе 5.7. В MySQL 5.7.12 появился новый модуль со слегка мистическим названием X Plugin и очень странно, что на Хабре до сих пор не появилось статьи на эту тему, потому что предоставляемая им функциональность впечатляет: новый протокол общения с сервером с возможностью асинхронного выполнения запросов, новый NoSQL API с упором на CRUD, JSON и document store с биндингами для Python, JavaScript, Node.js, .Net и Java, а также новая командная утилита для работы с сервером.

Однако всю эту функциональность следует рассматривать скорее как прототип для тестирования. Разработчики сообщают, что для первого релиза производительность и завершённость не были приоритетами и работа будет продолжена в будущих релизах.

X protocol/DevAPI/Shell

Для MySQL 8 у разработчиков обширные планы на новый протокол и API:

• производительность
• расширение API и привязок к другим языкам
• использование X протокола для репликации и шардинга (потоковый протокол + более строгая структурированность запросов сильно упрощают эти задачи)
• объединение всех административных утилит и фронтендов к серверу в MySQL Shell

Оптимизатор запросов

Оптимизатор запросов в MySQL 8 получит, пожалуй, самые значительные изменения на моей памяти:

• кэширование плана выполнения для prepares statements
• гистограммы
• оконные функции (window functions)
• common table expressions (в том числе, рекурсивные)

Как я понял, этот список не окончательный, рассматриваются также другие «продвинутые» возможности SQL, а также улучшения в JSON функциональности и индексах.

Кстати, пользователи MariaDB могут пользоваться гистограммами начиная с версии 10.0, а оконные функции и CTE (правда нерекурсивные) запланированы на MariaDB 10.2, который, скорее всего, выйдет раньше MySQL 8.

Group replication

Аналог Galera Cluster в исполнении Oracle называется Group Replication. Предварительные релизы уже были доступны в виде плагина. Как я понял, стабильный релиз планируется к появлению MySQL 8. Каких-то подробностей о запланированных возможностях разработчики не сообщали, кроме того, что будет ещё быстрее, удобнее и устойчивее, чем предварительные релизы.

Пока, MyISAM!

Наконец-то все системные таблицы будут переведены на InnoDB. MyISAM таким образом становится абсолютно ненужной с точки зрения сервера, но будет доступна в качестве опция для тех, кто любит кактусы.

Словарь данных и атомарные DDL

Один из самых частоупоминаемых недостатков MySQL — это отсутствие транзакционного словаря данных. Как я уже писал у этого недостатка есть много достаточно неприятных последствий: отсутствие транзакционных DDL, дорогостоящие запросы к INFORMATION_SCHEMA, проблемы с расширяемостью формата метаданных, проблемы с физическими бэкапами и блокировками таблиц.

В MySQL 8 по крайней мере часть этих проблем будет устранена. .frm файлов больше не будет, метаданные таблиц будут хранится только в общем словаре данных (а не .frm и отдельно в InnoDB, как это сейчас). То есть, проблемы с медленным доступом через INFORMATION_SCHEMA и рассинхронизацией метаданных в случае сбоев уходят в прошлое. Движки хранения получат возможность хранить расширенные атрибуты для своих таблиц, что открывает возможности для некоторых интересных возможностей в будущем.

И что самое главное, DDL станут хоть и не транзакционными, но атомарными. То есть возможности завернуть DDL в транзакцию и откатить в MySQL 8 ещё не будет. Но частично выполненных DDL в случае падения сервера или проблем с репликацией мы больше не увидим.

И ещё…

Наверняка это неполный список планируемой функциональности, и к релизу он расширится. Помимо прочего планируется очередной пересмотр значений по умолчанию для конфигурационных параметров. В частности, UTF-8 станет кодировкой по умолчанию вместо latin1.

Разработчики также туманно намекают на улучшенную поддержку облачных платформ и новый движок хранения на основе Log Structured Merge деревьев. В любом случае, MySQL 8 уже выглядит интересным.

ссылка на оригинал статьи https://habrahabr.ru/post/282337/