Эластичное масштабирование учетной записи Azure Cosmos DB для Apache Cassandra
ПРИМЕНИМО К:
Кассандра
Существует множество вариантов изучения эластичного характера Azure Cosmos DB для Apache Cassandra. Чтобы понять, как выполнять эффективное масштабирование в Azure Cosmos DB, важно знать, как подготовить правильное число единиц запросов (ЕЗ/с), чтобы соответствовать требованиям к производительности в системе. Дополнительные сведения о единицах запроса см. в этой статье.
Для API для Cassandra можно получить плату за единицу запроса для отдельных запросов с помощью пакетов SDK для .NET и 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;
- программным образом, используя функции уровня управления;
- программным образом, используя команды CQL с конкретным пакетом SDK;
- динамически с помощью автомасштабирования.
В следующих разделах объясняются преимущества и недостатки каждого из подходов. Затем вы можете выбрать оптимальную стратегию, чтобы сбалансировать потребности в масштабировании системы, общую стоимость и эффективность решения.
Использование портала Azure
Вы можете масштабировать ресурсы в Azure Cosmos DB для учетной записи Apache Cassandra с помощью портал 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 может оказаться более экономично выгодным методом автоматического масштабирования по сравнению с использованием автомасштабирования. Недостаток этого подхода заключается в том, что реализация повторных попыток может быть довольно сложной, а ограничение по частоте может увеличить задержку.
Использование подготовленной пропускной способности автомасштабирования
В дополнение к стандартному (ручному) или программному способу подготовки пропускной способности можно также настроить контейнеры Azure Cosmos DB с автомасштабированием подготовленной пропускной способности. Функция автомасштабирования автоматически и мгновенно выполняет масштабирование в соответствии с потребностями в рамках указанных диапазонов единиц запросов, не нарушая соглашения об уровне обслуживания. Дополнительные сведения см. в статье Создание контейнеров и баз данных Azure Cosmos DB в автомасштабировании .
Преимущество такого подхода заключается в том, что это самый простой способ учитывать потребности в масштабировании системы. Он не применяет ограничение по частоте в пределах настроенных диапазонов ЕЗ. Недостатком является то, что, если потребности в масштабировании системы предсказуемы, автомасштабирование может оказаться менее экономично выгодным способом для соответствия потребностей в масштабировании, чем использование собственных уровней управления или пакета 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;
Дальнейшие действия
- Начало работы с созданием API для учетной записи Cassandra, базы данных и таблицы с помощью приложения Java