Миграция из режима диспетчера карт сегментов эластичных запросов

Применимо к: База данных SQL Azure

Эластичные запросы в режиме диспетчера карт сегментов (горизонтальное секционирование), используя EXTERNAL DATA SOURCE тип SHARD_MAP_MANAGER, достигают конца поддержки 31 марта 2027 г. После этой даты существующие рабочие нагрузки будут продолжать функционировать, но больше не будут получать поддержку, а создание новых внешних источников данных типа SHARD_MAP_MANAGER больше не будет возможным. В этой статье содержатся параметры миграции из режима управления общей картой Elastic Query.

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

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

Microsoft Fabric

Лучше всего подходит для: сценариев OLAP (интерактивная аналитическая обработка данных) и создания отчетов.

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

Дополнительные сведения см. в документации по Microsoft Fabric.

Зеркалирование SQL в Fabric

Лучше всего подходит для: Создание отчетов и аналитика по централизованным данным.

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

Дополнительные сведения см. в статье о зеркальных базах данных Microsoft Fabric из базы данных SQL Azure.

Подход на основе ETL (например, использование фабрики данных Azure)

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

Использование конвейеров ETL, таких как Фабрика данных Azure (ADF), обеспечивает гибкое, запланированное перемещение и преобразование данных. Этот подход хорошо подходит для пакетной обработки, но может привести к задержкам в свежести данных. Учитывайте затраты на обслуживание и масштабируемость заданий ETL по мере увеличения объема данных.

Дополнительные сведения см. в документации по Фабрике данных Azure или фабрике данных в Microsoft Fabric.

Полностью перенести плоскость данных в Fabric OneLake

Лучше всего: Централизованное управление данными с помощью единой аналитики.

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

Дополнительные сведения см. в документации по OneLake.

Гипермасштабирование базы данных SQL Azure

Лучше всего подходит для: Рабочих нагрузок, в которых шардинг был реализован из-за ограничений хранилища, которые гипермасштабирование преодолевает сегодня.

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

Дополнительные сведения см. на уровне служб "Гипермасштабирование базы данных SQL Azure".

Эластичные задания

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

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

Дополнительные сведения см. в разделе "Эластичные задания" в База данных SQL Azure.

Управляемый экземпляр SQL Azure

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

Управляемый экземпляр SQL Azure по умолчанию поддерживает запросы с трикомпонентными именами и связанные серверы. Если вы используете эластичные запросы для запросов типа "точка — точка", управляемый экземпляр SQL является объектом естественной миграции. Рассмотрим настройку сети, конфигурации безопасности и затраты на лицензирование. Убедитесь, что рабочая нагрузка соответствует ограничениям производительности и масштабируемости управляемого экземпляра SQL.

Дополнительные сведения см. в статье "Что такое Управляемый экземпляр SQL Azure"?

Настраиваемый запрос вентилятора и уровень агрегирования результатов

Лучше всего: Сохранение существующей архитектуры базы данных SQL Azure с максимальной гибкостью.

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

Связанный контент

  • Last updated on