Оптимизируйте стоимость подготовленной пропускной способности в базе данных 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

Можно также настроить оповещения, чтобы проверить, превышает ли количество запросов с ограничением по частоте определенное пороговое значение. Дополнительные сведения см. в статье Мониторинг и отладка с помощью метрик в Azure Cosmos DB. Эти оповещения могут отправлять сообщение электронной почты администраторам учетных записей или вызывать настраиваемый веб-перехватчик HTTP либо функцию Azure для автоматического увеличения подготовленной пропускной способности.

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

Так как плата взимается за подготовленную пропускную способность, сопоставление подготовленной пропускной способности с вашими потребностями поможет вам избежать расходов на неиспользуемую пропускную способность. Масштаб подготовленной пропускной способности можно при необходимости увеличивать или уменьшать в любое время. Если требования к пропускной способности очень предсказуемы, вы можете использовать Функции 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 в следующих статьях: