Планирование развертываний База данных Azure для PostgreSQL для производительности операций

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

Introduction

Гибкость выбора соответствующего баланса ресурсов особенно важна для развертываний баз данных PostgreSQL. Рабочие нагрузки базы данных PostgreSQL могут начинаться небольшими, быстро увеличиваться, увеличиваться сезонно, переходить от высокой нагрузки на чтение к высокой нагрузке на запись или переходить от рабочих нагрузок транзакций в гибридные операционные и аналитические системы в режиме реального времени. База данных Azure для PostgreSQL гарантирует, что ваши решения достигли целевых объектов, предлагая широкий спектр вариантов для вычислений, хранения, доступности, репликации, безопасности, резервного копирования и управления операционными ресурсами.

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

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

Лучшей архитектурой является та, где эти части намеренно согласованы.

Планирование производительности облака — это общая ответственность

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

Самые сильные результаты возникают, когда эти две силы унифицируются.

Azure обеспечивает высокомасштабируемую инфраструктуру Postgres, но ваша команда должна предоставить аналитические сведения в следующих областях:

Сколько одновременных пользователей ожидается в течение обычных и пиковых периодов?
Какие операции наиболее важны: ориентированные на чтение, ориентированные на запись или смешанные?
Резко возрастает ли спрос в конце месяца, квартала, в праздники, при запусках или в периоды отчетности?
Насколько быстро растет набор данных?
Какие операции чувствительны к задержке?
Какие запросы или задания могут допускать более длительное время выполнения?
Является ли рабочая нагрузка в основном OLTP, OLAP или гибридной?
Находятся ли клиенты рядом с регионом базы данных, глобально распределены или сосредоточены в одном географическом регионе?

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

Производительность имеет несколько уровней

Производительность базы данных редко определяется одним параметром. Успешное развертывание зависит от нескольких уровней, работающих вместе:

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

В этой статье основное внимание уделяется третьему уровню: планирование развертывания базы данных Azure Postgres таким образом, чтобы выбор вычислений и хранилища поддерживал необходимый профиль производительности.

База данных Azure для PostgreSQL обеспечивает гибкость, но планирование является важным

гибкий сервер База данных Azure для PostgreSQL предоставляет широкий спектр вариантов развертывания, включая:

Область развертывания	Доступные варианты
Compute	Уровни вычислений, поколения виртуальных машин, конфигурации общего назначения и оптимизированные для памяти конфигурации.
Storage	Azure SSD премиум версии 1, SSD премиум версии 2, масштабирование хранилища, настройка параметров операций ввода-вывода в секунду (IOPS) и настройка пропускной способности.
Availability	Высокий уровень доступности, резервное копирование и восстановление, а также геоизбыточные резервные копии в поддерживаемых конфигурациях.
Replication	Чтение реплик и геореплик.
Security	Управляемые клиентом ключи и интеграция корпоративной безопасности.

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

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

Начало работы с профилем рабочей нагрузки

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

Область планирования	Ответы на вопросы
География	Где находятся пользователи, приложения, реплики и интеграции?
Concurrency	Сколько одновременных подключений и активных запросов ожидается?
Размер данных	Что такое текущий размер базы данных и какой ожидаемый темп роста?
Частота изменений	Насколько быстро данные растут за месяц? Сколько журналов для записи (WAL) создается?
Тип рабочей нагрузки	Является ли система OLTP, OLAP, сильно загруженной отчетами, пакетной системой или гибридной системой?
Комбинированные операции чтения и записи	Сколько процентов операций составляют считывания и записи?
Пиковое поведение	Есть ли прогнозируемые бизнес-циклы, сезонные пики или пакетные окна?
Чувствительность к задержке	Какие транзакции являются ориентированными на пользователя и критически важными по задержке?
Потребности в пропускной способности	Существуют ли обширные сканирования данных, экспорта, импорта или процессы извлечения, преобразования и загрузки (ETL)?
Масштабирование ожиданий	Потребуются ли временные всплески рабочей нагрузки или устойчиво высокая производительность?

Цель заключается не в том, чтобы предсказать будущее совершенно. Цель заключается в том, чтобы избежать слепого проектирования.

Общие сведения о трех основных понятиях производительности хранилища

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

IOPS

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

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

Распространенные сценарии, чувствительные к IOPS, включают:

Обработка больших объемов заказов
Обновления профилей пользователей
Системы инвентаризации
Прием событий
Системы оплаты или выставления счетов
Высоко одновременные приложения SaaS

Пропускная способность

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

Пропускная способность имеет значение при перемещении больших объемов данных. Аналитические запросы, резервные копии, восстановление данных, пакетные задания, сборки индексов, сканирование таблиц и рабочие процессы ETL могут нуждаться в высокой пропускной способности, даже если они не требуют самого высокого числа операций ввода-вывода в секунду (IOPS).

К общим сценариям, зависящим от пропускной способности, относятся следующие:

Создание отчетов по большим таблицам
Массовый импорт или экспорт
Сканирование в стиле хранилищ данных
Операции резервного копирования и восстановления
Операции создания или перестроения больших индексов
Пакетная обработка

Задержка

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

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

Замечание

Диски SSD уровня "Премиум" версии 1 предназначены для однозначных миллисекунд задержки для большинства операций ввода-вывода и, в частности, кэширование дисков может снизить задержку чтения для конфигураций дисков в пределах 4 ТБ. Премиумный SSD v2 и Ultra Disk предлагают задержку менее одной миллисекунды.

Операции ввода-вывода в секунду (IOPS), пропускная способность и задержка должны рассматриваться вместе

IOPS и пропускная способность связаны. Рабочая нагрузка, выполняющая несколько небольших операций 8-КиБ, может привести к высокой частоте операций ввода-вывода в секунду (IOPS) без высокой пропускной способности. Рабочая нагрузка, выполняющая многомегабайтные операции, может привести к высокой пропускной способности с низкими IOPS.

Простой способ подумать об этом:

IOPS x размер операций ввода-вывода = пропускная способность

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

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

Выбор развертывания напрямую влияет на производительность хранилища

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

Производительность хранилища Azure зависит от нескольких факторов. Эти детали включают:

Набор вычислительных возможностей (максимальное количество операций ввода-вывода в секунду и ограничения пропускной способности).
Поколение хранилища (SSD версии 1, SSD версии 2, диск категории "Ультра").
Размер диска хранилища (диски SSD v1 до 4096 ГБ включают хостовое кэширование, что позволяет всплески IOPS, превышающие стандартные базовые значения).
Емкость операций ввода-вывода в секунду хранилища.
Емкость пропускной способности хранилища.

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

Если конфигурация хранилища способна предложить 80 000 операций ввода-вывода в секунду, но SKU вычислительных ресурсов может выполнять только 20 000 операций ввода-вывода в секунду, развертывание не сможет обеспечить 80 000 операций ввода-вывода в секунду. И наоборот, если поколение виртуальных машин поддерживает высокий объем IOPS (операций ввода-вывода в секунду), но выбранный уровень хранилища ограничен, уровень хранилища становится ограничивающим фактором.

Планирование вычислений и хранилища должно выполняться вместе.

Ssd уровня "Премиум" версии 1: высокая базовая производительность с важным поведением кэширования

Premium SSD v1 — это популярный выбор для рабочих нагрузок Azure Postgres, которым требуется предсказуемая и выделенная производительность. Хранилище Azure Postgres SSD v1 поддерживает до 32 ТБ хранения, 20 000 IOPS и пропускную способность 900 МБ/с.

SSD уровня "Премиум" версии 1 хорошо подходит для рабочих нагрузок, которые выгодно использовать с кэшированием на узле. Azure Postgres поддерживает кэширование на уровне узла для размеров дисков SSD версии 1 менее 4,096 ГБ. Любой диск объемом до 4095 ГБ может использовать преимущества кэширования на хосте. После подготовки хранилища в 4096 ГБ или более кэширование узла не обеспечивается. Эта граница имеет значение. Для развертываний SSD уровня "Премиум" версии 1 в пределах 4 ТБ кэширование может повысить производительность чтения и уменьшить задержку чтения. Это кэширование создает отличную эффективность затрат к производительности для рабочих нагрузок с большим объемом чтения или смешанных рабочих нагрузок, которые укладываются в пределы порогового значения кэширования.

Почему граница 4 ТБ имеет значение

Когда развертывание SSD уровня "Премиум" версии 1 выходит за рамки поддерживаемого кэшированием диапазона, профиль производительности может измениться:

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

Превышение объема 4 ТБ неплохо, но вы должны планировать это.

Если вы ожидаете, что база данных увеличится до 4 ТБ, рассмотрите будущее состояние во время проектирования архитектуры. Конфигурация, которая хорошо работает при 2 ТБ с кэшированием, может потребовать иной план производительности при 5 ТБ без кэширования.

Бёрст помогает с пиками, но не заменяет устойчивую производительность.

Распределение хранилища Azure PostgreSQL Premium SSD версии 1 объемом до 4 ТБ поддерживает всплески кеширования узлов, что может помочь в таких сценариях, как:

Действие запуска
Короткие пакетные задания
Пики трафика
Обработка в конце месяца
Временные всплески рабочей нагрузки

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

Хороший вопрос планирования: Это временный всплеск, или это новая норма?

Временные пики могут быть хорошими кандидатами на всплеск. Управление устойчивым спросом с помощью целенаправленного планирования мощностей.

Емкость, количество операций ввода-вывода в секунду (IOPS) и пропускная способность в Премиум SSD версии 2 разделены.

SSD уровня «Премиум» версии 2 изменяет модель планирования, отделяя размер диска, IOPS и пропускную способность. База данных Azure для PostgreSQL гибкий сервер SSD уровня "Премиум" версии 2 поддерживает:

Емкость от 32 ГБ до 64 ТБ.
До 80 000 операций ввода-вывода в секунду.
До 1200 МБ/с пропускной способности.
Гранулярные настройки емкости с шагом 1 ГБ.
Гибкая конфигурация IOPS и пропускной способности.
Низкая задержка, чем SSD уровня "Премиум" версии 1.
Кэширование хоста отсутствует.

Это изменение является основным сдвигом. При использовании SSD уровня "Премиум" версии 1 производительность более тесно связана с размером диска. С помощью SSD уровня "Премиум" версии 2 можно настроить производительность непосредственно вокруг рабочей нагрузки.

Например, база данных с интенсивной транзакционной нагрузкой может потребовать большого количества операций ввода-вывода в секунду, не требуя большого объема хранилища. Azure Postgres предоставляет базовые IOPS и пропускную способность без дополнительных затрат, с возможностью получения дополнительных IOPS и пропускной способности за дополнительную плату. Предложения SSD уровня "Премиум" версии 2:

Диски размером до 399 ГБ получают базовые показатели 3000 операций ввода-вывода в секунду и 125 МБ/с.
Диски размером 400 ГБ или больше получают базовые показатели 12 000 операций ввода-вывода в секунду и 500 МБ/с.
Диски могут достигать 80 000 операций ввода-вывода в секунду при условии, что размер доступного пространства не менее 160 ГБ.
Пропускная способность может масштабироваться до 1200 МБ/с.

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

Диск Ultra (предварительная версия): высокоэффективный класс производительности Azure диска

Диск категории "Ультра" — это самый высокий уровень производительности диска. Azure Ultra Disk предоставляет уровни производительности до:

400 000 операций ввода-вывода в секунду
Пропускная способность 10 000 МБ/с
64 ТБ емкости
Целевые параметры проектирования для субмиллисекундной задержки
Независимо настраиваемая емкость, IOPS (операции ввода-вывода в секунду) и пропускная способность

Хранилище дисков категории "Ультра" предназначено для обеспечения высокой нагрузки операций ввода-вывода для баз данных верхнего уровня, SAP HANA и тяжелых для транзакций систем. Новое хранилище обеспечивает превосходную производительность для критически важных рабочих нагрузок. Тем не менее, ваша команда должна учитывать некоторые ключевые возможности развертывания, ограничения региональной доступности и параметры конфигурации при планировании развертывания:

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

Важно понимать возможности Ultra Disk в рамках более широкого ландшафта производительности хранилища Azure. Однако необходимо проверить доступность сервиса и поддержку конкретной рабочей нагрузки Azure Postgres. Обратитесь к представителю Microsoft, если предварительная версия диска "Ультра" доступна для развертывания Azure Postgres.

Практический вывод: Ultra Disk представляет верхний предел производительности хранилища Azure, но полный дизайн Postgres должен включать аналогично поддерживаемые комбинации для выбранных вычислительных ресурсов, региона и уровня выпуска.

Вопросы создания виртуальных машин: потолки вычислительных хранилищ V5 и V6 отличаются

Создание вычислений может существенно повлиять на производительность хранилища. При изучении наиболее высокой производительности хранилища Azure избегайте недоразумений относительно того, что "значительные вычислительные ресурсы" автоматически означают "максимальное хранилище". Вы должны проверить выбранный SKU вычислительных ресурсов относительно предполагаемого уровня хранилища. Давайте проиллюстрируем этот аспект, рассмотрев два поколения вычислительных систем схожего размера: Ddsv5 и Ddsv6.

Серия Ddsv5 поддерживает хранилище класса Premium (с кэшированием), Premium SSD v2 и Ultra Disk на уровне семейства виртуальных машин. Однако агрегированные ограничения удаленного хранилища виртуальной машины по-прежнему определяют потолок для того, что виртуальная машина может управлять. Ddsv5-series обеспечивает скорость работы хранилища до 80 000 операций ввода-вывода в секунду и 2600 МБ/с.

Серия Ddsv6предоставляет более высокую ёмкость хранилища, достигающую до 400 000 операций ввода-вывода в секунду и 12 000 МБ/с. Вычислительные ресурсы серии V6 также обеспечивают более высокую масштабируемость, чем предыдущие поколения, с объемом памяти до 192 виртуальных ЦП и 768-ГиБ.

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

Пример: Почему важно полное выравнивание

Рассмотрим рабочую нагрузку PostgreSQL с целевой целью хранения 400 000 операций ввода-вывода в секунду.

На уровне дисков Azure Ultra Disk поддерживает до 400 000 операций ввода-вывода в секунду (IOPS) на диск. SSD уровня "Премиум" версии 2 поддерживает до 80 000 операций ввода-вывода в секунду на диск, а для более высоких агрегатных проектов может потребоваться несколько дисков или абстракции на уровне платформы в зависимости от поддержки служб.

Но только возможности хранилища недостаточно.

Конфигурация серии V5 может иметь потолок хранилища, который ниже целевого. Как упоминалось ранее, номера SKU серии V5 поддерживают до 260 000 операций ввода-вывода в секунду для пропускной способности удаленного диска SSD уровня "Премиум". В этом случае выбор вычислительного слоя серии V5 для этого целевого объекта становится ограничением до достижения целевого объекта в 400 000 операций ввода-вывода в секунду.

В отличие от этого, документация по серии Ddsv6 предлагает до 400 000 операций ввода-вывода в секунду и 12 000 МБ/с. Это делает серии V6 и более новые поколения стратегически важными для проектов, которые должны координировать вычислительные ресурсы и хранилище вокруг классов высокой производительности хранилища.

Урок прост: максимальная производительность базы данных — это комплексное свойство, а не свойство только для хранения.

Планируйте бизнес-циклы, а не только стабильное состояние.

Многие системы не имеют единого профиля производительности. У них есть несколько:


Обычный будний трафик.	Пиковые рабочие часы.
Обработка в конце месяца или квартала.	Праздник или сезонный спрос.
События запуска продукта.	Окна отчетов.
Периоды обслуживания.	пакетная служба Azure периоды приема.
Сценарии резервного копирования и восстановления.	События аварийного восстановления.

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

Гибкость платформы Azure позволяет командам делать более тонкие выборы. Рассмотрим пример.

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

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

Наблюдаемость является частью архитектуры

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

Область мониторинга	Сигналы для анализа
Compute	Загрузка ЦП и давление на память.
Connections	Активные подключения, неактивные подключения и поведение пула подключений.
Запросы	Длительность запроса, изменения плана запроса и использование индекса.
Storage	Процент хранения, задержка чтения, задержка записи, использование операций ввода-вывода в секунду и статистика пропускной способности.
Maintenance	Таблица разбухания, разбухание индекса, характеристики WAL, расписания резервного копирования и расписания обслуживания.
Replication	Задержка реплики, при наличии.

Документация База данных Azure для PostgreSQL акцентирует внимание на мониторинге потребления I/O через портал Azure или метрики Azure CLI, включая ограничение хранилища, процент использования хранилища, фактически используемый объем и процент I/O.

Эти метрики помогают ответить на наиболее важный операционный вопрос: какой уровень фактически ограничивает производительность?

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

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

Контрольный список практического планирования

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

Category	Планирование входных данных
Тип рабочей нагрузки	OLTP, OLAP, гибрид, отчеты, пакет и поглощение.
Комбинированные операции чтения и записи	Процент операций чтения, записи, случайных операций ввода-вывода и последовательного ввода-вывода.
Текущая производительность	Базовые IOPS, пропускная способность, задержка, ЦП, память и подключения.
Пиковая производительность	Требования к рабочей нагрузке для 90-го и 99-го процентилей.
Размер данных	Текущий размер, ожидаемый рост, использование больших объектов и рост индекса.
Темпы роста	Прогнозы изменений объема хранения по месяцам и годам.
Concurrency	Активные сеансы, неактивные сеансы и поведение пула подключений.
Бизнес-циклы	Ежедневные, еженедельные, ежемесячные, сезонные и связанные с запуском пики.
Availability	Высокая доступность, реплики, аварийное восстановление, резервное копирование, восстановление, целевая точка восстановления (RPO) и целевое время восстановления (RTO).
Выбор хранилища	SSD уровня "Премиум", SSD уровня "Премиум" версии 2, поддерживаемые регионы и поддерживаемые функции.
Влияние кэширования	Применяется ли хост-кэширование для SSD v1 'Премиум' при объеме менее 4 ТБ.
Генерация вычислительных ресурсов	Может ли выбранный SKU обеспечить необходимые операции ввода-вывода в секунду (IOPS) и пропускную способность.
Модель масштабирования	Масштабирование вручную, запланированное масштабирование, корректировка производительности и реплики.
Observability	Метрики, оповещения, аналитические сведения о запросах и процесс проверки рабочей нагрузки.

Реальный тест производительности: сравнение конфигураций хранилища под нагрузкой

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

Настройка и методология теста

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

Все тесты выполняются на гибком сервере База данных Azure для PostgreSQL в одном регионе в пределах одной зоны доступности с использованием одного тестового базы данных и профиля рабочей нагрузки. Изолируя хранилище и вычисления в качестве переменных, вы гарантируете, что различия в производительности отражают фактические возможности платформы, а не сетевые, приложения или варианты рабочей нагрузки.

Детали конфигурации

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

Конфигурация	SKU для вычислений	vCores	Memory	Максимальное число операций ввода-вывода в секунду	Тип хранилища	Capacity	IOPS	Пропускная способность
Конфигурация 1	Standard_D16ds_v5	16	64 ГБ	25 600 (40 000 пиковая)	SSD уровня "Премиум" (P50)	4095 ГБ	7,500	250 МБ/с
Конфигурация 2	Standard_D16ds_v5	16	64 ГБ	25 600 (40 000 пиковая)	SSD уровня "Премиум" (P50)	4096 ГБ	7,500	250 МБ/с
Конфиг 3	Standard_D16ds_v5	16	64 ГБ	25 600 (40 000 пиковое значение)	SSD уровня "Премиум" (P80)	32 ТБ	20,000	900 МБ/с
Конфигурация 4	Standard_D16ds_v5	16	64 ГБ	25 600 (40 000 пиковое значение)	SSD Премиум версия 2	4095 ГБ	40,000	1200 МБ/с
Конфигурация 5	Standard_D32ds_v5	32	128 ГБ	51 200	SSD Премиум версия 2	4095 ГБ	60 000	1200 МБ/с

Ключевые наблюдения из структуры конфигурации:

Config 1 и Config 2: Эти конфигурации различаются только по размеру хранилища, 4095 ГБ и 4096 ГБ. Это сравнение проверяет границу кэширования узла для дисков SSD уровня "Премиум" версии 1.
Config 2 и Config 3: Обе конфигурации используют SSD версии 1, но конфигурация 3 масштабируется до 32 ТБ емкости для разблокировки более высоких операций ввода-вывода в секунду и пропускной способности.
Config 3 и Config 4: Обе конфигурации используют одни и те же вычислительные ресурсы, но Config 4 демонстрирует гибкость IOPS и пропускную способность Premium SSD v2 независимо от емкости.
Config 4 и Config 5: Конфигурация 5 удваивает SKU вычислительных ресурсов, чтобы продемонстрировать, как более мощные вычислительные ресурсы обеспечивают больше возможностей для повышения производительности хранилища.

Результаты производительности

Конфигурация 1: 4 095 ГБ SSD уровня "Премиум" версии 1 с кэшированием на уровне узла

Конфигурация 1 использует размер SSD категории "Премиум" 4095 ГБ версии 1, что обеспечивает преимущества кэширования узлов на SSD уровня "Премиум" версии 1. В период рабочей нагрузки эта конфигурация выдерживала:

Максимальное число операций ввода-вывода в секунду: 24 773, ограничено 7 500 подготовленными операциями ввода-вывода в секунду на SSD класса "Премиум" версии 1, что повышает эффективную производительность за счет кэширования.
Максимальное число операций ввода-вывода в секунду на чтение: 21,330, с использованием кэша хоста для операций с интенсивным чтением.
Максимальное число операций ввода-вывода в секунду: 7610.

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

Конфигурация 2: 4096 ГБ SSD версии 1 в уровне "Премиум" без кэширования на узле

Конфигурация 2 использует накопитель SSD премиум-класса объемом 4 096 ГБ версии 1, пересекая границу кэширования и теряя преимущества кэширования хоста. Влияние видно:

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

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

Конфигурация 3: SSD уровня "Премиум" 32 ТБ версии 1 с более высоким числом операций ввода-вывода в секунду

Конфигурация 3 решает проблемы с верхними пределами IOPS и пропускной способности для Премиум SSD версии 1, масштабируя емкость до 32 ТБ. Эта конфигурация достигнута:

Максимальное число операций ввода-вывода в секунду: 20 000.
Максимальное число операций ввода-вывода в секунду: Приблизительно 12 000.
Максимальное число операций ввода-вывода в секунду: Около 5000.

Увеличение емкости хранилища SSD уровня "Премиум" версии 1 увеличивает количество операций ввода-вывода в секунду и пропускную способность. Вы по-прежнему можете достичь верхних пределов диапазона вычислительных хранилищ для интенсивных рабочих нагрузок.

Конфигурация 4. Ssd уровня "Премиум" версии 2 с 40 000 операций ввода-вывода в секунду

Конфигурация 4 демонстрирует гибкую производительность SSD уровня "Премиум" версии 2 (v2), предоставляя 40 000 IOPS и пропускную способность 1200 МБ/с на 4095 ГБ емкости.

Максимальное число операций ввода-вывода в секунду: Более эффективное использование из-за задержки и пропускной способности SSD уровня "Премиум" версии 2.
Максимальное число операций ввода-вывода в секунду: Улучшенная производительность по сравнению с конфигурациями SSD уровня "Премиум" версии 1.
Максимальное число операций ввода-вывода в секунду: Высокая устойчивая емкость записи.

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

Конфигурация 5: Премиум SSD v2 с 60 000 IOPS на вычислительных ресурсах D32ds_v5

Конфигурация 5 одновременно масштабирует производительность хранилища до 60 000 операций ввода-вывода в секунду и вычислительные ресурсы с помощью Standard_D32ds_v5 и 32 виртуальных процессорных ядер. Эта конфигурация демонстрирует комплексный принцип выравнивания:

Максимальное число операций ввода-вывода в секунду: Значительно выше всех предыдущих конфигураций.
Максимальное количество операций ввода-вывода в секунду: Значительное улучшение с дополнительным запасом вычислительной мощности.
Максимальное число операций ввода-вывода в секунду: Устойчивая более высокая емкость записи.

Выравнивая вычислительные ресурсы и хранилище на более высокие уровни производительности, эта конфигурация обеспечивает оптимальную пропускную способность и наименьшее давление ЦП. Более высокий потолок хранилища D32ds_v5 позволяет более полно использовать диск Premium SSD v2 с производительностью до 60 000 операций ввода-вывода в секунду.

Уроки из эталонных показателей

Эти пять конфигураций иллюстрируют основные принципы из этой статьи:

Граница кэширования размером 4 ТБ имеет значение.
Config 1 и Config 2 показывают, что кэширование на стороне хоста обеспечивает измеримое увеличение производительности чтения менее чем 4 ТБ, а при превышении 4096 ГБ это преимущество исчезает.
Емкость не является производительностью.
Config 3 подготовило 32 ТБ, но не обеспечивало максимальные IOPS. Емкость хранилища не определяет пропускную способность транзакций.
Ssd уровня "Премиум" версии 2 обеспечивает гибкую настройку производительности.
Конфигурация четыре продемонстрировала высокий уровень операций ввода-вывода в секунду (IOPS) на скромной емкости, подтверждая разделённую модель, которую включает Premium SSD v2.
Вычисления и хранилище должны быть выровнены.
Конфигурация пять показывает, что максимизация производительности хранилища требует достаточной вычислительной мощности. Более высокий лимит хранения D32ds_v5 был необходим для более эффективного использования выделения 60 000 операций ввода-вывода в секунду.

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

Conclusion

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

Максимальная производительность не происходит случайно.

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

SSD Premium версии 1 может предоставить надежную прогнозируемую производительность, особенно если кэширование хоста применяется к данным, находящимся ниже границы 4 ТБ. SSD уровня "Премиум" версии 2 добавляет более гибкую конфигурацию производительности за счет разделения емкости, IOPS и пропускной способности. Диск Ultra представляет самый высокий класс по производительности управляемых дисков в Azure, а новые поколения вычислительных ресурсов обеспечивают значительно более высокие совокупные потолки удаленного хранилища для высокоуровневых архитектур.

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

Azure хранилище класса Premium: проектирование для высокой производительности
Azure пиковое увеличение производительности диска
Размеры виртуальных машин серии Ddv5 и Ddsv5
Размеры виртуальных машин серии Ddsv6
опция хранилища Premium SSD в База данных Azure для PostgreSQL
Premium SSD версии 2 в База данных Azure для PostgreSQL
Типы управляемых дисков Azure
Мониторинг метрик в Базе данных Azure для PostgreSQL

Обратная связь

Были ли сведения на этой странице полезными?

Last updated on 2026-05-08