#azure-sql-database #replication
Вопрос:
Фон
Я разрабатываю механизм прогнозирования (временные ряды) для различных целей. Модули обработки, моделирования и прогнозирования написаны на Python, и в настоящее время данные хранятся в базе данных SQL Azure. В настоящее время база данных имеет уровень обслуживания общего назначения (на основе vCore), уровень подготовленных вычислений и конфигурацию hw поколения 5 (12 VCORE). Я приближаюсь к пределу максимального объема хранилища (около 3 ТБ), но, поскольку я ежедневно читаю почти всю базу данных (только модели холодного запуска), я не вижу других вариантов, кроме увеличения объема хранилища. Об усечении части исторических данных не может быть и речи.
Проблема
При 12 vCores максимальное хранилище составляет около 3 ТБ, и увеличение vCores для обеспечения максимального объема хранилища около 4 ТБ нецелесообразно с точки зрения $(тем более, что узким местом является хранилище, а не вычисления). Я немного прочитал об альтернативных службах / уровнях на платформе Azure и вижу, что гипермасштабирование может решить мою проблему: я могу сохранить нетронутыми виртуальные хранилища и иметь хранилище объемом до 100 ТБ. Конфигурация с нулевыми вторичными репликами (при прочих равных условиях) окажется в том же диапазоне$, что и раньше (см. «Фон»). У меня складывается впечатление, что вторичные реплики (узлы только для чтения) занимают центральное место в архитектуре гипермасштабирования, поэтому я не уверен, что такая описанная настройка с нулевыми вторичными репликами является злоупотреблением / неправильным использованием. Например, даст ли она такую же производительность или я могу ожидать снижения производительности (даже с той же конфигурацией vCore)? Будет ли основной узел чтения / записи в основном напоминать узел без гипермасштабирования? Другие аспекты, о которых я должен подумать? Добавление вторичной реплики (или нескольких) может быть актуально в будущем (например, в сочетании с уменьшением vCores), но с точки зрения $это не вариант.
Microsoft заявляет, что «Возможность перехода с гипермасштабирования на другой уровень обслуживания не поддерживается» (действительно?), Поэтому я хотел бы уточнить это, чтобы избежать полуавтоматической миграции данных (и дельта-миграции) и наличия двух экземпляров рядом, если шайт попадет в вентилятор. Учитывая масштабы такой реконструкции и систему прогнозирования в целом, я считаю, что нецелесообразно проводить небольшое / полномасштабное тестирование заранее, чтобы получить репрезентативные показатели. Если есть что-то еще, о чем я должен подумать (связанное или полу-связанное), не стесняйтесь указывать мне в правильном направлении.
Ответ №1:
Поскольку уровень обслуживания гипермасштабирования является недавно добавленным уровнем обслуживания в базе данных SQL Azure, было бы трудно получить однозначный ответ на ваш вопрос.
Это правда, что он обеспечивает размер базы данных до 100 ТБ, но прелесть в том, что он будет взимать плату только за ту емкость, которую вы используете.
Уровень услуг гипермасштабирования устраняет многие практические ограничения, традиционно наблюдаемые в облачных базах данных. Там, где большинство других баз данных ограничены ресурсами, доступными в одном узле, базы данных на уровне услуг гипермасштабирования не имеют таких ограничений. Благодаря гибкой архитектуре хранилища объем хранилища увеличивается по мере необходимости. На самом деле, базы данных с гипермасштабированием не создаются с определенным максимальным размером. База данных гипермасштабирования растет по мере необходимости — и вам выставляется счет только за используемую вами емкость. Для рабочих нагрузок, требующих интенсивного чтения, уровень обслуживания гипермасштабирования обеспечивает быстрое масштабирование, предоставляя дополнительные реплики по мере необходимости для разгрузки рабочих нагрузок чтения.
Вы можете иметь первичную и вторичную реплики на уровне гипермасштабируемого сервиса.
- Первичная реплика выполняет операции чтения и записи
- Вторичная реплика обеспечивает масштабирование считывания, высокую доступность и георепликацию
Вторичные реплики всегда доступны только для чтения и могут быть трех различных типов:
- Реплика высокой доступности (рекомендуется)
- Именованная реплика (в предварительном просмотре не гарантируется SLA)
- Геореплика (в предварительном просмотре, без гарантированного SLA)
Вам следует рассмотреть уровень гипермасштабируемого обслуживания, потому что:
- вам нужно больше, чем 4 ТБ
- требуется быстрое вертикальное и горизонтальное масштабирование вычислений, высокая производительность, мгновенное резервное копирование и быстрое восстановление базы данных
Примечание. Пользователи могут изменять общее количество реплик высокой доступности от 0 до 4 в зависимости от необходимости.
Вы можете проверить модель ценообразования в гипермасштабе здесь.
Учитывая вышеизложенное, Гипермасштабирование-это хорошее, если не лучшее, решение для ваших требований.
Эти две ссылки определенно помогут вам принять решение. Уровень обслуживания гипермасштабирования, вторичные реплики гипермасштабирования
Комментарии:
1. Спасибо, @UtkarshPal-MT! Я уже немного прочитал о материале, на который вы ссылаетесь, но это не дает мне полной уверенности в том, что это несложно. Так, короче, меня прям вопрос таков: у меня создается впечатление, что вторичные реплики (только чтение узлы) занимают центральное место в широкомасштабных архитектуры, поэтому я не уверен, если такой наметили установить с нуля вторичных реплик является злоупотребление / злоупотребление. Например. это даст такую же производительность, или я могу ожидать снижения производительности (даже с тем же точное config и при прочих равных условиях)?
2. Вторичная реплика важна, если вам нужна высокая доступность. Как указано в документах, вторичная реплика обеспечивает масштабирование чтения, высокую доступность и георепликацию. Это означает, что если в регионе, где физически расположена ваша основная база данных, произошло какое-либо нарушение электроснабжения или стихийное бедствие, ваше приложение перейдет на новую вторичную реплику, чтобы ваше приложение продолжало работать. Следовательно, настройка вторичной реплики важна и рекомендуется.
3. Кроме того, вторичная реплика не означает увеличения vCore. Он просто копирует вашу основную базу данных в другое географическое местоположение с той же конфигурацией для обеспечения высокой доступности.
4. Я понимаю, что первичная и вторичная реплики будут иметь одинаковую конфигурацию hw. Я также понимаю, что репликация может обеспечить горизонтальное масштабирование, более высокую доступность (99,95% вместо 99,9% в соответствии с соглашением об уровне обслуживания) и георепликацию (в предварительном просмотре ). Я предполагаю, что «больше-это больше» (следовательно, «вторичная копия важна и рекомендуется» ), но в моем случае $ также является ограничением. Я имею в виду… если стихийное бедствие и т. Д. обрушится на мой регион, гео-восстановление полностью приемлемо.
5. Спасибо за помощь, кстати, но я чувствую, что мой вопрос не ответ: я не уверен, если такой наметили установить с нуля вторичных реплик является злоупотребление / злоупотребление. Например. это даст такую же производительность, или я могу ожидать снижения производительности (даже с тем же точное config и при прочих равных условиях)?
Ответ №2:
Я один из руководителей команды Azure SQL DB. Я вижу, что UtkarshPal-MT уже дал вам исчерпывающий ответ, поэтому я включаюсь, чтобы завершить картину. Гипермасштабируемая база данных SQL Azure предлагает различные типы вторичных реплик. Реплики, которые могут помочь получить более высокий уровень обслуживания, называются репликами высокой доступности. Вы можете использовать 0 реплик без каких-либо проблем. Что произойдет, так это то, что если первичные реплики по какой-либо причине недоступны, нам нужно запустить новую (вычислительную) реплику с нуля (поскольку реплики HA недоступны), так что это может занять некоторое время (обычно минуты), что означает, что ваша служба не будет доступна в течение этого времени. Наличие реплики HA значительно сокращает время, в течение которого база данных недоступна.
Вы можете прочитать все подробности здесь:
https://docs.microsoft.com/en-us/azure/azure-sql/database/service-tier-hyperscale-replicas?tabs=tsql
SLA определены здесь:
https://www.azure.cn/en-us/support/sla/sql-data/
Что касается производительности: если вы специально не используете вторичные реплики также для разгрузки рабочей нагрузки, доступной только для чтения, отсутствие реплики HA не повлияет на производительность
Комментарии:
1. Большое спасибо, @mauridb! Я думаю, что несколько минут отсутствия бд допустимы. В конце концов, 99,9% минимальной доступности довольно прилично. Я реализовал логику повторных попыток для обработки сбоев такого размера. Еще раз большое спасибо вам за предоставление дополнительной информации.
2. Если кто-то из будущего найдет эту тему, то, возможно, также стоит проверить, были ли здесь какие-либо полезные ответы: docs.microsoft.com/en-us/answers/questions/609075/…