Бөлісу құралы:

Как адаптироваться к Azure Cosmos DB для Apache Cassandra, если вы поступаете из Apache Cassandra

  • Мақала

Область применения: Кассандра

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

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

Поддерживаемые компоненты

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

Репликация

При планировании репликации важно обеспечить как миграцию, так и согласованность.

Хотя вы можете взаимодействовать с API для Cassandra с помощью протокола CQL (CQL) двоичного протокола версии 4, Azure Cosmos DB реализует собственный внутренний протокол репликации. Протокол взаимодействия Cassandra нельзя использовать для динамической миграции или репликации. Дополнительные сведения см. в статье Live-миграция из Apache Cassandra в API для Cassandra с помощью двух операций записи.

Сведения об автономной миграции см. в статье "Миграция данных из Cassandra в учетную запись Azure Cosmos DB для Apache Cassandra" с помощью Azure Databricks.

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

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

Примеры кода

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

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

Кроме того, вы можете использовать примеры для Java Spring Boot (драйвер версии 3) и Java Spring Boot (драйвер версии 4).

Хранилище

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

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

Развертывание в нескольких регионах Azure.

Нативное решение Apache Cassandra по умолчанию является системой с несколькими источниками. У Apache Cassandra нет возможности использовать один источник с репликацией в несколько регионов только для чтения. Понятие отработки отказа на уровне приложения в другой регион для записи является избыточным в Apache Cassandra. Все узлы независимы, и единой точки отказа нет. Но Azure Cosmos DB позволяет настраивать регионы с одним или несколькими источниками для операций записи.

Преимущество использования региона с одним источником для записи — предотвращении конфликтов между регионами. Это позволяет обеспечить высокий уровень согласованности данных в нескольких регионах при сохранении высокого уровня доступности.

Примечание.

В нативном решении Apache Cassandra нельзя реализовать строгую согласованность между регионами и нулевое значение целевой точки восстановления (RPO), так как все узлы могут служить для записи. Вы можете настроить в Azure Cosmos DB строгую согласованность между регионами в рамках конфигурации записи в один регион. Но, как и при использовании нативного решения Apache Cassandra, вы не можете настроить учетную запись Azure Cosmos DB с несколькими регионами записи для обеспечения строгой согласованности. Распределенная система не может предоставлять нулевые значения RPO и целевого времени восстановления (RTO).

Дополнительные сведения см. в статье о политике балансировки нагрузки в нашем API для рекомендаций Cassandra для блога Java. Также см. раздел сценариев отработки отказа в официальном примере кода для драйвера Cassandra Java v4.

Единиц запросов

Одно из основных различий между запуском собственного кластера Apache Cassandra и подготовкой учетной записи Azure Cosmos DB — способ подготовки емкости базы данных. В традиционных базах данных емкость указывается в ядрах ЦП, ОЗУ и операциях ввода-вывода в секунду. Azure Cosmos DB — это мультитенантная база данных на основе модели "платформа как услуга". Емкость выражается с использованием единой нормализованной метрики, называемой единицами запросов. Каждый запрос, отправляемый в базу данных, имеет свою стоимость единицы запроса (ЕЗ). Для каждого запроса можно выполнить профилирование, чтобы определить его стоимость.

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

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

Модели подготовки емкости

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

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

Секционирование

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

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

Масштабирование

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

Ограничение частоты

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

Соединитель Apache Spark

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

Устранение распространенных неполадок

Сведения о решениях распространенных проблем см. в статье "Устранение распространенных проблем в Azure Cosmos DB для Apache Cassandra".

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