Часто задаваемые вопросы об API Cassandra в Azure Cosmos DB

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

В этой статье описаны различия в функциональных возможностях между Apache Cassandra и API Cassandra в Azure Cosmos DB. В ней также приведены ответы на часто задаваемые вопросы об API Cassandra в Azure Cosmos DB.

Основные различия между Apache Cassandra и API Cassandra

  • Рекомендуемое ограничение размера ключа секции в Apache Cassandra составляет 100 МБ. В API Cassandra для Azure Cosmos DB это ограничение составляет 20 ГБ на секцию.
  • Apache Cassandra позволяет отключить устойчивые фиксации. Вы можете пропустить запись в журнал фиксации и перейти непосредственно к таблицам в памяти (memtable). Это может привести к потере данных, если узел выйдет из строя, прежде чем таблицы в памяти будут записаны в таблицы SSTables на диске. Azure Cosmos DB всегда выполняет устойчивые фиксации, чтобы помочь предотвратить потери данных.
  • Если рабочая нагрузка включает много замен или удалений, в Apache Cassandra возможно снижение производительности. Это вызвано отметками полного удаления, которые рабочая нагрузка чтения должна пропускать, чтобы получить последние данные. В API Cassandra не происходит снижения производительности, если рабочая нагрузка содержит много замен или удалений.
  • В сценариях с рабочими нагрузками, включающими много замен, необходимо выполнить сжатие, чтобы объединить таблицы SSTables на диске. (Объединение требуется, так как операции записи в Apache Cassandra включают только добавление данных. Несколько обновлений хранятся в виде отдельных записей в таблице SSTable, и их необходимо периодически объединять). Эта ситуация также может привести к снижению производительности чтения во время сжатия. В API Cassandra такого влияния не происходит, поскольку это API не реализует сжатие.
  • В Apache Cassandra можно установить коэффициент репликации 1. Однако это приведет к снижению доступности в случае, если единственный узел с данными выйдет из строя. В API Cassandra для Azure Cosmos DB это не является проблемой, так как всегда обеспечивается коэффициент репликации 4 (кворум, равный 3).
  • При добавлении или удалении узлов в Apache Cassandra требуется вмешательство вручную, а также возникает высокая загрузка ЦП на новом узле, пока существующие узлы перемещают некоторые из своих диапазонов токенов на новый узел. Такая ситуация возникает при выводе существующего узла из использования. Однако масштабирование API Cassandra не вызывает никаких проблем в службе или приложении.
  • При масштабировании не нужно устанавливать параметр num_tokens на каждом узле в кластере, как в Apache Cassandra. Azure Cosmos DB полностью управляет узлами и диапазонами токенов.
  • API Cassandra является полностью управляемым. Вам не требуются команды nodetool, такие как "repair" и "decommission" в Apache Cassandra.

Другие часто задаваемые вопросы

Какую версию протокола поддерживает API Cassandra?

API Cassandra для Azure Cosmos DB поддерживает CQL версии 3.x. Совместимость API Cassandra с CQL основана на общедоступном репозитории GitHub Apache Cassandra. Отзывы о поддержке других протоколов отправляйте на адрес askcosmosdbcassandra@microsoft.com.

Зачем необходимо выбирать пропускную способность для таблицы?

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

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

Концепция пропускной способности подробно описана в статье Единицы запросов в базе данных Azure Cosmos DB. Пропускная способность для таблицы равномерно распределяется между базовыми физическими секциями.

Что представляет собой пропускная способность таблицы, созданной с помощью CQL?

Azure Cosmos DB использует единицы запросов в секунду (ЕЗ) в качестве валюты для предоставления пропускной способности. Таблицы, созданные с помощью CQL, по умолчанию содержат 400 ЕЗ. Количество ЕЗ можно изменить на портале Azure.

CQL

CREATE TABLE keyspaceName.tablename (user_id int PRIMARY KEY, lastname text) WITH cosmosdb_provisioned_throughput=1200

.NET

int provisionedThroughput = 400;
var simpleStatement = new SimpleStatement($"CREATE TABLE {keyspaceName}.{tableName} (user_id int PRIMARY KEY, lastname text)");
var outgoingPayload = new Dictionary<string, byte[]>();
outgoingPayload["cosmosdb_provisioned_throughput"] = Encoding.UTF8.GetBytes(provisionedThroughput.ToString());
simpleStatement.SetOutgoingPayload(outgoingPayload);

Что происходит, когда достигается предел пропускной способности?

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

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

0x1001 Перегрузка: не удается обработать запрос из-за высокой частоты запросов

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

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

Сведения о журналах диагностики приведены в статье Журнал ведения диагностики Azure Cosmos DB.

Вписывается ли первичный ключ в концепцию ключа секции в Azure Cosmos DB?

Да. Ключ секции используется для размещения сущности в надлежащем расположении. В Azure Cosmos DB он используется для поиска соответствующей логической секции, хранящейся в физической секции. Концепция секционирования подробно описана в статье Секционирование и масштабирование в Azure Cosmos DB. Из этого следует, что размер логической секции не должен превышать ограничение в 20 ГБ.

Что происходит при получении уведомления, информирующего о заполнении секции?

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

Необходимо придерживаться ограничения в 20 ГБ на число сущностей или количество элементов в каждой логической секции. Кроме того, для обеспечения достаточной масштабируемости приложения мы рекомендуем не создавать секцию с высокой нагрузкой, чтобы хранить в ней все сведения и выполнять запрос этих данных. Эта ошибка может возникнуть только при наличии перекоса в распределении данных, то есть если в одном ключе секции находится большой объем данных (более 20 ГБ). Вы можете найти распределение данных, используя портал хранилища. Чтобы устранить эту ошибку, необходимо повторно создать таблицу и выбрать управляемый первичный ключ (ключ секции). Это позволит распределить данные более эффективно.

Можно ли использовать API Cassandra в качестве хранилища пар "ключ — значение" с миллионами или миллиардами ключей секций?

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

Можно ли создать более одной таблицы с помощью API Cassandra?

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

Можно ли поочередно создать несколько таблиц?

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

Каково максимальное число таблиц, которые можно создать?

Физического ограничения на количество таблиц не существует. Если вам нужно создать большое количество таблиц (для которых общий устойчивый размер данных превышает 10 ТБ), а не несколько десятков или сотен таблиц, как обычно, отправьте электронное письмо по адресу askcosmosdbcassandra@microsoft.com.

Какое максимальное число пространств ключей можно создать?

Физическое ограничение на количество пространств ключей отсутствует, так как они являются контейнерами метаданных. Если у вас много пространств ключей, отправьте электронное письмо по адресу askcosmosdbcassandra@microsoft.com.

Можно ли добавить большое количество данных после начала работы с обычной таблицей?

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

Можно ли использовать параметры в YAML-файле для настройки поведения API?

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

Будет ли API Cassandra поддерживать команды добавления узлов и просмотра состояния кластера и состояния узла?

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

Что происходит с различными параметрами конфигурации для создания пространств ключей (например, "простой"/"сеть")?

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

А как насчет параметров для метаданных таблиц?

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

Поддерживается ли срок жизни для таблиц Cassandra?

Да, TTL поддерживается.

Как можно отслеживать инфраструктуру и пропускную способность?

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

Какие клиентские пакеты SDK могут работать с API Cassandra?

Для клиентских программ использовались клиентские драйверы пакета SDK Apache Cassandra, которые используют CQLv3. Если вы используете другие драйверы или если у вас возникли проблемы, отправьте сообщение электронной почты по адресу askcosmosdbcassandra@microsoft.com.

Поддерживаются ли составные ключи секции?

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

Можно ли использовать sstableloader для загрузки данных?

Нет, sstableloader не поддерживается.

Можно ли связать локальный кластер Apache Cassandra с API Cassandra?

Сейчас служба Azure Cosmos DB оптимизирована для работы с облачной средой без дополнительных расходов на операции. Если требуется связывание, отправьте письмо с описанием сценария по адресу askcosmosdbcassandra@microsoft.com. Мы работаем над предложением, которое поможет связать локальный или облачный кластер Cassandra с API Cassandra для Azure Cosmos DB.

Предоставляет ли API Cassandra полные резервные копии?

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

Если необходимо изменить срок хранения и частоту создания резервных копий, отправьте сообщение электронной почты по адресу askcosmosdbcassandra@microsoft.com или обратитесь в службу поддержки. Сведения о возможности резервного копирования см. в статье Автоматическая оперативная архивация и восстановление с помощью Azure Cosmos DB.

Как в учетной записи Cassandra API выполняется отработка отказа, если регион становится недоступен?

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

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

Индексирует ли API Cassandra все атрибуты сущности по умолчанию?

Нет. API Cassandra поддерживает вторичные индексы, функции которых похожи на Apache Cassandra. По умолчанию API не индексирует каждый атрибут.

Можно ли использовать пакет SDK для Cassandra API локально с эмулятором?

Да, это поддерживается. Сведения о том, как это сделать, можно найти в разделе Использование эмулятора Azure Cosmos DB для разработки и тестирования в локальной среде.

Как можно перенести данные из кластеров Apache Cassandra в Azure Cosmos DB?

Сведения о вариантах миграции см. в руководстве Перенос данных в учетную запись API Cassandra в Azure Cosmos DB.