Поделиться через


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

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

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

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

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

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

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

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

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

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

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

  • Метод доступа к данным: Язык прямых запросов (например, SQL или Gremlin), REST API, пакет SDK или сочетание. Некоторые платформы ограничивают доступ к закрытому уровню API, который влияет на гибкость запросов и параметры интеграции.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Будут ли рабочие нагрузки использовать SQL Server? В Azure рабочие нагрузки могут выполняться на базе IaaS SQL Server on Azure Virtual Machines или на базе paaS SQL Database hosted service. Выбор зависит от того, хотите ли вы управлять базой данных, применять исправления и создавать резервные копии или делегировать эти операции Azure. В некоторых сценариях требуется SQL Server, размещенный в IaaS, из-за требований к функциональности. Дополнительные сведения см. в разделе Выбор подходящего варианта SQL Server в Azure.

  • Включает ли ваша Azure-решение платформу Power Platform или нагрузки Dynamics 365?Microsoft Dataverse — это платформа данных SaaS для Power Platform и бизнес-приложений Dynamics 365. В отличие от служб баз данных PaaS и IaaS в этой статье, Dataverse абстрагирует всю инфраструктуру и управление подсистемой. Он предоставляет реляционное хранилище данных со встроенными бизнес-правилами, детализацией безопасности (на основе ролей, уровня строк и уровня столбцов) и стандартизованной Common Data Model. Клиентские приложения в основном получают доступ к данным через API Dataverse, а не прямые подключения SQL к базовому ядру СУБД, что ограничивает гибкость запросов и пропускную способность по сравнению с Azure собственными службами баз данных. Оцените dataverse для частей решения, которые используют Power Apps, Power Automate, Power Pages или Dynamics 365. Для компонентов одного решения, требующего обработки высокой пропускной способности, сложных аналитических запросов или прямого управления базой данных, используйте службу базы данных Azure наряду с Dataverse. Вы можете синхронизировать данные между службами Dataverse и Azure с помощью таких средств, как Azure Synapse Link для Dataverse и Microsoft Fabric.

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

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

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

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

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

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

Замечание

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

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

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

Ваша цель Рекомендуемая служба базы данных
Создавайте приложения, масштабируемые с помощью управляемой и интеллектуальной базы данных SQL в облаке. База данных SQL
Модернизируйте приложения SQL Server, используя управляемый и обновлённый экземпляр базы данных SQL в облачной среде. Azure SQL Managed Instance
Переносите ваши SQL-нагрузки на Azure, сохраняя полную совместимость с SQL Server и доступ на уровне операционной системы. SQL Server on Virtual Machines
Создавайте масштабируемые управляемые корпоративные приложения на базе PostgreSQL с открытым исходным кодом, масштабируйте одноузловую PostgreSQL с высокой производительностью или переносите рабочие нагрузки PostgreSQL и Oracle в облако. Azure Database for PostgreSQL
Обеспечение высокого уровня доступности и эластичного масштабирования для мобильных и веб-приложений с открытым исходным кодом с помощью управляемой службы базы данных MySQL или переноса рабочих нагрузок MySQL в облако. Azure Database for MySQL
Создавайте приложения, которые гарантируют низкую задержку и высокий уровень доступности в любом масштабе, или переносите рабочие нагрузки Cassandra, Gremlin и других систем NoSQL в облако. Azure Cosmos DB
Перенос рабочих нагрузок MongoDB в облако или создание гибридных и многооблачных приложений с высокой емкостью вертикального и горизонтального масштабирования Azure DocumentDB
Модернизируйте существующие кластеры и приложения данных Cassandra и получите гибкость с помощью службы управляемого экземпляра. Azure Managed Instance для Apache Cassandra
Поставляйте быстрые и масштабируемые приложения с использованием хранилища данных, совместимого с открытым исходным кодом. Azure Managed Redis
Создание или расширение бизнес-приложений с помощью Power Platform или Dynamics 365 с встроенным моделированием данных, бизнес-логикой и безопасностью. Microsoft Dataverse

Сравнение функций базы данных и платформы данных

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

Функция База данных SQL SQL Managed Instance База данных Azure для PostgreSQL Azure Database for MySQL Azure Managed Instance для Apache Cassandra Azure Cosmos DB Azure Управляемый Redis Azure DocumentDB Microsoft Dataverse
Тип базы данных Реляционная Реляционная Реляционная Реляционная NoSQL NoSQL В памяти NoSQL Реляционный (управляемый)
Модель данных Реляционная Реляционная Реляционная Реляционная Широкий столбец Мультимодель: документ, ширококолонная, ключ-значение, граф ключ-значение Документ Реляционная
Распределенные многопримарные записи нет нет нет нет Да Да Да Да нет
Поддержка подключения к виртуальной сети Конечная точка службы виртуальной сети Реализация собственной виртуальной сети Внедрение виртуальной сети (только для Flexible Server) Внедрение виртуальной сети (только для Flexible Server) Реализация собственной виртуальной сети Конечная точка службы виртуальной сети Конечная точка службы виртуальной сети Конечная точка службы виртуальной сети Поддержка управляемой виртуальной сети

Замечание

служба Azure Private Link упрощает проектирование сети, позволяя Azure службам данных обмениваться данными через частные сети. Большинство служб баз данных Azure, перечисленных в этой таблице, поддерживают Azure Private Link через private endpoints. Для служб баз данных управляемого экземпляра эти экземпляры развертываются в виртуальных сетях, поэтому для них не нужно развертывать частные конечные точки. Microsoft Dataverse размещается в Power Platform, а не в качестве ресурса Azure, а его виртуальная сеть и частные параметры подключения описаны в разделе Мангедная поддержка виртуальной сети для Power Platform.

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

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

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

Microsoft Dataverse среды развертываются в географической области Power Platform (например, США, Европе или Австралии), а не в определенной области Azure. Данные остаются в выбранном географическом регионе, но вы не управляете тем, какой регион Azure в пределах этого географического региона размещает вашу среду. Учитывайте грубую гранулярность региона при планировании совместного размещения с другими службами Azure или при наличии определенной задержки или требований к размещению данных.

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

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

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

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

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

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

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

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

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

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

Политики следует применять к ресурсам, группам ресурсов, подпискам и группам управления в облаке.

Microsoft Dataverse среды управляются отдельно с помощью центра администрирования Power Platform, а не через Azure Policy. Используйте управляемые среды и политики предотвращения потери данных для управления созданием среды, использованием соединителя и перемещением данных. Если ваше решение охватывает как базы данных, поддерживаемые Azure, так и Dataverse, планируйте управление для каждой из контрольных плоскостей.

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

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