Рекомендации по оптимальной производительности База данных Azure для MySQL — гибкий сервер
Узнайте, как повысить производительность при работе с База данных Azure для MySQL гибким сервером. По мере добавления новых возможностей платформы будут уточняться и наши рекомендации в этом разделе.
Физическая удаленность
Убедитесь, что приложение и база данных развернуты в одном регионе. Быстрая проверка перед запуском любого теста производительности заключается в определении сетевой задержки между клиентом и базой данных с помощью простого запроса SELECT 1.
Если такие ресурсы, как веб-приложение и связанная с ним база данных, выполняются в разных регионах, обмен данными между этими ресурсами может происходить с повышенной задержкой. Размещение приложения и базы данных в разных регионах влечет и другой побочный эффект: затраты на передачу исходящих данных.
Чтобы повысить производительность и надежность приложения в оптимизированном для затрат развертывании, настоятельно рекомендуется использовать службу веб-приложений и ресурс гибкого сервера База данных Azure для MySQL в одном регионе и зоне доступности. Совместное размещение важнее всего для приложений, чувствительных к сетевым задержкам. Также оно повышает пропускную способность благодаря близости ресурсов.
Ускорение работы в сети
Примените ускорение сети для сервера приложений, если вы используете виртуальную машину Azure, Azure Kubernetes или службы приложений. Функция ускорения работы в сети позволяет использовать виртуализацию ввода-вывода с единым корнем (SR-IOV), повышая тем самым производительность сети виртуальной машины. Этот высокопроизводительный метод обеспечивает обход узла на пути к данным, что уменьшает задержку, дрожание и нагрузку ЦП. Он предназначен для ресурсоемких рабочих нагрузок сети на виртуальных машинах поддерживаемых типов.
Эффективность подключения
Установка нового соединения всегда является дорогостоящей и трудоемкой задачей. Когда приложение запрашивает подключение к базе данных, оно определяет приоритет выделения существующих бездействующих подключений к базе данных, а не создает новое подключение. Ниже приведены некоторые решения для оптимизации подключения.
ProxySQL. Используйте ProxySQL, который предоставляет встроенные пулы подключений и распределяет нагрузку по нескольким репликам чтения по мере необходимости, не требуя даже изменять код приложения.
Прокси-сервер данных Heimdall. Кроме того, вы можете использовать прокси-сервер данных Heimdall, патентованное решение для создания прокси-серверов для любых поставщиков. Он поддерживает кэширование запросов и разделение операций чтения и записи с обнаружением задержки репликации. Подробности можно узнать в статье об ускорении производительности MySQL с помощью прокси-сервера Heimdall.
Постоянное или продолжительное подключение. Если приложение генерирует короткие транзакции или запросы, обычно со временем выполнения < 5–10 мс, замените краткосрочные подключения на постоянные. Замена краткосрочных подключений на постоянные требует лишь незначительных изменений в коде, но оказывает значительное влияние в плане повышения производительности во многих типичных прикладных сценариях. Не забудьте задать время ожидания или закрыть подключение по завершении транзакции.
Реплика. Если вы используете реплику, добавьте ProxySQL для балансировки нагрузки между сервером базы данных-источника и доступным для чтения сервером вспомогательной реплики. См. раздел Настройка ProxySQL.
Организация пулов соединений
Пул подключений предоставляет механизм автоматического управления созданием и выделением подключений к базе данных, который призван защитить базу данных от чрезмерного количества подключений. Пул подключений может оказаться полезным, если используемое приложение открывает множество краткосрочных подключений в течение относительно короткого времени. Такое поведение может создавать сотни и тысячи подключений в секунду, и в этом случае время на создание и закрытие подключений будет значительным по сравнению с общим временем существования подключений.
Если платформа разработки приложения не поддерживает пул подключений, вместо этого используйте прокси-сервер подключения, например ProxySQL или прокси-сервер Heimdall, между приложением и сервером базы данных.
Обработка масштабирования подключения
Для масштабирования веб-приложений с учетом изменений спроса чаще всего применяется метод добавления и удаления серверов приложений. Каждый сервер приложений может использовать собственный пул подключений для обращений к базе данных. Такой подход повышает общее число подключений к серверу базы данных пропорционально числу серверов приложений. Например, если к серверу базы данных подключаются 10 серверов приложений, каждый из которых может создавать до 100 подключений к базе данных, в общей сложности это составит 1000 подключений к базе данных. Если рабочая нагрузка приложения масштабируется с добавлением еще 50 серверов из-за повышения активности пользователей, общее число подключений к базе данных может достичь 6000. Большинство из этих подключений будут неактивными после того, как серверы приложений их создадут. Так как неактивные подключения используют ресурсы (память и ЦП), чтобы оставаться открытыми, масштабируемость базы данных может повлиять.
Потенциально также могут возникать проблемы с обработкой такого числа подключений к серверу базы данных. Успешность обработки зависит от количества серверов приложений, подключенных к серверу базы данных, каждый из которых создает собственный набор подключений. В таких сценариях можно изменить настройки пулов подключений на серверах приложений. Попробуйте уменьшить количество подключений в каждом пуле до приемлемого минимума, чтобы убедиться, что на стороне сервера базы данных нет больших двоичных объектов. Это решение следует считать краткосрочной мерой для временного устранения проблем, вызванных масштабированием сервера приложений, и не следует использовать как основной вариант при увеличении масштаба приложения.
В качестве долгосрочного решения следует добавить между сервером базы данных и сервером приложений прокси-сервер подключений, например прокси-сервер ProxySQL или Heimdall. Этот прокси-сервер будет выполнять следующие задачи:
- создание подключений к серверу базы данных с фиксированным ограничением количества;
- прием подключений от приложений и защита от потенциальных всплесков количества подключений.
Прокси-серверы могут предоставлять и дополнительные функции, такие как кэширование запросов, буферизация подключений, перезапись запросов, маршрутизация запросов и балансировка нагрузки. Для дополнительного повышения масштабируемости можно настроить несколько экземпляров прокси-сервера.
Обработка подключений для отказоустойчивости и более быстрого восстановления
При разработке приложений и среды для отказоустойчивости и ускорения восстановления следует учитывать, что в среде базы данных может возникнуть прерывание подключения или сбои оборудования. Также не забывайте о таких оперативных действиях, как масштабирование размеров экземпляров, применение исправлений и отработка отказа вручную.
В качестве примера можем привести сценарий, в котором сервер базы данных выполняет отработку отказа за одну минуту, но приложение не может нормально работать еще несколько минут, так как на стороне приложения настроен слишком длинный срок жизни записей DNS. В таких случаях простое уменьшение этого срока жизни позволит быстрее выполнять восстановление, а добавление прокси-сервера подключений между приложением и сервером базы данных поможет полностью устранить сбои подобного характера.
Секция
Если рабочая нагрузка использует очень большие таблицы, можно повысить производительность базы данных и упростить обслуживание с помощью секционирования. Секционирование упрощает управление большими таблицами, позволяя добавлять и удалять секции для эффективного управления большими таблицами. Секционирование также может помочь масштабировать подсистему, снижая число состязаний за ресурсы внутренней структуры, таких как внутренние блокировки таблиц или индексов (таких, как btr_search_latch в InnoDB).
Например, добавив пять секций, вы по сути разделяете большую таблицу с высоким уровнем активности на пять более эффективных таблиц меньшего размера. Это в первую очередь поможет в случаях, когда основная операция является поиском первичного ключа в таблице, таким образом, что запросы могут воспользоваться преимуществами "обрезки секций". Также секционирование может помочь при сканировании таблиц.
Хотя секционирование имеет свои преимущества, он также имеет некоторые ограничения, такие как отсутствие поддержки внешних ключей в секционированных таблицах, отсутствие кэша запросов и т. д. Полный список этих ограничений в руководстве по MySQL см. в разделе "Ограничения и ограничения для секционирования".
Разделение операций чтения и записи
Основная нагрузка в большинстве приложений приходится на чтение данных из базы данных, и лишь небольшой процент взаимодействий связан с записью. Количество активных подключений к базе данных-источнику, которое мы использовали для вычисления размеров пулов подключений, скорее всего, включает и трафик чтения данных. Если вы переместите максимально возможную часть запросов на чтение реплик, направляя к экземпляру источника только операции записи, вы сможете увеличить общий объем действий с базой данных, доступных серверам приложений, не увеличивая нагрузку на базу данных-источник. Если вы еще не обращаетесь к репликам чтения по крайней мере для более длительных запросов, таких как отчеты, следует рассмотреть возможность немедленного перемещения отчетов или аналитики для чтения реплик.
Более широкое использование реплик чтения может потребовать более тщательного рассмотрения, так как реплики немного отстают от основной из-за асинхронной природы репликации. Найдите в приложении как можно больше элементов, для которых операции чтения можно перенести на реплики, не внося значительных изменений в код приложения. Этот же метод следует применять и на более высоких уровнях — как можно больше содержимого, которое применяется только для чтения или медленно изменяется, следует обслуживать через специальный уровень кэширования, например с помощью Кэша Azure для Redis
Сегментирование и масштабирование операций записи
Приложения со временем развиваются, в том числе дополняются новыми возможностями. Для удобства или просто по традиции таблицы обычно добавляются в базу данных-источник. Чтобы справляться с растущим объемом трафика к базе данных, вам следует выделить области приложения, которые можно легко переместить в отдельные базы данных, и постараться применить горизонтальное сегментирование или вертикальную ориентацию для базы данных.
Горизонтальное сегментирование базы данных выполняется путем создания нескольких копий схемы приложения в отдельных базах данных и распределения между ними клиентов и всех связанных с ними данных на основе идентификатора клиента, географического региона или другого атрибута клиентов или арендаторов. Это очень хорошо подходит для приложений в формате SaaS или B2C, где каждый отдельный клиент не создает большой нагрузки, а масштаб приложения определяется совокупной нагрузкой от работы миллионов клиентов. Однако более сложно использовать приложения B2B, в которых клиенты имеют разные размеры и отдельные крупные клиенты могут доминировать в нагрузке трафика для определенного сегмента.
Вертикальная ориентация нагрузки выполняется путем функционального сегментирования базы данных, то есть перемещения отдельных доменов приложений (именуемых микрослужбами) в собственные базы данных. Это позволяет снять часть нагрузки с базы данных-источника и переместить ее в отдельные базы данных каждой службы. Например, таблица журнала и сведения о конфигурации сайтов не обязательно держать в той же базе данных, где находится активно используемая таблица заказов. Если рассматривать более сложные примеры, можно отделить домены клиентов и учетных записей от заказов или доменов исполнения. В некоторых случаях это может потребовать изменения приложения, например для изменения очередей заданий электронной почты или фоновых заданий, которые должны быть автономными и не полагаться на присоединение обратно к таблице клиентов или заказов. Перемещение существующих таблиц и данных в новую базу данных-источник можно выполнять с помощью База данных Azure для MySQL гибких реплик чтения сервера и продвижения реплики и указания частей приложения на только что созданную базу данных, доступную для записи. Доступ к новой базе данных следует ограничить с помощью пулов подключений, а также настроить запросы и распределить нагрузку с применением таких же реплик, как и для основной базы данных-источника.
Конфигурации импорта данных
- Можно временно масштабировать экземпляр до более высокого размера SKU перед началом операции импорта данных, а затем, после успешного завершения импорта, масштабировать его обратно.
- Данные можно импортировать с минимальным временем простоя с помощью локальной миграции MySQL в База данных Azure для MySQL для миграции в сети или в автономном режиме.
рекомендации по гибкой памяти сервера База данных Azure для MySQL
Рекомендуется выделить достаточно ОЗУ База данных Azure для MySQL гибкого сервера, чтобы рабочий набор находился почти полностью в памяти.
- Проверьте, используется ли процент памяти при достижении ограничений с помощью метрик для гибкого сервера База данных Azure для MySQL.
- Настройте оповещения по таким значениям, которые позволяют быстро принять корректирующие меры по мере того, как серверы будут достигать предела ресурсов. В зависимости от заданных ограничений проверьте, масштабируется ли размер SKU базы данных — либо до более высокого размера вычислений, либо до лучшей ценовой категории, что приводит к значительному увеличению производительности.
- Увеличивайте масштаб до тех пор, пока показатели производительности не перестанут критически падать. Сведения о мониторинге метрик экземпляра базы данных см. в разделе База данных Azure для MySQL Метрики гибкой базы данных сервера.
Использование "прогрева" буферного пула в InnoDB
После перезапуска экземпляра гибкого сервера База данных Azure для MySQL страницы данных, находящиеся в хранилище, загружаются по мере запроса таблиц, что приводит к увеличению задержки и снижению производительности для первого выполнения запросов. Это может быть неприемлемо для конфиденциальных рабочих нагрузок с задержкой.
Использование буферного пула InnoDB позволяет сократить период "прогрева", перезагружая дисковые страницы, которые были в буферном пуле до перезапуска, не ожидая операций DML или SELECT для доступа к соответствующим строкам.
После перезапуска экземпляра гибкого сервера База данных Azure для MySQL можно уменьшить период прогрева, который представляет преимущество производительности, настроив параметры сервера буферного пула InnoDB. InnoDB сохраняет долю последних использованных страниц для каждого буферного пула при завершении работы сервера и восстанавливает эти страницы при запуске сервера.
Важно также отметить, что повышение производительности достигается за счет более длительного времени запуска сервера. Если этот параметр включен, время запуска и перезапуска сервера в зависимости от количества операций ввода-вывода, подготовленных на сервере, должно возрасти.
Мы рекомендуем протестировать и отслеживать время перезапуска, чтобы обеспечить приемлемую производительность при запуске и перезапуске, так как сервер в это время недоступен. Мы не рекомендуем использовать этот параметр, если подготовлено менее 1000 операций ввода-вывода в секунду (или, иными словами, когда подготовленное хранилище меньше 335 ГБ).
Чтобы сохранить состояние буферного пула при завершении работы сервера, задайте для параметра сервера innodb_buffer_pool_dump_at_shutdown значение ON. Аналогичным образом задайте для параметра сервера innodb_buffer_pool_load_at_startup значение ON, чтобы восстановить состояние буферного пула при запуске сервера. Управлять влиянием на время запуска или перезапуска можно путем уменьшения и точной настройки значения параметра сервера innodb_buffer_pool_dump_pct. По умолчанию этот параметр имеет значение 25.
Примечание.
Параметры "прогрева" буферного пула InnoDB поддерживаются только на серверах хранилищ общего назначения с хранилищем объемом до 16 ТБ. Дополнительные сведения см. в разделе База данных Azure для MySQL параметров гибкого хранилища сервера.