В состав этого документа вошли: Чэнь Цзе (по прозвищу Ай'ао на Alibaba), Чжан Пин (Chiyuan), Цяо Хунлинь (Honglin), Тан Цзянь (Tanjian), Qixing и Zhang Tieying (Tieying).

Конференция VLDB 2019 (45-я международная конференция по очень большим базам данных) проходила в Лос-Анджелесе, Калифорния, с 26 по 30 августа 2019 года. На этой конференции несколько докладов группы разработки баз данных Alibaba Cloud были выбраны в исследовательский трек и Индустриальный путь.

В этой статье представлен подробный обзор статьи «iBTune: индивидуальная настройка буфера для крупномасштабных облачных баз данных», включенной в окончательный список журнала Research Track.

Задний план

Около пяти или шести лет назад команда баз данных Alibaba попыталась применить опыт администраторов баз данных к продуктам, чтобы предоставить более эффективные и интеллектуальные службы баз данных для развития бизнеса. Администраторы облачных баз данных предоставляют услуги интеллектуальной диагностики и настройки с самообслуживанием с 2014 года и в 2018 году превратились в платформу самоуправляемых баз данных (SDDP) следующего поколения после четырех лет непрерывных исследований.

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

В конце 2017 года SDDP позволил полностью автоматизировать сквозную оптимизацию для всех экземпляров базы данных, включая автоматические медленные запросы SQL, оптимизацию пространства и параметров для больших баз данных. В этой статье описывается автоматическая настройка параметров для больших баз данных.

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

Академическое сообщество исследовало интеллектуальную настройку базы данных последние год или два. Например, Университет Карнеги-Меллона разработал OtterTune, инструмент автоматической настройки, который основан на предыдущем опыте ручной настройки и не может быть масштабирован для больших баз данных. База данных SQL Azure и AWS также инвестировали в интеллектуальную настройку базы данных, но не опубликовали никаких статей или продуктов.

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

Документ «iBTune: индивидуальная настройка буфера для крупномасштабных облачных баз данных» был выбран для включения в программу исследований на конференции VLDB 2019, что стало важной вехой для бизнеса Alibaba в области анализа баз данных. Этот документ был написан в соавторстве с Тан Цзянем, Тиеин, Фейдао, Ай’ао, Цисином, Чиюань, Хунлинем, Шиюэ, Минсун и Чжан Жуй.

В этом документе предлагаются инновационные идеи для интеллектуальной настройки параметров базы данных, которые были широко реализованы примерно на 10 000 экземплярах в Alibaba Group и помогли снизить использование ресурсов памяти примерно на 12%. Это делает Alibaba единственной компанией в отрасли, которая широко внедряет настройку параметров базы данных.

Определение проблемы

Настройка параметров - важное средство настройки базы данных, и она становится все более сложной по мере увеличения количества параметров базы данных. Например, последняя версия MySQL предоставляет более 500 параметров, и даже PostgreSQL предоставляет около 290 параметров. При настройке базы данных основное внимание уделяется параметрам, влияющим на производительность. Среди этих параметров наибольшее влияние имеют настройки пула буферов.

В настоящее время Alibaba использует развертывание, в котором несколько экземпляров базы данных используют один и тот же хост. Это приводит к бесполезной трате ресурсов сервера, поскольку нехватка памяти хоста часто возникает, несмотря на избыточные ресурсы ЦП и хранилища. Следовательно, нехватка ресурсов памяти представляет собой узкое место, которое не позволяет повысить плотность развертывания экземпляров базы данных.

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

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

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

Разнообразие и постоянные изменения сервисов не позволяют администраторам баз данных вручную настраивать параметры больших баз данных. Это побудило нас исследовать использование алгоритмов, управляемых данными и машинного обучения, для динамической настройки пула буферов базы данных на основе изменений нагрузки и производительности базы данных.

Анализ проблемы

Размер буферного пула и коэффициент попадания напрямую связаны. Мы можем уменьшить размер пула буферов, не затрагивая службу, если сможем найти такую ​​формулу, как Размер пула буферов = Функция (коэффициент совпадений), и определить коэффициент совпадений, приемлемый для бизнес-партнера или администратора базы данных. .

Мы нашли большое количество исследований взаимосвязи между размером буферного пула и коэффициентом попаданий в области исследования кеш-памяти для операционных систем. Некоторые исследования показывают, что соотношение следует степенному распределению в длинной хвостовой части, то есть:

Мы провели стресс-тестирование различных конфигураций буферного пула в основных сценариях обработки онлайн-транзакций (OLTP) в Alibaba, таких как добавление в корзину и оплату транзакции, с помощью Frodo, инструмента, разработанного администраторами баз данных Alibaba. Результаты тестирования показали, что буферный пул MySQL соответствует предположениям о степенном распределении в длинной хвостовой части.

Определение соответствующего коэффициента промахов

У Alibaba более 30 000 первичных узлов экземпляров баз данных. Мы рассмотрели метод поиска экземпляров среди этих экземпляров базы данных, которые похожи на целевой экземпляр, чтобы определить коэффициент промахов целевого экземпляра на основе коэффициента промахов подобных экземпляров.

В качестве показателей производительности для описания рабочей нагрузки службы мы выбрали такие функции, как использование ЦП, логическое чтение, чтение ввода-вывода, коэффициент промахов и время отклика. Мы также выбрали статистические элементы, такие как среднее значение, медиана, 70-й процентиль и 90-й процентиль, чтобы измерить значения этих характеристик.

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

Проблемы алгоритма

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

С точки зрения деловых партнеров и администраторов баз данных, коэффициент попадания не отражает напрямую влияние сервисов баз данных и не может использоваться для измерения стабильности сервисов баз данных. Из-за требований к стабильности мы не можем применить алгоритм на уровне обслуживания, потому что мы не можем количественно оценить влияние обслуживания.

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

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

Модель прогнозирования RT

Мы предложили модель попарной глубокой нейронной сети (DNN) для прогнозирования RT, как показано на следующем рисунке.

DNN - это полностью связанная сеть с функцией активации ReLU. Скрытый слой 1, скрытый слой 2 и скрытый слой 3 имеют 100, 50 и 50 узлов соответственно.

Эксперимент

В эксперименте прогнозирования RT мы сравнили алгоритмы регрессии, такие как линейная регрессия (LR), XGBoost, консенсус случайной выборки (RANSAC), дерево решений (DTree), ENet, Adaptive Boosting (AdaBoost), дерево решений с градиентным усилением (GBDT), Регрессия K-соседей (KNR), регрессор суммирования (BR), регрессор чрезвычайно рандомизированных деревьев (ETR), случайные леса (RF) и кластеризация разреженных подпространств (SSC). Мы добавили алгоритмы глубокого обучения, включая модель экземпляр-вектор (I2V) -DNN на уровне внедрения и попарную модель DNN.

На следующем рисунке показана структура модели I2V-DNN.

Чтобы доказать универсальность алгоритма, мы выбрали 1000 экземпляров из нескольких основных бизнес-сценариев баз данных в Alibaba, включая примеры с разными соотношениями чтения / записи, такие как экземпляры только для чтения, экземпляры только для записи и экземпляры балансировки чтения / записи.

Мы оценили производительность алгоритма, используя следующие три показателя:

AMRAE измеряет процент ошибок в результатах прогнозирования времени отклика, MAE измеряет среднюю ошибку при прогнозировании времени отклика, а UMAE измеряет занижение прогнозов времени отклика.

На следующем рисунке сравниваются результаты прогнозирования времени отклика на основе данных эксперимента.

Как показано на предыдущем рисунке, алгоритм попарного DNN превосходит другие алгоритмы по производительности AMRAE и демонстрирует лучшую производительность по другим показателям. Поэтому мы выбрали попарный алгоритм DNN для прогнозирования времени отклика.

Результаты

Чтобы интуитивно показать изменения до и после настройки пула буферов, мы выбрали 10 экземпляров и измерили их показатели базы данных до и после настройки, как показано на следующем рисунке.

Как показано на предыдущем рисунке, время отклика для разных типов экземпляров (кроме экземпляра 1) не сильно отличается до и после настройки пула буферов. Показатели количества запросов в секунду и использования ЦП показывают, что количество запросов в секунду не сильно различается до и после настройки пула буферов, и что экземпляры потребляют почти одинаковое количество ресурсов. Однако экземпляры показывают разную степень сокращения использования памяти.

Время отклика экземпляра 1 после настройки значительно увеличилось. У этого экземпляра обычно очень мало запросов в секунду, при этом на один запрос приходится большая часть времени обработки. Значение, возвращаемое для этого запроса после настройки, отличается от значения до настройки. Настройка значительно увеличивает количество логических и физических чтений, а также увеличивает среднее время отклика. Однако абсолютное значение времени отклика после настройки невелико, и медленные запросы SQL не возникают. Такая ситуация приемлема для сервисов. Следовательно, откат не срабатывает.

Выполнение

Мы реализовали процесс приложения сквозного алгоритма, от сбора данных до выполнения команд настройки пула буферов. В системе четыре модуля: сбор показателей, обработка данных, принятие решений и исполнение. На следующем рисунке показана конструкция модуля.

  • Сбор метрик: платформа управления базой данных собирает метрики всех экземпляров базы данных в Alibaba, включая все метрики, используемые алгоритмом.
  • Обработка данных: статистика собирается для собранных показателей в разных размерах окна после операции потоковой передачи, а статистические результаты сохраняются в MaxCompute для использования алгоритмом.
  • Принятие решения: этот модуль считывает статистику показателей из MaxCompute и вычисляет их, используя алгоритм для определения размера целевого буферного пула.
  • Выполнение: платформа управления данными запускает команды настройки и планирует соответствующее временное окно, чтобы эффективно выполнять настройку в соответствии с ограничениями выпуска.

Проблемы стабильности

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

Мы предприняли ряд мер для обеспечения стабильности сервиса, в том числе:

  1. Модель алгоритма: регулирует коэффициент чувствительности αα взаимосвязи отображения между размером буферного пула и коэффициентом совпадений, чтобы сделать результат настройки более консервативным.
  2. Онлайн-настройка: настраивает параметры только тех экземпляров, которые поддерживают онлайн-настройку, чтобы избежать сбоев MySQL, вызванных ядром MySQL.
  3. Политика поэтапной настройки: строгая политика поэтапной настройки реализуется во время обширной настройки параметров всей сети. Сначала администратор баз данных службы настраивает небольшое количество экземпляров на основе размера буферного пула, определенного алгоритмом, для обеспечения стабильности службы. Затем администратор баз данных службы добавляет большое количество экземпляров в белый список, позволяя автоматически настраивать размер пула буферов. Наконец, администратор баз данных службы выполняет обширную автоматическую настройку подтвержденных неосновных экземпляров, при этом количество экземпляров ограничивается во время каждой операции настройки.
  4. Процесс с замкнутым циклом: весь процесс настройки представляет собой замкнутый цикл, от сбора данных, принятия решений относительно размера буферного пула и автоматической настройки буферного пула до количественной оценки после настройки и отката. Отчет статистического анализа после настройки выдается каждый день.

Результаты

После изучения алгоритма и автоматической настройки пула буферов от начала до конца в 2019 финансовом году было настроено около 10 000 экземпляров в Alibaba, что снизило общее использование памяти с 217 ТБ до 190 ТБ и сэкономило 12,44% (27 ТБ) ресурсов памяти.

Планы на будущее

  • Что касается бизнеса, то в 2020 финансовом году мы реализуем настройку пула буферов для большего количества экземпляров, чтобы сэкономить больше ресурсов памяти, а также оптимизировать и применить модель алгоритма в общедоступном облаке с помощью управления базой данных гибридного облака (HDM), чтобы предоставить пользователям облака рекомендации по выбору базы данных. типы экземпляров.
  • С технической точки зрения, мы настроим другие параметры, связанные с производительностью базы данных в дополнение к пулу буферов, изучим взаимосвязи и влияние нескольких параметров, связанных с производительностью, и создадим модель на основе взаимосвязи между нагрузкой на базу данных и влиянием на производительность для настройки параметров базы данных. на уровне экземпляра базы данных.

Первоисточник: