Подготовка к выбору хранилища данных в Azure

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

Определение требований к службам данных

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

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

Функциональные требования

Рассмотрим характер данных и способ его использования:

• Формат данных: Структурированные (таблицы), полуструктурированные (JSON, XML и ключ-значение) или неструктурированные (изображения и документы)

• Цель: Интерактивная обработка транзакций (OLTP) для транзакционных данных или оперативной аналитической обработки (OLAP) для сложного, нерегламентированного анализа данных

• Потребности поиска: Возможность индексирования или полнотекстового поиска

• Специализированный: Векторные хранилища для данных с высокой размерностью или графовые базы данных для высокосвязанных данных

• Связи данных: Соединения, обход графа или иерархические структуры

• Модель согласованности: Строгой, конечной или настраиваемой согласованности

• Гибкость схемы: Схема при записи (жесткая) или схема при чтении (гибкая)

• Требования к параллелизму: Оптимистичное и пессимистичное блокирование и сценарии с высокой интенсивностью записи

• Жизненный цикл данных: Кратковременное и долгосрочное архивирование, а также горячие и холодные данные

• Перемещение данных: Требования к извлечению, преобразованию и загрузке (ETL); требования к извлечению, загрузке и преобразованию (ELT); и интеграция с конвейерами

Нефункциональные требования

Оцените ожидания производительности и масштабируемости:

• Задержка и пропускная способность: Режим реального времени и пакетная обработка
• Масштабируемость: Вертикальное и горизонтальное масштабирование и глобальное распределение
• Надежность и доступность: Требования соглашения об уровне обслуживания (SLA) и стратегии отказоустойчивости
• Ограничения: Размер хранилища, ограничения пропускной способности и ограничения секционирования

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

Фактор операционной нагрузки и бюджета:

• Управляемое и локальное: Компромиссы платформы как услуги (PaaS) и инфраструктуры как услуги (IaaS)
• Доступность региона: Требования к месту расположения данных и соответствия требованиям
• Оптимизация затрат: Многоуровневые хранилища, секционирование и кэширование
• Лицензирование и переносимость: Зависимость от поставщика и совместимость с открытым исходным кодом

Безопасность и управление

Убедитесь в соответствии с политиками организации:

• Шифрование: Шифрование в состоянии покоя и в процессе передачи
• Проверка подлинности и авторизация: Интеграция доступа на основе ролей и идентификации
• Аудит и мониторинг: Журналы действий, оповещения и диагностика
• Сети: Частные конечные точки, правила брандмауэра и интеграция виртуальной сети

Готовность DevOps и команды

Оцените способность вашей команды поддерживать и развивать решение:

• Навыки: Знакомство с языками запросов, SDK и инструментами
• Поддержка клиентов: Языковые привязки и доступность драйверов
• Интеграция инструментов: Конвейеры непрерывной интеграции и непрерывной доставки (CI/CD) и средства наблюдения

Ключевые вопросы

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

• Какой уровень контроля вам нужен над операционной системой и движком базы данных? В некоторых сценариях требуется высокий уровень контроля над конфигурацией программного обеспечения и хост-серверами для рабочих нагрузок базы данных. В этих сценариях можно развернуть пользовательские виртуальные машины IaaS для полного управления развертыванием и настройкой служб данных. Возможно, вам не нужен этот уровень управления, но, возможно, вы не готовы перейти к полному решению PaaS. В этом случае управляемый экземпляр может обеспечить более высокую совместимость с локальным ядром СУБД, обеспечивая преимущества управляемой платформы.

• Будут ли рабочие нагрузки использовать технологию реляционной базы данных? Если это так, выберите базу данных SQL Azure, базу данных Azure для MySQL и Базуданных Azure для PostgreSQL, которая предоставляет возможности управляемой базы данных PaaS.

• Будут ли ваши рабочие процессы использовать SQL Server? В Azure рабочие нагрузки могут выполняться на сервере SQL Server на основе IaaS на виртуальных машинах Azure или в размещенной службе базы данных SQL PaaS. Выбор зависит от того, хотите ли вы управлять базой данных, применять исправления и создавать резервные копии или делегировать эти операции в Azure. В некоторых сценариях требуется sql Server, размещенная на IaaS, из-за требований к возможностям. Дополнительные сведения см. в разделе "Выбор подходящего варианта SQL Server" в Azure.

• Будут ли ваши нагрузки использовать хранилище данных типа ключ-значение?Azure Managed Redis — это управляемое хранилище данных в памяти на основе последней версии Redis Enterprise. Она обеспечивает низкую задержку и высокую пропускную способность. Azure Cosmos DB также предоставляет возможности хранилища ключевых значений.

• Будут ли ваши рабочие процессы использовать данные документа или графа?Azure Cosmos DB — это служба многомодельной базы данных, которая поддерживает различные типы данных и API. Он также предоставляет возможности базы данных документов и графов. Azure DocumentDB — это полностью управляемая, совместимая с MongoDB служба базы данных с открытым кодом.

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

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

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

• Будут ли рабочие нагрузки использовать данные временных рядов?Azure Data Explorer — это управляемая, высокопроизводительная платформа аналитики больших данных, которая анализирует большие объемы данных практически в реальном времени.

Распространенные сценарии базы данных

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

Сравнение функций базы данных

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

Региональная доступность

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

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

Дополнительные сведения о глобальной инфраструктуре Azure см. в географических регионах Azure.

Требования к месту расположения данных и соответствия требованиям

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

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

Дополнительные сведения об этих требованиях см. в статье "Обеспечение соответствия требованиям к месту размещения данных и безопасности с помощью Azure".

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

Установка элементов управления для служб баз данных

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

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

Например, пользователи могут ограничить создание только ресурсов базы данных SQL. Используйте политики для управления параметрами, которые пользователи могут выбирать при создании ресурсов. Например, можно ограничить номера SKU базы данных SQL, которые пользователи могут подготавливать, разрешая устанавливать только определенные версии SQL Server на виртуальной машине IaaS. Дополнительные сведения см. в встроенных определениях политик политики Azure.

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

Дальнейшие шаги

• Общие сведения о моделях данных

Используйте следующие статьи, чтобы выбрать специализированное хранилище данных:

• Выбор технологии хранилища больших данных в Azure
• Выбор хранилища данных поиска в Azure
• Выбор службы Azure для поиска векторов