Часто задаваемые вопросы о Azure Cosmos DB для Apache Cassandra

Ниже приведены некоторые ключевые различия между API для службы Cassandra и Apache Cassandra:

• Рекомендуемое ограничение размера ключа секции в Apache Cassandra составляет 100 МБ. API для Cassandra для Azure Cosmos DB позволяет до 20 ГБ на секцию.
• Apache Cassandra позволяет отключить устойчивые фиксации. Вы можете пропустить запись в журнал фиксации и перейти непосредственно в структуру данных в памяти. Это может привести к потере данных, если узел выходит из строя, прежде чем структуры данных в памяти сбрасываются на 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 полностью управляется. Вам не нужны команды, такие как восстановление и вывод из эксплуатации, которые используются в Apache Cassandra.

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

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

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

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

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. Основной вывод здесь о том, что логическая секция не должна пройти через ограничение в 20 ГБ.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

№ API для Cassandra поддерживает вторичные индексы, которые ведут себя аналогично Apache Cassandra. API по умолчанию не индексировать каждый атрибут.

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

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

Связанный контент

• Начало работы с эластичным масштабированием учетной записи Azure Cosmos DB для Учетной записи Apache Cassandra

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