Share via

Comment s’adapter à Azure Cosmos DB for Apache Cassandra si vous venez d’Apache Cassandra

  • Article

S’APPLIQUE À : Cassandra

Azure Cosmos DB for Apache Cassandra fournit une compatibilité avec les protocoles filaires via les kits SDK et outils Cassandra existants. Vous pouvez exécuter des applications conçues pour se connecter à Apache Cassandra à l’aide de l’API pour Cassandra avec un minimum de changements.

Lorsque vous utilisez l’API pour Cassandra, il est important de connaître les différences entre Apache Cassandra et Azure Cosmos DB. Si vous êtes familiarisé avec Apache Cassandra natif, cet article peut vous aider à commencer à utiliser Azure Cosmos DB for Apache Cassandra.

Prise en charge des fonctionnalités

L’API pour Cassandra prend en charge un grand nombre de fonctionnalités d’Apache Cassandra. Certaines fonctionnalités ne sont pas prises en charge ou ont des limitations. Avant de migrer, assurez-vous que les fonctionnalités d’Azure Cosmos DB for Apache Cassandra dont vous avez besoin sont prises en charge.

Réplication

Lorsque vous planifiez la réplication, il est important de regarder à la fois la migration et la cohérence.

Même si vous pouvez communiquer avec l’API pour Cassandra via le protocole filaire CQL (Cassandra Query Language) binaire v4, Azure Cosmos DB implémente son propre protocole de réplication interne. Vous ne pouvez pas utiliser le protocole de bavardage Cassandra pour la migration ou la réplication en direct. Pour plus d’informations, consultez Migrer en direct d’Apache Cassandra vers l’API pour Cassandra en utilisant deux écritures.

Pour plus d’informations sur une migration hors connexion, consultez Migrer des données de Cassandra vers un compte d’Azure Cosmos DB for Apache Cassandra en utilisant Azure Databricks.

Bien que les approches de la cohérence de la réplication dans Apache Cassandra et Azure Cosmos DB soient similaires, il est important de comprendre en quoi elles sont différentes. Un document de correspondance compare les approches Apache Cassandra et Azure Cosmos DB au niveau de la cohérence de la réplication. Toutefois, nous vous recommandons vivement de passer spécialement en revue les paramètres de cohérence d’Azure Cosmos DB ou de regarder une petite vidéo qui vous aide à comprendre les paramètres de cohérence dans la plateforme Azure Cosmos DB.

Lorsque vous utilisez l’API pour Cassandra, vous n’avez pas besoin d’apporter beaucoup de changements au code des applications existantes qui exécutent Apache Cassandra. Nous vous recommandons quelques approches et paramètres de configuration pour l’API pour Cassandra dans Azure Cosmos DB. Consultez le billet de blog sur les recommandations de l’API pour Cassandra pour Java.

Exemples de code

L’API pour Cassandra est conçue pour fonctionner avec votre code d’application existant. Si vous rencontrez des erreurs liées à la connectivité, utilisez les exemples de démarrage rapide comme point de départ pour découvrir les changements mineurs de configuration que vous risquez de devoir apporter à votre code existant.

Nous avons également des exemples plus détaillés de pilotes Java v3 et Java v4. Ces exemples de code implémentent des extensions personnalisées qui, elles-mêmes, implémentent les configurations client recommandées.

Vous pouvez aussi utiliser des exemples pour Java Spring Boot (pilote v3) et Java Spring Boot (pilote v4).

Stockage

L’API pour Cassandra est alimentée par Azure Cosmos DB, moteur de base de données NoSQL orienté document. Azure Cosmos DB conserve les métadonnées, ce qui peut entraîner un changement dans l’espace de stockage physique nécessaire pour une charge de travail spécifique.

La différence dans les besoins de stockage entre Apache Cassandra natif et Azure Cosmos DB se remarque de façon plus notable dans les petites tailles de ligne. Dans certains cas, la différence peut être compensée parce qu’Azure Cosmos DB n’implémente pas le compactage ou les objets tombstone. Ce facteur dépend considérablement de la charge de travail. Si vous n’êtes pas sûr du stockage nécessaire, nous vous recommandons de créer d’abord une preuve de concept.

Déploiements multirégion

Apache Cassandra natif est un système multimaître par défaut. Apache Cassandra n’offre pas d’option pour un maître unique avec la réplication multirégion pour les lectures uniquement. Le concept de basculement au niveau de l’application vers une autre région pour les écritures est redondant dans Apache Cassandra. Tous les nœuds sont indépendants et il n’y a pas de point de défaillance unique. Toutefois, Azure Cosmos DB offre la possibilité de configurer des régions monomaîtres ou multimaîtres pour les écritures.

L’avantage d’avoir une région monomaître pour les écritures est qu’il permet d’éviter les conflits inter-régions. Il vous donne la possibilité d’assurer une forte cohérence entre plusieurs régions tout en maintenant un niveau de haute disponibilité.

Notes

Une forte cohérence entre les régions et un objectif de point de récupération (RPO) de zéro ne sont pas possibles pour Apache Cassandra natif, car tous les nœuds sont capables de servir les écritures. Vous pouvez configurer Azure Cosmos DB pour une forte cohérence entre plusieurs régions dans une configuration de région mono-écriture. Toutefois, comme avec Apache Cassandra natif, vous ne pouvez pas configurer un compte Azure Cosmos DB configuré avec plusieurs régions d’écriture pour une forte cohérence. Un système distribué ne peut pas fournir un RPO de zéro et un objectif de temps de récupération (RTO) de zéro.

Pour plus d’informations, consultez la Stratégie d’équilibrage de charge dans notre billet de blog Recommandations relatives à l’API pour Cassandra pour Java. En outre, consultez les Scénarios de basculement dans notre Exemple de code officiel pour le pilote Cassandra Java v4.

Unités de demande

L’une des principales différences entre l’exécution d’un cluster Apache Cassandra natif et le provisionnement d’un compte Azure Cosmos DB est la manière dont la capacité de base de données est provisionnée. Dans les bases de données traditionnelles, la capacité est exprimée en cœurs de processeur, en RAM et en IOPS. Azure Cosmos DB est une base de données de plateforme en tant que service mutualisée. La capacité est exprimée à l’aide d’une métrique normalisée unique, appelée unité de requête. Chaque requête envoyée à la base de données a un coût en unités de requête (coût RU). Chaque requête peut être profilée pour déterminer son coût.

L’avantage d’utiliser des unités de requête comme métrique est que la capacité de base de données peut être provisionnée de manière déterministe pour bénéficier de performances et d’une efficacité hautement prévisibles. Après avoir profilé le coût de chaque requête, vous pouvez utiliser des unités de requête pour associer directement le nombre de requêtes envoyées à la base de données à la capacité dont vous avez besoin pour provisionner. La difficulté de cette méthode d’approvisionnement en capacité est que vous devez avoir une bonne connaissance des caractéristiques de débit de votre charge de travail.

Nous vous recommandons vivement de profiler vos requêtes. Utilisez ces informations pour vous aider à estimer le nombre d’unités de requêtes que vous devrez approvisionner. Voici quelques articles susceptibles de vous aider à faire une estimation :

Modèles d’approvisionnement de capacité

Dans le provisionnement des bases de données traditionnelles, une capacité fixe est provisionnée d’avance pour gérer le débit anticipé. Azure Cosmos DB propose un modèle basé sur la capacité, appelé débit provisionné. En tant que service multilocataire, Azure Cosmos DB propose également des modèles basés sur la consommation en mode mise à l’échelle automatique et en mode serverless. Une charge de travail peut bénéficier plus ou moins de l’un de ces modèles de provisionnement basés sur la consommation en fonction de la prédictibilité de son débit.

En général, les charges de travail stables qui ont un débit prévisible bénéficient le plus de l’approche du débit provisionné. Les charges de travail dont les périodes de repos sont longues bénéficient plus du mode serverless. Les charges de travail qui ont un niveau continu de débit minimal, mais avec des pics imprévisibles, bénéficient le plus du mode de mise à l’échelle automatique. Nous vous recommandons de consulter les articles suivants pour avoir une idée claire du meilleur modèle de capacité pour vos besoins de débit :

Partitionnement

Dans Azure Cosmos DB, le partitionnement est similaire à celui dans Apache Cassandra. L’une des principales différences est qu’Azure Cosmos DB est plus optimisé pour la mise à l'échelle horizontale. Dans Azure Cosmos DB, des limites sont placées sur la quantité de capacité de débit vertical qui est disponible dans toute partition physique. L'effet de cette optimisation est le plus visible quand un modèle de données existant a de gros écarts de débit.

Prenez des mesures pour vous assurer que la conception de votre clé de répartition entraîne une distribution relativement uniforme des requêtes. Pour plus d’informations sur le fonctionnement du partitionnement logique et physique et sur les limites de capacité de débit par partition, consultez Partitionnement dans Azure Cosmos DB for Apache Cassandra.

Mise à l’échelle

Dans Apache Cassandra en mode natif, l’augmentation de capacité et de l’échelle impliquent d’ajouter de nouveaux nœuds à un cluster et de veiller à ce que les nœuds soient correctement ajoutés à l’anneau Cassandra. Dans Azure Cosmos DB, l’ajout de nœuds est transparent et automatique. La mise à l’échelle sert à déterminer combien d’unités de requête sont provisionnées pour votre table ou espace de clés. La mise à l’échelle des ordinateurs physiques se produit lorsque le stockage physique ou le débit requis atteint les limites autorisées pour une partition physique ou logique. Pour plus d’informations, consultez Partitionnement dans Azure Cosmos DB for Apache Cassandra.

Limitation du débit

Une des difficultés à provisionner des unités de requête, en particulier si vous utilisez un débit provisionné, est la limitation du débit. Azure Cosmos DB retourne des erreurs de débit limité si les clients consomment plus de ressources que la quantité que vous avez provisionnée. L’API pour Cassandra dans Azure Cosmos DB traduit ces exceptions en erreurs surchargées sur le protocole natif Cassandra. Pour savoir comment éviter la limitation de débit dans votre application, consultez Empêcher les erreurs de limitation de débit pour les opérations d’Azure Cosmos DB for Apache Cassandra.

Connecteur Apache Spark

De nombreux utilisateurs Apache Cassandra se servent du connecteur Apache Spark Cassandra pour interroger leurs données à des fins d’analytique et de déplacement de celles-ci. Vous pouvez vous connecter à l’API pour Cassandra de la même façon et en utilisant le même connecteur. Avant de vous connecter à l’API pour Cassandra, consultez Se connecter à Azure Cosmos DB for Apache Cassandra de Spark. Consultez notamment la section Optimiser la configuration du débit du connecteur Spark.

Résolution des problèmes courants

Pour obtenir des solutions aux problèmes courants, consultez Résoudre les problèmes courants dans Azure Cosmos DB for Apache Cassandra.

Étapes suivantes