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

Optimize provisioned throughput cost in Azure Cosmos DB (Оптимизация стоимости подготовленной пропускной способности в Azure Cosmos DB)

  • Статья

Область применения: Nosql Mongodb Кассандра Гремлин Таблица

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

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

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

Оптимизация путем подготовки пропускной способности на разных уровнях

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

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

Ниже приведены некоторые рекомендации по выбору стратегии подготавливаемой пропускной способности.

Рекомендуем подготовить пропускную способность для базы данных Azure Cosmos DB (содержащей набор контейнеров) в следующих случаях:

  1. У вас есть несколько десятков контейнеров Azure Cosmos DB и хотите поделиться пропускной способностью между некоторыми или всеми из них.

  2. Вы переносите базу данных с одним клиентом, предназначенную для запуска на виртуальных машинах, размещенных в IaaS, или локальной среде, например NoSQL или реляционных баз данных в Azure Cosmos DB. И если у вас много коллекций, таблиц и графов, и вы не хотите вносить какие-либо изменения в модель данных. Обратите внимание, что при миграции из локальной базы данных может потребоваться скомпрометировать некоторые преимущества, предоставляемые Azure Cosmos DB. Рекомендуется всегда выполнять повторную оценку модели данных для получения максимальной производительности, а также для оптимизации затрат.

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

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

Рекомендуем подготовить пропускную способность для отдельного контейнера в следующих случаях:

  1. У вас есть несколько контейнеров Azure Cosmos DB. Так как Azure Cosmos DB не зависит от схемы, контейнер может содержать элементы с разнородными схемами и не требуют от клиентов создания нескольких типов контейнеров, по одному для каждой сущности. Это всегда вариант, чтобы рассмотреть, следует ли группировать отдельные контейнеры, скажем, 10-20 в один контейнер. При минимуме 400 ЕЗ для контейнеров объединение всех 10–20 контейнеров в один может обеспечить экономию.

  2. Вам нужно контролировать пропускную способность в определенном контейнере и получить гарантированную пропускную способность для заданного контейнера в соответствии с соглашением об уровне обслуживания.

Рекомендуем использовать гибридное сочетание двух стратегий в следующих случаях:

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

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

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

API Для общей пропускной способности настройте следующее Для выделенной пропускной способности настройте следующее
API для NoSQL База данных Контейнер
API Azure Cosmos DB для MongoDB База данных Коллекция
API для Cassandra Пространство ключей Таблица
API для Gremlin Учетная запись базы данных График
API для таблицы Учетная запись базы данных Таблица

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

Оптимизация с ограничением частоты запросов

Для рабочих нагрузок, не чувствительных к задержке, можно подготовить меньше пропускной способности и обрабатывать ограничение частоты запросов в приложении, когда фактическая пропускная способность превысит подготовленную. Сервер заранее завершит запрос с ошибкой RequestRateTooLarge (код состояния HTTP 429) и вернет в заголовке x-ms-retry-after-ms время (в миллисекундах), спустя которое пользователь сможет повторно выполнить этот запрос.

HTTP Status 429, 
 Status Line: RequestRateTooLarge 
 x-ms-retry-after-ms :100

Логика повтора в пакетах SDK

Собственные пакеты SDK (.NET/.NET Core, Java, Node.js и Python) неявно перехватывают этот ответ, учитывают указанный сервером заголовок retry-after и повторяют попытку запроса. Если к вашей учетной записи имеют доступ сразу несколько клиентов, следующая попытка будет успешной.

Если у вас более одного клиента, согласованно работающего над скоростью запроса, число повторных попыток по умолчанию, которое в настоящее время имеет значение 9, может быть недостаточно. В этом случае клиент создает в приложении исключение RequestRateTooLargeException с кодом состояния 429. Число повторных попыток по умолчанию можно изменить, задав свойство RetryOptions в экземпляре ConnectionPolicy. По умолчанию в случае превышения заданного счетчика повторов исключение RequestRateTooLargeException с кодом состояния 429 возвращается через 30 секунд (совокупное время ожидания). Это происходит, даже если текущее значение количества повторных попыток (по умолчанию (9) или определенное пользователем) меньше максимального значения.

Для MaxRetryAttemptsOnThrottledRequests задано значение 3. Таким образом, если операции запроса ограничены по частоте зарезервированной пропускной способностью для контейнера, будут выполнены три повторные попытки операции запроса, прежде чем в приложении будет создано исключение. Для MaxRetryWaitTimeInSeconds задано значение 60. В этом случае, если совокупное время ожидания повторных попыток с момента первого запроса превысит 60 секунд, будет выдано исключение.

ConnectionPolicy connectionPolicy = new ConnectionPolicy(); 
connectionPolicy.RetryOptions.MaxRetryAttemptsOnThrottledRequests = 3; 
connectionPolicy.RetryOptions.MaxRetryWaitTimeInSeconds = 60;

Стратегия секционирования и затраты на подготовленную пропускную способность

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

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

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

  • Выберите ключ секции, который имеет широкий диапазон значений.

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

Проектирование элементов меньшего размера для повышения пропускной способности

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

Схемы доступа к данным

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

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

Оптимизация путем изменения политики индексирования

По умолчанию Azure Cosmos DB автоматически индексирует все свойства каждой записи. Это делается для упрощения разработки и обеспечения высокой производительности для множества различных типов ad-hoc-запросов. Если у вас есть большие записи с тысячами свойств, оплата пропускной способности для индексирования каждого свойства может оказаться не полезной, особенно если вы запрашиваете только 10 или 20 этих свойств. Когда вы научитесь лучше управлять конкретной рабочей нагрузкой, рекомендуем настроить политику индексирования. Подробные сведения о политике индексирования в Azure Cosmos DB см. в этой статье.

Мониторинг подготовленной и потребляемой пропускной способности

Вы можете отслеживать общее количество подготовленных единиц запросов, количество запросов с ограниченными скоростью и количество единиц запросов, которые вы использовали в портал Azure. Дополнительные сведения см. в статье "Анализ метрик Azure Cosmos DB". На следующем изображении показан пример метрики использования:

Мониторинг единиц запроса на портале Azure

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

Эластичное масштабирование пропускной способности и масштабирование по запросу

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

  • Мониторинг потребления единиц запросов и соотношение запросов с ограниченными скоростями может показать, что вам не нужно поддерживать подготовку в течение всего дня или недели. Вы можете получить меньше трафика в ночное время или в выходные дни. С помощью портала Azure или собственных пакетов SDK либо REST API для Azure Cosmos DB можно в любое время масштабировать подготовленную пропускную способность. REST API для Azure Cosmos DB предоставляет конечные точки для программного изменения уровня производительности контейнеров, что упрощает регулирование пропускной способности из кода в зависимости от времени дня или дня недели. Операция выполняется без простоев и обычно вступает в силу в менее чем за минуту.

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

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

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

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

  1. Выполните первоначальную грубую оценку с помощью планировщика ресурсов и откорректируйте результаты оценки с помощью Обозревателя Azure Cosmos DB на портале Azure.

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

  3. Рекомендуем использовать один из собственных пакетов SDK для Azure Cosmos DB, чтобы использовать преимущество автоматических повторов при ограничении частоты запросов. Если вы работаете на платформе, которая не поддерживается и используете REST API Azure Cosmos DB, реализуйте собственную политику повторных попыток с помощью заголовка x-ms-retry-after-ms .

  4. Убедитесь, что код вашего приложения корректно поддерживает ситуацию, когда все повторы завершаются неудачно.

  5. Вы можете настроить оповещения на портале Azure, чтобы получать уведомления об ограничении частоты. Начать можно с умеренных ограничений, например с 10 запросов с ограниченной частотой за последние 15 минут, а после выяснения фактического потребления ресурсов — переключиться на более строгие правила. Редкие нерегулярные ограничения частоты — это нормально, они показывают, что вы оперируете как раз в заданных пределах и это именно то, что вам требуется.

  6. Определите структуру трафика с помощью мониторинга, чтобы оценить потребность в динамической корректировке подготовленной пропускной способности в течение дня или недели.

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

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

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

  1. Если вы подготовили чрезмерный объем пропускной способности для всех контейнеров и баз данных, следует проанализировать количество подготовленных ЕЗ в сравнении с потребленными ЕЗ и точнее настроить рабочие нагрузки.

  2. Одним из способов оценки объема зарезервированной пропускной способности, необходимой для приложения, является запись платы за единицу запроса, связанную с выполнением типичных операций с репрезентативным контейнером или базой данных Azure Cosmos DB, используемой приложением, а затем оценить количество операций, которые вы ожидаете выполнять каждую секунду. Не забудьте измерить и включить в расчет стандартные запросы и их потребление. Чтобы узнать, как оценить стоимость ЕЗ на выполнение запросов программным способом или с помощью портала, см. статью об оптимизации затрат на запросы.

  3. Другой способ проанализировать операции и их стоимость в ЕЗ — включить журналы Azure Monitor, что позволит получить разбивку по операциям, их длительности и плате за запросы. В Azure Cosmos DB плата за запросы начисляется для каждой операции, поэтому сведения о плате за каждую операцию можно сохранить из ответа и затем использовать для анализа.

  4. Можно гибко масштабировать подготовленную пропускную способность в обе стороны по мере изменения потребностей рабочей нагрузки.

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

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

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

  8. Рассмотрите возможность использования уровня "Бесплатный уровень Azure Cosmos DB" (бесплатно в течение одного года), попробуйте Azure Cosmos DB (до трех регионов) или скачайте эмулятор Azure Cosmos DB для сценариев разработки и тестирования. Используя эти возможности для тестирования и разработки, можно существенно снизить затраты.

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

  10. Благодаря зарезервированной емкости Azure Cosmos DB можно получить значительные скидки (до 65 %) на три года. Модель зарезервированной емкости Azure Cosmos DB предусматривает авансовую оплату за единицы запроса, которые потребуются со временем. Скидки распределяются по уровням таким образом, что чем больше единиц запроса используется за продолжительный период времени, тем больше скидка. Эти скидки вступают в силу немедленно. За любые потребленные ЕЗ сверх подготовленных значений плата взимается на основе тарифов на незарезервированную емкость. Дополнительные сведения см. в статье о зарезервированной емкости Azure Cosmos DB. Рекомендуем приобрести зарезервированную емкость для дополнительного уменьшения затрат на подготовленную пропускную способность.

Следующие шаги

Теперь вы можете перейти к изучению оптимизации затрат в Azure Cosmos DB в следующих статьях: