Realme 10 Pro+ 5G: изогнутый дисплей и немного дороговато. Но стоит ли телефон того?

Lenovo Yoga 9 14IAP7 Обзор: как ноутбук-трансформер, он преодолевает весь негатив

Dynamic Island на iPhone 14 Pro становится полезнее; Должен ли он быть на всех телефонах?

Lenovo Legion 5i Pro (2022 г.) Обзор: «Стильный» игровой ноутбук

Обзор Boat Stone 190 Superman DC Edition: колонка для начинающих с оттенком стиля

Актуальные истории

4 основные функции убедили меня купить Nothing Phone 1; Я ни о чем не жалею, кроме ONE

10 самых больших функций, которые пользователи WhatsApp получили в 2022 году: реакции от аватаров до эмодзи и многое другое

6 лучших космических фотографий, которые потрясли мир в 2022 году

Углеродный след Apple iPhone 14 за весь срок службы? Просто проверьте это

iPhone 14 снова спасает жизнь, обнаружение аварий спасает жертв автокатастроф из каньона

PlayStation Plus, январь 2023 г. Утечка игр: играйте в Fallout 76, Fallen Order и другие БЕСПЛАТНО

Не пропустите розыгрыш Minecraft! Получите бесплатные карты, скины и многое другое таким образом

Киберспорт рассматривается как путь к разнообразию карьеры STEM

Производитель Fortnite заплатит 520 миллионов долларов за конфиденциальность и злоупотребления электронной коммерцией

Получите бесплатную игру из магазина Epic Games уже сегодня! Wolfenstein: The New Order в продаже

Часто задаваемые вопросы об автоматически масштабируемой пропускной способности в Azure Cosmos DB

Редактировать

Твиттер LinkedIn Фейсбук Электронное письмо

ПРИМЕНЯЕТСЯ К: NoSQL MongoDB Кассандра Гремлин Таблица

Благодаря автомасштабированию подготовленной пропускной способности Azure Cosmos DB будет автоматически управлять количеством ЕЗ/с вашей базы данных или контейнера и масштабировать их в зависимости от использования. В этой статье приведены ответы на часто задаваемые вопросы об автомасштабировании.

«Автомасштабирование» или «автомасштабирование подготовленной пропускной способности» — это обновленное название функции, ранее известной как «автопилот». В текущем выпуске автомасштабирования мы добавили новые функции, в том числе возможность устанавливать собственные максимальные ЕЗ/с и программную поддержку.

Что произойдет с базами данных или контейнерами, созданными в предыдущей модели уровня автопилота?

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

Например, если ранее вы выбрали уровень с масштабированием от 400 до 4000 ЕЗ/с, для базы данных или контейнера теперь будет отображаться максимальная скорость 4000 ЕЗ/с, которая масштабируется от 400 до 4000 ЕЗ/с. . Отсюда вы можете изменить максимальное количество ЕЗ/с на пользовательское значение в соответствии с вашей рабочей нагрузкой.

Какова точка входа ЕЗ/с для автомасштабирования?

Начиная с апреля 2022 г., вы можете установить автомасштабирование с максимальным числом единиц запросов в секунду от 1000 единиц запросов в секунду (масштабируется от 100 единиц запросов в секунду до 1000 единиц запросов в секунду). Это также означает, что вы можете установить диапазоны шкалы от 200 до 2000 RU/с и от 300 до 3000 RU/с. Раньше точка входа была 400 — 4000 RU/s. Эта конфигурация рекомендуется для рабочих нагрузок с низкими требованиями к пропускной способности, но все же может масштабироваться до максимального числа ЕЗ/с.

При автомасштабировании система масштабирует пропускную способность (ЕЗ/с) T вверх или вниз в пределах 0,1 * Tmax и Tmax в зависимости от входящего трафика. Поскольку масштабирование является автоматическим и мгновенным, в любой момент времени вы можете потреблять до подготовленного Tmax без задержки.

Используйте метрики Azure Monitor для мониторинга как предоставленного максимального числа ЕЗ/с при автоматическом масштабировании, так и текущей пропускной способности (ЕЗ/с), до которой масштабируется система.

Каждый час вам будет выставляться счет за максимальную пропускную способность T система масштабируется в течение часа. Если у вашего ресурса не было запросов в течение часа или его масштабирование не превышало 0,1 * Tmax , вам будет выставлен счет как минимум 0,1 * Tmax . Дополнительные сведения см. на странице цен на Azure Cosmos DB.

В учетных записях с одним регионом записи скорость автоматического масштабирования на 100 ЕЗ/с в 1,5 раза превышает скорость стандартной (ручной) выделенной пропускной способности. В своем счете вы увидите существующий стандартный счетчик пропускной способности. Количество этого метра будет умножено на 1,5. Например, если максимальное число ЕЗ/с, до которого система масштабировалась в течение часа, составляло 6000 ЕЗ/с, вам будет выставлен счет 60 * 1,5 = 9. 0 единиц метра за этот час.

В учетных записях с несколькими областями записи скорость автоматического масштабирования на 100 ЕЗ/с такая же, как и скорость для стандартной (ручной) подготовки нескольких областей записи. В вашем счете вы увидите существующий счетчик нескольких областей записи. Так как скорости одинаковы, при использовании автомасштабирования вы увидите то же количество, что и при стандартной пропускной способности.

Да. Когда вы покупаете зарезервированную емкость для учетных записей с одним регионом записи, скидка на резервирование ресурсов автомасштабирования применяется к использованию вашего счетчика в соотношении 1,5 * коэффициент для конкретного региона. Например, если вы хотите использовать зарезервированную емкость для покрытия 10 000 единиц запросов в секунду с автоматическим масштабированием, вам следует запланировать приобретение общей зарезервированной емкости на 15 000 единиц запросов в секунду.

Зарезервированная емкость области с множественной записью работает одинаково для автомасштабирования и стандартной (ручной) выделенной пропускной способности. См. зарезервированную емкость Azure Cosmos DB

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

Да, автомасштабирование поддерживается для всех API: NoSQL, Gremlin, Table, Cassandra и MongoDB.

Да. Максимальное количество ЕЗ/с доступно в каждом регионе, добавленном в учетную запись Azure Cosmos DB.

Как включить автомасштабирование для новых баз данных или контейнеров?

См. эту статью о том, как включить автомасштабирование.

Можно ли включить автомасштабирование для существующей базы данных или контейнера?

Да. Вы также можете переключаться между автоматическим масштабированием и стандартной (ручной) выделенной пропускной способностью по мере необходимости. В настоящее время для всех API можно использовать портал Azure, интерфейс командной строки или PowerShell для выполнения этих операций. По умолчанию вы не можете использовать клиентские пакеты SDK Azure Cosmos DB или шаблон ARM для перехода между ручным и автоматическим масштабированием. Однако вы можете использовать клиентские пакеты SDK или шаблоны ARM для создания новых ресурсов автомасштабирования и изменения максимального числа ЕЗ/с в существующем ресурсе автомасштабирования.

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

Миграция со стандартной (ручной) выделенной пропускной способности на автоматическое масштабирование

Для контейнера используйте следующую формулу для оценки начального максимального количества ЕЗ/с при автоматическом масштабировании: МАКС. Provisioned / 10, хранилище в ГБ * 100) , округленное до ближайших 1000 ЕЗ/с. Фактическое исходное максимальное количество ЕЗ/с для автомасштабирования может различаться в зависимости от конфигурации вашей учетной записи.

Пример 1. Предположим, у вас есть контейнер с пропускной способностью 10 000 ЕЗ/с, выделенной вручную, и хранилищем объемом 25 ГБ. Когда вы включаете автомасштабирование, начальное максимальное число ЕЗ/с при автомасштабировании будет составлять 10 000 ЕЗ/с, которое будет масштабироваться в диапазоне от 1000 до 10 000 ЕЗ/с.

Пример № 2. Предположим, у вас есть контейнер с пропускной способностью 50 000 ЕЗ/с, выделенной вручную, и 2 500 ГБ хранилища. Когда вы включаете автомасштабирование, исходная максимальная скорость автомасштабирования ЕЗ/с будет составлять 250 000 ЕЗ/с, которая будет масштабироваться в диапазоне от 25 000 до 250 000 ЕЗ/с.

Миграция от автоматического масштабирования к стандартной (ручной) выделенной пропускной способности

Первоначальная ручная выделенная пропускная способность будет равна текущему максимальному количеству ЕЗ/с при автомасштабировании.

Пример. Предположим, у вас есть база данных или контейнер с автоматическим масштабированием, максимальная скорость которых составляет 20 000 ЕЗ/с (масштабируется от 2000 до 20 000 ЕЗ/с). При обновлении для использования пропускной способности, подготовленной вручную, начальная пропускная способность будет составлять 20 000 ЕЗ/с.

Есть ли поддержка Azure CLI, PowerShell или Azure Resource Manager для управления базами данных или контейнерами с автомасштабированием?

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

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

Каково разрешенное количество контейнеров на общую базу данных пропускной способности при включенном автомасштабировании?

Azure Cosmos DB применяет максимум 25 контейнеров в общей базе данных пропускной способности, что относится к базам данных с автоматическим масштабированием или стандартной (ручной) пропускной способностью.

Автомасштабирование не влияет на уровень согласованности базы данных. Дополнительную информацию о доступных уровнях согласованности см. в статье об уровнях согласованности.

Предел хранилища в ГБ для каждого максимального количества ЕЗ/с составляет: Макс. ЕЗ/с базы данных или контейнера / 100. Например, если максимальное количество ЕЗ/с составляет 20 000 ЕЗ/с, ресурс может поддерживать 200 ГБ хранилища. Доступные максимальные ЕЗ/с и варианты хранения см. в статье об ограничениях автомасштабирования.

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

Например, если вы начинаете с максимальной скорости ЕЗ/с, равной 50 000 ЕЗ/с (масштабируется от 5000 до 50 000 ЕЗ/с), вы можете хранить до 500 ГБ данных. Если вы превысите 500 ГБ (например, хранилище теперь составляет 600 ГБ), новое максимальное значение ЕЗ/с будет составлять 60 000 ЕЗ/с (масштабируется от 6000 до 60 000 ЕЗ/с).

Можно ли изменить максимальное число ЕЗ/с в базе данных или контейнере?

Да. См. эту статью о том, как изменить максимальное число запросов в секунду. Когда вы изменяете максимальное количество ЕЗ/с, в зависимости от запрошенного значения, это может быть асинхронная операция, выполнение которой может занять некоторое время, до 4–6 часов, в зависимости от выбранных ЕЗ/с. Учить больше.

Когда вы отправляете запрос на увеличение максимального количества ЕЗ/с Tmax , в зависимости от выбранного максимального количества ЕЗ/с, служба выделяет больше ресурсов для поддержки более высокого максимального количества ЕЗ/с. Пока это происходит, ваша существующая рабочая нагрузка и операции не будут затронуты. Система будет продолжать масштабировать вашу базу данных или контейнер между предыдущими 0,1*Tmax и Tmax до тех пор, пока не будет готов новый диапазон масштабирования от 0,1*Tmax_new до Tmax_new .

Когда вы уменьшаете максимальное количество ЕЗ/с, минимальное значение, которое вы можете установить, составляет: МАКС(1000, максимальное максимальное количество ЕЗ/с, когда-либо предоставленное / 10, текущее хранилище в ГБ * 100) , округленное до ближайших 1000 ЕЗ /с.

Пример № 1. Предположим, у вас есть контейнер автомасштабирования с максимальной скоростью 20 000 ЕЗ/с (масштабируется от 2000 до 20 000 ЕЗ/с) и 50 ГБ хранилища. Наименьшее, минимальное значение, которое можно установить для максимального числа ЕЗ/с, составляет: МАКС(1000, 20 000 / 10, 50 * 100 ) = 5000 ЕЗ/с (шкалы от 500 до 5000 ЕЗ/с).

Пример 2. Предположим, у вас есть контейнер автомасштабирования с максимальной скоростью 100 000 ЕЗ/с и хранилищем объемом 100 ГБ. Теперь вы масштабируете максимальное количество запросов в секунду до 150 000 запросов в секунду (масштабируется от 15 000 до 150 000 запросов в секунду). Наименьшее минимальное значение, которое теперь можно установить для максимального числа ЕЗ/с, составляет: МАКС(1000, 150 000 / 10 , 100 * 100) = 15 000 ЕЗ/с (масштабируется от 1500 до 15 000 ЕЗ/с).

Для базы данных с общей пропускной способностью, когда вы уменьшаете максимальное количество ЕЗ/с, минимальное значение, которое вы можете установить, равно: МАКС(1000, максимальное максимальное количество ЕЗ/с, когда-либо предоставленное / 10, текущее хранилище в ГБ * 100, 1000 + (МАКС(количество контейнеров - 25, 0) * 1000)) , округленное до ближайших 1000 RU/с.

Вышеприведенные формулы и примеры относятся к минимальному максимальному автомасштабированию RU/s, которое вы можете установить, и оно отличается от диапазона от 0,1 * Tmax до Tmax , между которым система автоматически выполняет масштабирование. Независимо от максимального числа ЕЗ/с система всегда будет масштабироваться от 0,1 * Tmax до Tmax .

При автомасштабировании операции TTL не влияют на масштабирование ЕЗ/с. Любые ЕЗ, использованные из-за TTL, не являются частью оплачиваемых ЕЗ/с контейнера автомасштабирования.

Например, предположим, что у вас есть контейнер автомасштабирования с 400–4000 ЕЗ/с:

• Час 1: T=0: контейнер не используется (нет TTL или запросов рабочей нагрузки). Оплачиваемая RU/с — 400 RU/с.
• Час 1: T=1: TTL включен.
• Час 1: T=2: Контейнер начинает получать запросы, потребляющие 1000 RU за 1 секунду. Также необходимо выполнить TTL в размере 200 RU. Оплачиваемая ЕЗ/с по-прежнему составляет 1000 ЕЗ/с. Независимо от того, когда возникают TTL, они не повлияют на логику автомасштабирования.

При первом выборе максимального числа ЕЗ/с Azure Cosmos DB подготовит: Макс. ЕЗ/с / 10 000 ЕЗ/с = количество физических разделов. Каждый физический раздел может поддерживать до 10 000 ЕЗ/с и 50 ГБ хранилища. По мере увеличения размера хранилища Azure Cosmos DB будет автоматически разделять разделы, чтобы добавить больше физических разделов для обработки увеличения хранилища, или увеличить максимальное число ЕЗ/с, если хранилище превысит связанный предел.

Максимальное количество ЕЗ/с базы данных или контейнера равномерно распределяется между всеми физическими разделами. Таким образом, общая пропускная способность, до которой может масштабироваться любой отдельный физический раздел, составляет: макс. ЕЗ/с базы данных или контейнера / # физических разделов.

Что произойдет, если входящие запросы превысят максимальное количество ЕЗ/с для базы данных или контейнера?

Если общее количество потребляемых ЕЗ/с превышает максимальное количество ЕЗ/с для базы данных или контейнера, запросы, превышающие максимальное количество ЕЗ/с, будут регулироваться и возвращать код состояния 429. Запросы, нормализованное использование которых превышает 100 %, также будут регулироваться. Нормализованное использование определяется как максимальное использование ЕЗ/с во всех физических разделах. Например, предположим, что ваша максимальная пропускная способность составляет 20 000 ЕЗ/с, и у вас есть два физических раздела, P_1 и P_2, каждый из которых можно масштабировать до 10 000 ЕЗ/с. В данную секунду, если P_1 использовал 6000 RU, а P_2 8000 RU, нормализованное использование равно MAX(6000 RU / 10 000 RU, 8000 RU / 10 000 RU) = 0,8.

Примечание

Пакеты SDK клиента Azure Cosmos DB и средства импорта данных (фабрика данных Azure, библиотека массового исполнителя) автоматически повторяют попытки с ошибкой 429, поэтому случайные ошибки 429 допустимы. Постоянно высокое число ошибок 429 может указывать на то, что вам необходимо увеличить максимальное количество ЕЗ/с или пересмотреть стратегию секционирования для горячей секции.

Да. Можно увидеть 429 в двух сценариях. Во-первых, когда общее количество потребляемых ЕЗ/с превышает максимальное количество ЕЗ/с для базы данных или контейнера, служба соответствующим образом ограничивает запросы.

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

Например, если выбрать параметр максимальной пропускной способности 20 000 ЕЗ/с и иметь 200 ГБ хранилища с четырьмя физическими разделами, каждый физический раздел можно автоматически масштабировать до 5000 ЕЗ/с. Если на определенном ключе логического раздела был горячий раздел, вы увидите 429s, когда базовый физический раздел, в котором он находится, превышает 5000 ЕЗ/с, что превышает нормализованное использование 100%.\

Обратите внимание, что появление ошибки 429 при использовании автомасштабирования не обязательно означает наличие проблемы с вашей базой данных или контейнером.