Эластичное масштабирование учетной записи API Cassandra в Azure Cosmos DB

ПРИМЕНИМО К: API Cassandra

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

Для API Cassandra вы можете получить сведения о расходуемых единицах запросов для отдельных запросов с помощью .NET и пакетов SDK для Java. Это может оказаться полезным при определении числа ЕЗ/с для подготовки в службе.

Операции с базой данных потребляют единицы запроса

Обработка ограничения частоты (429 ошибок)

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

Если система не чувствительна к задержке, может быть достаточно обработать ограничение частоты пропускной способности, выполнив повторные попытки. Чтобы узнать, как "прозрачно" управлять ограничениями скорости, см. примеры кода Java для драйверов Apache Cassandra Java версии 3 и версии 4. В этих примерах реализована пользовательская версия политики повтора Cassandra, используемой по умолчанию, в Java. Для обработки ограничения по частоте можно также использовать расширение Spark. При использовании Spark обязательно следуйте нашим рекомендациям по оптимизации конфигурации пропускной способности соединителя Spark.

Управление масштабированием

Если необходимо уменьшить задержку, существует ряд вариантов управления масштабированием и подготовки пропускной способности (ЕЗ) в API Cassandra:

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

Использование портала Azure

Вы можете масштабировать ресурсы в учетной записи API Cassandra в Azure Cosmos DB с помощью портала Azure. Дополнительные сведения см. в статье Обеспечение необходимой пропускной способности для контейнеров и баз данных. В этой статье объясняются относительные преимущества настройки пропускной способности на уровне базы данных или контейнера на портале Azure. Термины "база данных" и "контейнер", упомянутые в этих статьях, сопоставляются с "пространством ключей" и "таблицей" для API Cassandra.

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

Использование уровня управления

API Azure Cosmos DB для Cassandra обеспечивает возможность программной настройки пропускной способности с помощью различных функций уровня управления. Инструкции и примеры см. в статьях об Azure Resource Manager, PowerShell и Azure CLI.

Преимущество этого метода заключается в том, что вы можете автоматизировать масштабирование ресурсов на основе таймера, чтобы учитывать пиковую активность или периоды низкой активности. Рассмотрим наш пример здесь, чтобы узнать, как это сделать с помощью Функций Azure и PowerShell.

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

Использование запросов QL с конкретным пакетом SDK

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

Преимущество такого подхода заключается в том, что он позволяет вам отвечать на запросы масштабирования динамически и в соответствии с вашими настройками, которые подходят для приложения. При таком подходе к вам по-прежнему будет применяться стандартная тарификация за ЕЗ/с. Если потребности в масштабировании системы в основном являются прогнозируемыми (около 70 % или более), использование пакета SDK с CQL может оказаться более экономично выгодным методом автоматического масштабирования по сравнению с использованием автомасштабирования. Недостаток этого подхода заключается в том, что реализация повторных попыток может быть довольно сложной, а ограничение по частоте может увеличить задержку.

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

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

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

Чтобы задать или изменить максимальную пропускную способность (ЕЗ) для автомасштабирования с помощью CQL, выполните следующую команду (заменяя имя пространства ключей/таблицы соответствующим образом):

# to set max throughput (RUs) for autoscale at keyspace level:
create keyspace <keyspace name> WITH cosmosdb_autoscale_max_throughput=5000;

# to alter max throughput (RUs) for autoscale at keyspace level:
alter keyspace <keyspace name> WITH cosmosdb_autoscale_max_throughput=4000;

# to set max throughput (RUs) for autoscale at table level:
create table <keyspace name>.<table name> (pk int PRIMARY KEY, ck int) WITH cosmosdb_autoscale_max_throughput=5000;

# to alter max throughput (RUs) for autoscale at table level:
alter table <keyspace name>.<table name> WITH cosmosdb_autoscale_max_throughput=4000;

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