А вот и «Механизм аналитики MySQL»

2 декабря Oracle официально запустила «Службу базы данных MySQL с Analytics Engine» на своем официальном сайте. Эта функция примечательна как значительное улучшение продукта MySQL. Я нашел время, чтобы сделать простое понимание на выходных, и вы можете получить представление об этом. (Часть информации и иллюстраций взята с официального сайта Oracle).

1. Естественный недостаток MySQL «анализ данных»

Жизнь в основном состоит из двух вещей: выбора темы и решения проблемы. Лучшая жизнь — это правильно выбирать вопросы и хорошо их решать в каждом ключевом моменте. Самая большая боль в жизни — это решить правильный вопрос, но выбрать неправильный вопрос, и вы не знаете, что выбрали неправильный вопрос. Так же, как самое большое сожаление в жизни — это не то, что ты не можешь, а то, что ты мог.

MySQL, как самая популярная база данных с открытым исходным кодом, получила широкое распространение. Как видно из последнего индекса db-engines, он занимает важное место в сфере баз данных.

Но у такого популярного продукта базы данных есть один очевидный недостаток — анализ данных. Я полагаю, что у пользователей MySQL есть такое ощущение, что MySQL несколько бессилен в случае крупномасштабных данных. Хотя его ядро постоянно расширяет свои возможности в этом отношении (например, последняя версия 8.0 поддерживает хэш-соединение, гистограмму и т. д.), оно все же имеет определенные недостатки по сравнению с другими базами данных. Суть в том, что MySQL изначально разработан для сценариев OLTP и не рассматривает сценарии OLAP. Хотя некоторые производители расширили свои возможности анализа данных, расширив механизмы хранения, в целом они неудовлетворительны. Поэтому одним из обычных вариантов является перенос данных в другую базу данных или архитектуру больших данных для анализа данных. Через последний, чтобы завершить работу по анализу данных. В этом процессе разработчикам необходимо определить свою собственную логику ETL (которая может быть основана на анализе журнала или логическом извлечении данных) для завершения переноса данных. В то же время необходимо постоянно обращать внимание на синхронизацию данных во время работы, чтобы обеспечить достоверность данных. При использовании необходимо написать отдельный оператор (оператор разнородных источников данных) для выполнения действия по анализу данных. Весь процесс, несомненно, имеет определенный порог для использования пользователями, и для решения этой проблемы требуются дополнительные усилия. Я считаю, что исходная фабрика Oracle также увидела эту проблему и запустила MySQL Analytics Engine.

2. МАЭ?

MySQL Analytics Engine (сокращенно MAE), вообще говоря, представляет собой встроенный механизм анализа. Его сочетание с базой данных MySQL позволяет администраторам баз данных и разработчикам приложений напрямую использовать базу данных MySQL в качестве унифицированной службы для рабочих нагрузок OLTP и OLAP. Он предоставляет «Службу базы данных MySQL с Analytics Engine», которая состоит из экземпляра базы данных MySQL и нескольких узлов анализа. Когда аналитика включена, на инстансе БД будет установлена служба аналитики, отвечающая за управление кластером, загрузку данных, выполнение запросов и т.д. С точки зрения пользователя его можно подключить и использовать через стандартный коннектор MySQL JDBC/ODBC. Ниже рассмотрим подробнее

Прежде всего, с точки зрения общего использования, он предоставляет унифицированную службу базы данных MySQL для внешнего мира. Пользователи по-прежнему используют его традиционным способом, будь то сценарии OLTP или OLAP. В эту службу включены традиционный механизм OLTP и новый механизм аналитики. В данных также есть две копии. Первый по-прежнему хранится в механизме хранения, таком как InnoDB, а второй хранится в памяти кластера узлов. Изменения данных, вызванные обычными транзакционными операциями, прозрачно распространяются на последующие кластеры анализа для ускорения обработки анализа. Это позволяет клиентам запускать рабочие нагрузки OLTP и OLAP на одной платформе базы данных. Короче говоря, это два вычислительных движка и два хранилища данных.

Основная рабочая идея MAE состоит в том, чтобы «превратить большое в маленькое».Благодаря механизму разделов данные разбиваются и обрабатываются независимыми ресурсами ЦП. Обработанные результаты возвращаются единообразно.

Внутри MAE он состоит из нескольких узлов анализа. Конкретное количество узлов может быть автоматически получено консультантом по автоматической настройке, предоставляемым механизмом анализа MySQL. В узлах данные хранятся в гибридном столбцовом сжатом формате. Это помогает с векторизацией, что приводит к очень хорошей производительности запросов. Данные кодируются и сжимаются перед запуском в памяти. Это сжатое и оптимизированное использование памяти, особенно для числовых и строковых данных, повышает производительность и уменьшает объем памяти, что приводит к снижению затрат для клиентов. При этом в каждом узле используется технология параллельной работы, что обеспечивает высокую скорость попадания в кэш для анализа и обеспечивает хорошую масштабируемость между узлами. Каждый аналитический узел в кластере и каждое ядро в узле могут обрабатывать секционированные данные параллельно, включая параллельное сканирование, объединение, группировку, агрегирование и обработку k-го числа.

MySQL Analytical Engine реализует новейшие алгоритмы распределенной аналитической обработки в памяти. Соединения внутри раздела можно быстро обрабатывать с помощью ядра векторизованной сборки и пробного соединения. Сетевое взаимодействие между узлами аналитики оптимизировано за счет использования асинхронного пакетного ввода-вывода. Алгоритм разработан таким образом, что время вычислений перекрывается с передачей данных между узлами, что помогает достичь хорошей масштабируемости.

MySQL необходим анализ и анализ всех OLTP двигателя и услуги базы данных MySQL к интеграции предприятия представляет собой единую платформу управления данными. MySQL Анализ двигатель выполнен в виде сменного механизма хранения данных MySQL, которая полностью экранировать основной слой хранения всех деталей реализации, а не конечный пользователь видит. Пользователи и приложения через узел базы данных MySQL в кластерном анализе, чтобы взаимодействовать с MySQL. Пользователь с помощью стандартных инструментов и основанного на стандартах ODBC / JDBC разъем к MySQL анализа двигателя. MySQL механизм анализа поддерживает те же MySQL ANSI SQL стандартные и кислотные свойства, и поддерживать различные типы данных. Это позволяет существующим приложениям без каких-либо изменений в их приложениях может воспользоваться для анализа двигателя MySQL, что позволяет быстро и легко интегрировать. После того, как пользователь отправляет запрос к базе данных MySQL, MySQL запросы оптимизатор будет решить, следует ли прозрачно запрос для анализа выгрузки кластера для ускорения реализации. Этот анализ основан на двигатели MySQL поддерживают все операторы и функции, на которые ссылается в процессах запроса и анализа двигателя, используя расчетное время запроса менее чем MySQL, то запрос будет выталкиваться вниз к узлу анализа для обработки. После обработки, результаты передаются обратно в узел базы данных MySQL, и возвращаются к пользователю.

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

3. Что может дать нам МАЭ?

С точки зрения продукта, MySQL Analytics Engine — это облачная служба, доступная исключительно в Oracle Cloud Infrastructure, обеспечивающая непревзойденную производительность и экономичность для аналитических рабочих нагрузок. Организации, использующие базы данных MySQL для управления корпоративными данными, теперь могут использовать аналитический механизм MySQL для выполнения аналитических запросов со значительно улучшенной производительностью, меньшими затратами, отсутствием необходимости в ETL и поддержкой аналитики в реальном времени. Сервис, который можно развернуть только в облаке или в гибридной среде, упрощает управление транзакционными и аналитическими приложениями. С момента запуска продукта его можно обобщить в следующих концепциях:

❖ ОДНА БД

Основная ценность этого продукта — унифицированная обработка сценариев. В прошлом MySQL приходилось использовать следующие методы при работе со смешанными бизнес-сценариями (как показано на рисунке ниже):

Благодаря внедрению MAE возможности MySQL расширены для достижения унифицированного эффекта.

❖ ОДИН SQL

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

❖ НЕТ ETL

Пользователям не нужно заботиться о деталях синхронизации данных, и нет необходимости писать дополнительные задания ETL. Это значительно снизит нагрузку на пользователей.

❖ БЕЗ ТЮНИНГА

До MAE, если пользователи хотели решить проблемы анализа данных, было не более двух типов проблем. Либо внутри библиотеки, либо вне библиотеки. Если это решается в библиотеке, необходимо выполнить большую работу по оптимизации MySQL или принять механизм хранения для сценариев анализа, что приводит к рабочей нагрузке оптимизации. То же самое относится и к решениям вне библиотеки, и пользователям необходимо выполнить работу по оптимизации самостоятельно. С MAE вам не нужно беспокоиться об этом. Он использует возможности автоматизированного машинного обучения (AutoML), разработанные Oracle Labs, для автоматизации каждого аспекта службы. Поскольку эта автоматизация основана на машинном обучении, система может интеллектуально прогнозировать различные сценарии и предпринимать действия, включая автоматическую оценку количества аналитических узлов, необходимых для рабочей нагрузки. При запуске службы таблицы базы данных, выполняющие аналитические запросы, должны быть загружены в память аналитического кластера MySQL. Размер требуемого кластера зависит от таблиц и столбцов, необходимых для загрузки, а также от степени сжатия этих данных в памяти. В традиционной конфигурации пользователю необходимо угадать размер кластера. Недооценка может привести к сбою загрузки данных или выполнения запроса из-за нехватки места. Завышение приводит к дополнительным затратам на ненужные ресурсы. В результате пользователь продолжает выполнять итерации до тех пор, пока не будет определен правильный размер кластера, и эта оценка размера становится неточной при обновлении таблицы. MAE, с другой стороны, автоматизирует этот процесс.

❖ ВЫСОКАЯ ПРОИЗВОДИТЕЛЬНОСТЬ

Являясь распределенным, масштабируемым, работающим в памяти, гибридным механизмом обработки столбцовых запросов, MAE обеспечивает исключительную производительность за счет векторизованной обработки в памяти и крупномасштабной межузловой и внутриузловой параллельной обработки. В то же время обработка запросов была оптимизирована для Oracle Cloud Infrastructure, включая оптимизацию пропускной способности сети между узлами. Благодаря вышеперечисленным возможностям MAE предоставляет мощные аналитические возможности. Ниже приведено сравнение производительности с основными конкурентами.

MySQL Analytics vs MySQL

MySQL Analytics vs Amazon Aurora

MySQL Analytics vs Amazon Redshift

❖ НИЗКАЯ СТОИМОСТЬ

Стоимость использования службы базы данных MySQL с механизмом аналитики зависит от количества настроенных узлов аналитики. Размер аналитического кластера зависит от размера набора данных и характеристик рабочей нагрузки. Узел аналитики может содержать около 400 ГБ данных. Когда клиенты используют Analytics Engine для перехода на службы баз данных MySQL, можно ожидать, что их затраты значительно снизятся. По сравнению с Amazon Aurora и Redshift аналитическая система MySQL стоит в три раза дешевле.

❖ ПРОСТОЙ МАСШТАБ

В настоящее время MAE поддерживает до 24 аналитических узлов (тысячи ядер) в кластере, обрабатывая примерно 10 ТБ аналитических данных. 10 ТБ — это приблизительный объем данных, который может поместиться в память узла аналитики в данный момент. Объем данных, хранящихся в базе данных MySQL, не ограничен, и клиенты могут выбирать, какие таблицы или столбцы загружать из схемы базы данных MySQL в память узла аналитики. Если эти таблицы больше не нужны запросу, пользователь может удалить эти таблицы из памяти, чтобы освободить место для других данных.

❖ ПРОСТОЕ ИСПОЛЬЗОВАНИЕ

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

Глядя на план выполнения, вы можете визуально увидеть, используется ли кластер анализа (Использование вторичного ядра RAPID на рисунке ниже)

Кроме того, для гибридных облачных сценариев (т. е. для клиентов, которые не могут развернуть данные в облаке) репликация MySQL может использоваться для репликации локальных данных MySQL в механизм аналитики MySQL, опять же без ETL. В настоящее время MAE доступен только на аппаратной платформе Oracle Cloud Infrastructure (OCI) Gen 2.

напиши в конце

Появление MAE компенсировало недостатки встроенных в MySQL сценариев анализа данных. Считается, что эта функция еще больше расширит возможности использования MySQL и проложит путь для ее более крупных и важных корпоративных приложений. Жаль, что MAE в настоящее время можно использовать только в OCI, а большинство офлайн-пользователей в Китае еще не умеют им пользоваться.