Рекомендации по масштабированию подготовленной пропускной способности

В этой статье описываются рекомендации и стратегии масштабирования пропускной способности базы данных или контейнера (коллекция, таблица или граф). Эти концепции применяются при увеличении предоставляемых вручную единиц запроса в секунду (RU/s) или максимальном значении автомасштаба RU/s любого из API Azure Cosmos DB.

Предпосылки

• Если вы не знакомы с секционированием и масштабированием в Azure Cosmos DB, см. раздел секционирования и горизонтальное масштабирование в Azure Cosmos DB.
• Если вы планируете увеличить пропускную способность RU/с из-за исключений 429, ознакомьтесь с руководством по диагностике и устранению неполадок с исключениями "Частота запросов слишком большая" (429). Перед увеличением ЕЗ определите основную причину проблемы и выясните, является ли увеличение количества ЕЗ правильным решением.

Обзор масштабирования RU/с (запросных единиц в секунду)

При отправке запроса на увеличение ЕЗ/с базы данных или контейнера в зависимости от запрошенного ЕЗ/с и текущего макета физической секции операция масштабирования выполняется мгновенно или асинхронно (обычно 4–6 часов).

• Мгновенное масштабирование:

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

• Асинхронное масштабирование:

  • Если запрашиваемые RU/с (объем операций в секунду) выше того, что может поддерживать конфигурация физических секций, Azure Cosmos DB разделяет существующие физические секции. Это происходит до тех пор, пока у ресурса не будет минимально необходимого количества разделов, необходимых для поддержки запрашиваемой производительности (RU/с).
  • В результате операция может занять некоторое время (обычно 4–6 часов). Каждый физический раздел может поддерживать максимум 10 000 RU/с (относится ко всем API) пропускной способности и 50 ГБ хранилища (относится ко всем API, кроме Cassandra, для которой хранилище составляет 30 ГБ).

  Замечание

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

• Мгновенное снижение масштаба:

  • Для операции горизонтального масштабирования Azure Cosmos DB не нужно разделять или добавлять новые секции.
  • В результате операция завершится мгновенно, и RU/s будут доступны для использования.
  • Ключевым результатом этой операции является уменьшение числа RUs на каждый физический раздел.

Как масштабировать RU/с без изменения разделения

Шаг 1. Найдите текущее количество физических разделов

Перейдите в раздел Аналитика>Пропускная способность>Нормализованное потребление на единицу запроса (%) по PartitionKeyRangeID. Подсчитайте количество отдельных идентификаторов PartitionKeyRangeIds.

Каждый PartitionKeyRangeId сопоставляется с одним физическим разделом и назначается для хранения данных в диапазоне возможных значений хэша.

Azure Cosmos DB распределяет ваши данные по логическим и физическим секциям на основе ключа раздела для обеспечения горизонтального масштабирования. По мере написания данных Azure Cosmos DB использует хэш значения ключа секции, чтобы определить, на каком логическом и физическом разделе находятся данные.

Шаг 2. Расчет максимальной пропускной способности по умолчанию

Максимальное количество RU/с, до которого можно масштабироваться, не вызывая разделения секций в Azure Cosmos DB, равно Current number of physical partitions * 10,000 RU/s.

Это значение можно получить от поставщика ресурсов Azure Cosmos DB. Выполните GET-запрос для объектов установок пропускной способности базы данных или контейнера и получите свойство instantMaximumThroughput. Это значение также доступно на странице "Масштаб и параметры " базы данных или контейнера на портале.

Example

Допустим, у вас есть существующий контейнер с пятью физическими разделами и 30 000 RU/s вручную настроенной пропускной способности. Вы можете мгновенно увеличить скорость ЕЗ/с 5 * 10,000 RU/s = 50,000 RU/s. Аналогично, если бы у нас был контейнер с автомасштабируемым максимальным количеством ЕЗ — 30 000 ЕЗ (масштабируется в диапазоне 3000 — 30 000 ЕЗ), мы могли бы мгновенно увеличить максимальное количество ЕЗ до 50 000 ЕЗ (масштабируется в диапазоне 5000 — 50 000 ЕЗ).

Как обеспечить равномерное распределение данных при асинхронном масштабировании

Основные сведения

Когда вы увеличиваете число единиц запроса в секунду (RU/s) за пределы текущего количества physical partitions * 10,000 RU/s, Azure Cosmos DB делит существующие партиции до тех пор, пока новое количество партиций не станет равным ROUNDUP(requested RU/s / 10,000 RU/s). Во время разделения родительские секции разделяются на две дочерних.

Например, предположим, что у вас есть контейнер с тремя физическими секциями и вручную выделенной пропускной способностью 30 000 RU/s. При увеличении пропускной способности до 45 000 ЕЗ/с Azure Cosmos DB разделяет две из существующих физических секций, чтобы в общей сложности было ROUNDUP(45,000 RU/s / 10,000 RU/s) = 5 physical partitions.

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

Чтобы узнать, почему давайте рассмотрим пример, в котором у вас есть существующий контейнер с двумя физическими секциями, 20 000 ЕЗ/с и 80 ГБ данных.

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

Кроме того, в Azure Cosmos DB RU/s равномерно распределяется по всем физическим разделам. В результате каждый физический раздел имеет 10 000 RU/s и 50 % (40 ГБ) от общего объема данных. На схеме ниже показано текущее состояние.

Предположим, вы хотите увеличить ЕЗ/с с с 20 000 ЕЗ/с до 30 000 ЕЗ/с.

Если вы просто увеличиваете ЕЗ/с до 30 000 ЕЗ/с, то разделяется только одна из секций. После разделения у вас есть:

• Одна секция, содержащая 50% данных (эта секция не была разделена).
• Два раздела, содержащие по 25% данных каждый (это образовавшиеся дочерние разделы из родительского раздела, который был разделен).

Так как Azure Cosmos DB равномерно распределяет ЕЗ/с по всем физическим секциям, каждая физическая секция по-прежнему получает 10 000 ЕЗ/с. Теперь у вас наблюдается перекос в распределении хранилища и нагрузки запросов.

На следующей схеме секции 3 и 4 (дочерние секции секций 2) имеют 10 000 ЕЗ/с для обслуживания запросов на 20 ГБ данных, а секция 1 имеет 10 000 ЕЗ/с, чтобы обслуживать запросы на два раза больше данных (40 ГБ).

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

Таким образом, если начать с двух физических разделов, чтобы гарантировать, что разделы будут равномерными после разделения, необходимо задать RU/s таким образом, чтобы в итоге получилось четыре физических раздела. Чтобы достичь этого, сначала установите RU/s = 4 * 10,000 RU/s per partition = 40,000 RU/s. Затем, после завершения разделения, уменьшите RU/с до 30 000 RU/с.

В результате каждый физический раздел получает 30,000 RU/s / 4 = 7500 RU/s для обработки запросов на 20 ГБ данных. В целом вы поддерживаете равномерное распределение хранилища и запросов между разделами.

Общая формула

Шаг 1: Увеличьте количество RU/s, чтобы гарантировать равномерное разделение всех разделов

В общем случае, если у вас есть P начальных физических разделов и вы хотите установить желаемое число RU/с S.

Увеличьте ваши RU/с до: 10,000 * P * (2 ^ (ROUNDUP(LOG_2 (S/(10,000 * P)))). Это приближает RU/с к желательному значению, что гарантирует равномерное деление всех разделов.

Шаг 2. Понижение количества ЕЗ до нужного

Например, предположим, что у нас есть пять физических разделов, 50,000 RU/s, и мы хотим масштабироваться до 150,000 RU/s. Сначала следует задать: 10,000 * 5 * (2 ^ (ROUND(LOG_2(150,000/(10,000 * 5)))) = 200,000 RU/sи затем уменьшить до 150 000 ЕЗ/с.

Когда мы увеличили масштаб до 200,000 РУ/с (Request Units в секунду), самый низкий уровень РУ/с, который мы можем теперь установить вручную в будущем, составляет 2,000 РУ/с. Самое низкое значение максимальной скорости автомасштабирования ЕЗ, которое мы можем установить, составляет 20 000 ЕЗ (масштабируется в диапазоне от 2 000 до 20 000 ЕЗ). Так как наша целевая единица запросов в секунду составляет 150 000 ЕЗ/с, мы не пострадали от минимального ЕЗ/с.

Оптимизация строк в секунду (RU/s) для большого поглощения данных

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

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

Шаг 1: Проверьте выбор ключа раздела

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

Шаг 2. Вычисление количества физических секций, необходимых

Number of physical partitions = Total data size in GB / Target data per physical partition in GB

Каждая физическая секция может содержать не более 50 ГБ хранилища (30 ГБ для API для Cassandra). Значение, которое следует выбрать для целевых данных на физический раздел в ГБ, зависит от того, насколько плотно вы хотите заполнить физические разделы и сколько вы ожидаете роста хранилища после миграции.

Например, если предполагается, что хранилище будет продолжать расти, можно задать значение 30 ГБ. Если вы выбрали хороший ключ раздела, который равномерно распределяет хранилище, каждый раздел заполнен примерно на 60% (30 ГБ из 50 ГБ). По мере записи будущих данных они могут храниться на существующем наборе физических секций, не требуя от службы немедленного добавления новых физических секций.

В отличие от этого, если вы считаете, что хранилище не будет значительно увеличиваться после миграции, можно задать значение выше, например 45 ГБ. Это означает, что каждый раздел заполнен на ~90% (45 ГБ из 50 ГБ). Это минимизирует количество физических разделов, по которым распределяются данные, что означает, что каждый физический раздел может получить большую долю от общего количества выделенных RU/s.

Шаг 3: Вычислите количество RU/s для начала для всех разделов

Starting RU/s for all partitions = Number of physical partitions * Initial throughput per physical partition

Начнем с примера с произвольным количеством целевых RU/s на физическую секцию.

• Initial throughput per physical partition = 10,000 RU/s per physical partition при использовании автомасштабирования или общих баз данных пропускной способности
• Initial throughput per physical partition = 6000 RU/s per physical partition при использовании ручного управления пропускной способностью

Example

Предположим, у вас есть 1 ТБ (1000 ГБ) данных для приема и вы хотите использовать ручную пропускную способность. Каждая физическая секция в Azure Cosmos DB имеет емкость 50 ГБ. Предположим, вы стремитесь заполнить разделы на 80% (примерно до 40 ГБ), оставляя место для будущего роста.

Это означает, что для 1 ТБ данных требуются 1000 GB / 40 GB = 25 физические секции. Чтобы обеспечить наличие 25 физических секций с помощью ручной пропускной способности, сначала подготовьте 25 * 6000 RU/s = 150,000 RU/s. Затем, после создания контейнера, чтобы ускорить загрузку, увеличьте РУ/с до 250 000 РУ/с перед началом загрузки (происходит мгновенно, так как у вас уже есть 25 физических разделов). Это позволяет каждому разделу достигать максимум 10 000 RU/s.

Если вы используете автомасштабируемую пропускную способность или общую базу данных пропускной способности, чтобы получить 25 физических разделов, необходимо подготовить 25 * 10,000 RU/s = 250,000 RU/s. Поскольку вы уже находитесь на самом высоком уровне единиц запросов в секунду (РУ/с), которые могут поддерживаться с 25 физическими секциями, вы не будете дополнительно увеличивать выделенные РУ/с перед обработкой данных.

В теории с 250 000 ЕЗ/с и 1 ТБ данных, если предполагается, что размер документов составляет 1 КБ и требуется 10 ЕЗ на запись, загрузка может теоретически завершиться за: 1000 GB * (1,000,000 kb / 1 GB) * (1 document / 1 kb) * (10 RU / document) * (1 sec / 250,000 RU) * (1 hour / 3600 seconds) = 11.1 hours.

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

После завершения миграции можно снизить RU/с или включить функцию автомасштабирования по мере необходимости.

Дальнейшие действия

• Мониторинг журналов действий эластичных операций (разделения/слияния)
• Как мониторить нормализованные RU/s для контейнера или учетной записи Azure Cosmos DB
• Диагностика и устранение неполадок с исключениями "Слишком большая скорость запросов" (429)
• Создание контейнеров и баз данных Azure Cosmos DB с автоматическим масштабированием пропускной способности