Рекомендации по платформе данных для критически важных рабочих нагрузок в Azure

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

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

Критерии выбора платформы данных

Оцените требования к данным в пределах емкости, пропускной способности, модели данных, согласованности и управления перед выбором технологий данных.

Рекомендации по проектированию

Емкость и рост

• Существующие (если таковые) и ожидаемые будущие объемы данных на основе прогнозируемых темпов роста данных, согласованных с бизнес-целями и планами.

  • Объем данных должен охватывать сами данные и индексы, журналы, телеметрию и другие применимые наборы данных.
  • Крупные критически важные и критически важные для бизнеса приложения обычно создают и хранят большие объемы (ГБ и ТБ) ежедневно.
  • С расширением данных могут возникнуть значительные финансовые последствия.

• Объем данных может меняться из-за изменения бизнес-обстоятельств или процедур хранения.

• Объем данных может существенно повлиять на производительность запросов платформы данных.

• Может быть глубокое влияние, связанное с достижением ограничений объема платформы данных.

  • Приведет ли это к простою? и если да, насколько долго?
  • Каковы процедуры устранения рисков? и потребуется ли устранение рисков для изменения приложения?
  • Будет ли риск потери данных?

• Такие функции, как время жизни (TTL) можно использовать для управления ростом данных путем автоматического удаления записей после истечения времени с помощью создания или изменения записи.

  • Например, Azure Cosmos DB предоставляет встроенную возможность TTL.

Пропускная способность и задержка

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

  • Характер требований к пропускной способности будет отличаться по сценариям рабочей нагрузки, таким как те, которые являются тяжелыми для чтения или записи.
    • Например, аналитические рабочие нагрузки обычно должны обеспечить большую пропускную способность чтения.
  • Что такое требуемая пропускная способность? И как ожидается увеличение пропускной способности?
  • Каковы требования к задержке данных на уровне ссылочной нагрузки P50/P99?

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

  • Оптимизация конфигурации для высокой пропускной способности приводит к компромиссам, которые должны быть полностью понятны.
  • Для дальнейшей оптимизации пропускной способности можно использовать шаблоны распределения нагрузки и обмена сообщениями, такие как CQRS и Event Sourcing.

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

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

• Влияние падения пропускной способности может отличаться в зависимости от сценария рабочей нагрузки.

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

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

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

• В конфигурации записи с несколькими регионами изменения должны быть синхронизированы и объединены между всеми репликами с разрешением конфликтов, где это необходимо, и это может повлиять на уровни производительности и масштабируемость.

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

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

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

Модель данных и фигура запроса

• Модель данных, типы данных, связи данных и предполагаемая модель запросов сильно влияют на решения платформы данных.

  • Требуется ли приложению реляционная модель данных или она может поддерживать модель переменных или нереляционных данных?
  • Как будет выполняться запрос данных приложения? И будут ли запросы зависеть от концепций уровня базы данных, таких как реляционные соединения? Или приложение предоставляет такую семантику?

• Характер наборов данных, рассмотренных приложением, может быть различным, от неструктурированного содержимого, например изображений и видео, или более структурированных файлов, таких как CSV и Parquet.

  • Составные рабочие нагрузки приложений обычно имеют различные наборы данных и соответствующие требования.

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

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

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

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

• Наборы функций для каждой службы Azure различаются по языкам, пакетам SDK и API, что может значительно повлиять на уровень настройки конфигурации, которую можно применить.

• Возможности для оптимального согласования с моделью данных и охваченных типов данных существенно влияют на выбор платформы данных.

  • Слои запросов, такие как хранимые процедуры и объектно-реляционные мапперы.
  • Возможность выполнения языково-нейтральных запросов, таких как защищённого уровня REST API.
  • Возможности непрерывности бизнес-процессов, такие как резервное копирование и восстановление.

• Аналитические хранилища данных обычно поддерживают полиглотное хранилище для различных типов структур данных.

  • В аналитических средах выполнения, таких как Apache Spark, могут быть ограничения интеграции для анализа структур данных polyglot.

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

Согласованность и управление

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

  • Согласованность данных.
  • Функции безопасности платформы.
  • Управление данными.
  • Управление изменениями и эволюция схемы.
  • Зависимости между наборами данных.

• В любом распределенном приложении с несколькими репликами данных существует компромисс между согласованностью и задержкой, как выражено в теоремах CAP и PACELC .

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

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

  • Стандартизированные политики разрешения конфликтов, такие как "Last Write Wins", или настраиваемая стратегия с пользовательской логикой может быть применена.

• Реализация требований к безопасности может негативно повлиять на пропускную способность или производительность.

• Шифрование неактивных данных можно реализовать на уровне приложений с помощью шифрования на стороне клиента и (или) уровня данных с помощью шифрования на стороне сервера при необходимости.

• Azure поддерживает различные модели шифрования, включая шифрование на стороне сервера, использующее ключи, управляемые службой, ключи, управляемые клиентом, в Key Vault или управляемые клиентом ключи на оборудовании, управляемом клиентом.

  • С помощью шифрования на стороне клиента ключи можно управлять в Key Vault или другом безопасном расположении.

• Шифрование канала данных MACsec (IEEE 802.1AE MAC) используется для защиты всего трафика, перемещаемого между центрами обработки данных Azure в магистральной сети Майкрософт.

  • Пакеты шифруются и расшифровываются на устройствах перед отправкой, предотвращая физические атаки "man-in-the-middle" или snooping/wiretapping.

• Аутентификация и авторизация на уровне плоскости данных и управления.

  • Как платформа данных будет проходить проверку подлинности и авторизовать доступ к приложениям и операционный доступ?

• Наблюдаемость с помощью мониторинга работоспособности платформы и доступа к данным.

  • Как будет применяться оповещение для условий вне допустимых операционных границ?

Рекомендации по проектированию

Емкость и рост

• Убедитесь, что будущие объемы данных, связанные с органическим ростом, не должны превышать возможности платформы данных.

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

• Отслеживайте объем данных и проверяйте его в модели емкости, учитывая ограничения масштабирования и ожидаемые темпы роста данных.

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

• Определите уровни данных приложения, чтобы классифицировать наборы данных на основе использования и критическости, чтобы упростить удаление или разгрузку старых данных.

  • Рассмотрите возможность классификации наборов данных на уровни "горячий", "теплый" и "холодный" (архив).
    • Например, базовые эталонные реализации используют Azure Cosmos DB для хранения "горячих" данных, активно используемых приложением, в то время как Хранилище BLOB-объектов Azure используются для "холодных" операций для аналитических целей.

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

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

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

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

Пропускная способность и задержка

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

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

• Выравнивайте нагрузку с помощью асинхронного неблокирующего обмена сообщениями, например, используя шаблоны CQRS или Event Sourcing с Служебная шина Azure или Центры событий Azure.

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

• Обеспечьте гибкую масштабируемость для поддержки переменной пропускной способности и уровней нагрузки.

  • Если уровни нагрузки являются весьма неустойчивыми, рассмотрите возможность увеличения уровня емкости, чтобы обеспечить поддержание пропускной способности и производительности.
  • Тестируйте и валидируйте влияние на составные нагрузки приложений, если пропускную способность не удается поддерживать.

• Определите приоритет родных для Azure служб данных с автоматизированными операциями масштабирования, чтобы ускорить реагирование на нестабильность уровня нагрузки.

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

• Отслеживайте пропускную способность чтения и записи данных приложения в соответствии с требованиями к задержке P50/P99 и выравнивайте модель емкости приложения.

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

• Реализуйте кэширование для сценариев с горячими данными, чтобы свести к минимуму время отклика.

  • Примените соответствующие политики для истечения срока действия кэша и хранения, чтобы избежать роста данных.
    • Срок действия элементов кэша при изменении резервных данных.
    • Если срок действия кэша определяется строго временем жизни (Time-To-Live, TTL), важно понимать влияние и опыт клиентов при работе с устаревшими данными.

Модель данных и фигура запроса

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

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

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

• Убедитесь, что необходимые возможности доступны для выбранных технологий данных.

  • Обеспечьте поддержку необходимых языков и возможностей пакета SDK. Не все возможности доступны для каждого языка или пакета SDK одинаково.

Согласованность и управление

• Внедрение структуры платформы данных с несколькими регионами, поддерживающей подход к активному или активному развертыванию рабочей нагрузки. Дополнительные сведения см. в разделе "Глобальное распределение".

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

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

  • Рассмотрите бизнес-требования к разрешению конфликтов, если один и тот же элемент данных изменяется в двух отдельных репликах записи, прежде чем можно будет реплицировать любое изменение и таким образом создать конфликт.
    • Используйте стандартные политики разрешения конфликтов, такие как "Побеждает последний", где это возможно
      • Если требуется настраиваемая стратегия с пользовательской логикой, убедитесь, что методы CI/CD DevOps применяются для управления пользовательской логикой.

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

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

  • Убедитесь, что процессы непрерывной доставки рассматривают нагрузочное тестирование по известным тестам производительности.

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

Дополнительные ссылки

Дополнительные рекомендации по платформе данных доступны в руководстве по архитектуре приложений Azure.

• Дерево принятия решений хранилища данных Azure
• Критерии выбора хранилища данных
• Нереляционные хранилища данных
• Реляционные хранилища данных OLTP

Глобально распределенное хранилище данных записи в нескольких регионах

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

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

Рекомендации по проектированию

Azure Cosmos DB

Azure Cosmos DB — это рекомендуемое хранилище данных для критически важных рабочих нагрузок, требующих глобально распределенной платформы записи данных в нескольких регионах. Она изначально обеспечивает многорегиональные операции записи и настраиваемую согласованность, SLA доступности операций чтения и записи на уровне 99,999 % при настройке нескольких регионов с возможностью записи, автоматическое переключение при сбое и избыточность между зонами доступности. Эти возможности напрямую поддерживают модель активного и активного развертывания, требующую критически важных рабочих нагрузок. Полный набор функций, руководство по настройке и рекомендации см. в руководстве по службе Cosmos DB.

Ключевые критически важные вопросы:

• Конфигурация записи в несколько регионов связана со значительными затратами, поскольку RU/s выделяются и тарифицируются отдельно для каждого региона. Два региона записи стоят в 2 раза дороже, три — в 3 раза дороже и так далее. Определение приоритета операций записи в нескольких регионах только для сценариев рабочей нагрузки, требующих максимальной надежности.
• В конфигурации записи в нескольких регионах могут возникать конфликты обновлений. Azure Cosmos DB поддерживает политики разрешения конфликтов по принципу «последняя запись побеждает» (по умолчанию), а также пользовательские политики разрешения конфликтов.
• Модель данных и стратегия секционирования между логическими и физическими секциями играет важную роль в достижении оптимальной производительности и доступности.
• Пропускная способность автомасштабирования защищает от ошибок регулирования путем автоматического масштабирования, что важно для непредсказуемых критически важных рабочих нагрузок.
• Режим непрерывного резервного копирования позволяет выполнять самостоятельное восстановление на определённый момент времени (PITR) с точностью до одной секунды и со сроком хранения до 30 дней, что делает его предпочтительным по сравнению с периодическим резервным копированием для критически важных сценариев.

Рекомендации по проектированию

Azure Cosmos DB

• Используйте Azure Cosmos DB в качестве основной платформы данных, где это допускается требованиями.

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

  • Настройте приложение, чтобы установить приоритет использования локальной реплики Azure Cosmos DB для записи и чтения с целью оптимизации нагрузки на приложение, производительности и регионального потребления R/сек.
  • Конфигурация записи с несколькими регионами имеет значительные затраты и должна быть приоритетна только для сценариев рабочей нагрузки, требующих максимальной надежности.

• Для сценариев с менее критичной рабочей нагрузкой следует отдавать приоритет использованию конфигурации с записью в одном регионе (при использовании Зоны доступности) и глобально распределёнными репликами чтения.

  • Настройте приложение для использования локальной реплики чтения Azure Cosmos DB для оптимизации производительности чтения.

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

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

• Настройте Azure Cosmos DB с избыточностью зоны доступности (AZ) во всех регионах развертывания с поддержкой AZ, чтобы обеспечить устойчивость к сбоям зоны в пределах региона.

Соглашение об уровне обслуживания Azure Cosmos DB вычисляется путем усреднения неудачных запросов, которые могут не совпадать напрямую с бюджетом ошибок уровня надежности 99,999%. При проектировании на 99.999% SLO крайне важно предусмотреть недоступность записей в одном или нескольких регионах Azure Cosmos DB, обеспечив наличие резервного хранилища, чтобы в случае сбоя, например, с использованием сохраняемой очереди сообщений, обеспечить возможность последующего воспроизведения.

• При использовании AKS в качестве вычислительной платформы: для рабочих нагрузок с большим количеством запросов выбирайте SKU узла AKS с включённой функцией accelerated networking, чтобы уменьшить задержку и колебания загрузки ЦП.

• Для развертываний одного региона записи настоятельно рекомендуется настроить Azure Cosmos DB для отработки отказа, управляемой службой.

• Управление уровнем загрузки через асинхронный неблокирующий обмен сообщениями в системных потоках, которые записывают обновления в Azure Cosmos DB.

  • Рассмотрим такие шаблоны, как разделение команд и ответственности запросов и сортировка событий с помощью Служебная шина Azure или Центры событий Azure.

Технологии реляционных данных

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

Для критически важных рабочих нагрузок выгодно использовать полиглотное хранение данных: применяйте оптимальное хранилище данных для каждого сценария нагрузки, вместо того чтобы пытаться обрабатывать все данные с помощью одной технологии. Azure Cosmos DB обрабатывает глобально распределенные операции записи, а реляционные базы данных, такие как База данных SQL Azure и База данных Azure для PostgreSQL, служат сценариям с строго реляционными моделями, сложными транзакциями или нормативными ограничениями, требующими гарантий ACID.

Подробные инструкции по настройке База данных SQL Azure см. в руководстве по службе базы данных SQL.

Подробные инструкции по настройке База данных Azure для PostgreSQL см. в руководстве по службе Database for PostgreSQL.

Рекомендации по проектированию

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

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

• База данных SQL Azure предоставляет группы автоматического переключения при отказе, георепликацию максимум между четырьмя регионами, избыточность на уровне зон доступности и SLA на уровне 99,995 % для уровней Business Critical. Эти возможности позволяют использовать критически важные сценарии, в которых существуют реляционные требования. Полные возможности см. в руководстве по службе базы данных SQL.

• База данных Azure для PostgreSQL гибкий сервер с эластичными кластерами (Citus) обеспечивает динамическую масштабируемость с помощью сегментирования. Используйте гибкий сервер для критически важных рабочих нагрузок, требующих поддержки зоны доступности, и гарантии обслуживания 99.95%. Полные возможности см. в руководстве по службе Database for PostgreSQL.

Рекомендации по проектированию

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

  • Сегментирование не подходит для всех сценариев приложения, поэтому требуется контекстная оценка.

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

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

Кэширование для данных горячего уровня

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

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

Рекомендации по проектированию

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

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

• В некоторых сценариях рабочей нагрузки кэширование в памяти можно реализовать в самой платформе приложений.

Управляемый Redis в Azure и Кэш Azure для Redis

• Кэш Azure для Redis уходит в отставку. Для новых проектов используйте Azure Managed Redis.

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

Рекомендации по проектированию

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

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

  • При изменении резервных данных рассмотрите возможность истечения срока действия элементов кэша.

Управляемый Redis в Azure и Кэш Azure для Redis

• Используйте Azure Managed Redis для новых развертываний кэша.

• Для существующих экземпляров Кэш Azure для Redis воспользуйтесь рекомендациями по прекращению поддержки.

• Разверните экземпляры реплики с использованием георепликации в активной конфигурации во всех регионах рассматриваемого развертывания.

• Убедитесь, что экземпляры реплик развертываются в зонах доступности в каждом из рассматриваемых регионов Azure.

• Используйте Azure Monitor для оценки экземпляров кэша.

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

Аналитические сценарии

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

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

Текущее руководство по Azure Cosmos DB рекомендует использовать Azure Cosmos DB Mirroring for Microsoft Fabric для новых проектов аналитики без ETL вместо Synapse Link.

Рекомендации по проектированию

• Традиционно крупномасштабные аналитические сценарии упрощаются путем извлечения данных в отдельную платформу данных, оптимизированную для последующих аналитических запросов.
  • Конвейеры извлечения, преобразования и загрузки (ETL) используют пропускную способность и могут повлиять на производительность транзакционной рабочей нагрузки.
  • Выполнение конвейеров ETL нечасто для снижения пропускной способности и воздействия на производительность приведет к тому, что аналитические данные будут менее актуальными.
  • Затраты на разработку и обслуживание конвейеров ETL увеличиваются, так как преобразования данных становятся более сложными.
    • Например, если исходные данные часто изменяются или удаляются, конвейеры ETL должны учитывать эти изменения в целевых данных для аналитических запросов с помощью аддитивного или версионного подхода, дампа и перезагрузки или внесения изменений непосредственно в аналитические данные. Каждый из этих подходов будет иметь производное влияние, например повторное создание или обновление индекса.

Azure Cosmos DB

• Аналитические запросы, выполняемые в транзакционных данных Azure Cosmos DB, обычно агрегируются между секциями по большим объемам данных, потребляя значительную пропускную способность единиц запросов (ЕЗ), что может повлиять на производительность окружающих транзакционных рабочих нагрузок.

• Канал изменений Azure Cosmos DB также можно использовать для обслуживания отдельного дополнительного хранилища данных для аналитических сценариев.

Рекомендации по проектированию

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

• Используйте Azure Cosmos DB Mirroring for Microsoft Fabric для новых аналитических проектов без ETL.

• Используйте канал изменений Azure Cosmos DB только для простых аналитических сценариев.

Следующий шаг

Ознакомьтесь с рекомендациями по работе с сетями.