Questions fréquentes sur Azure Cosmos DB for Apache Cassandra

Voici quelques différences essentielles entre Apache Cassandra et l’API pour le service Cassandra :

• Apache Cassandra recommande de limiter à 100 Mo la taille de clé de partition. L’API pour Cassandra pour Azure Cosmos DB autorise jusqu’à 20 Go par partition.
• Apache Cassandra permet de désactiver les validations durables. Vous pouvez ignorer l’écriture dans le journal de validation et accéder directement aux structures de données en mémoire. Cela peut entraîner une perte de données, si le nœud cesse de fonctionner avant que les structures de données en mémoire soient vidées dans des SStables sur disque. Azure Cosmos DB effectue toujours des validations durables pour prévenir la perte de données.
• Les performances d’Apache Cassandra peuvent baisser si la charge de travail implique un grand nombre de remplacements ou suppressions. Cela est dû aux enregistrements désactivés que la charge de travail de lecture doit ignorer pour extraire les données les plus récentes. Les performances de lecture de l’API pour Cassandra ne baissent pas lorsque la charge de travail inclut un grand nombre de remplacements ou suppressions.
• Dans les scénarios de charges de travail de remplacement lourdes, une compression s’impose pour fusionner les SSTables sur le disque (Une fusion est nécessaire car les écritures d’Apache Cassandra ne sont que des ajouts. Plusieurs mises à jour sont stockées en tant qu’entrées SSTable individuelles qui doivent être fusionnées périodiquement). Cette situation peut également entraîner une baisse des performances de lecture pendant le compactage. Cet impact sur les performances ne se produit pas dans l’API pour Cassandra parce que celle-ci n’implémente pas de compactage.
• La définition d’un facteur de réplication de 1 est possible avec Apache Cassandra. Toutefois, cela aboutit à une faible disponibilité si le seul nœud avec les données tombe en panne. Ce n’est pas un problème concernant l’API pour Cassandra pour Azure Cosmos DB, car il existe toujours un facteur de réplication de 4 (quorum de 3).
• L’ajout ou la suppression de nœuds dans Apache Cassandra nécessite une intervention manuelle, ainsi qu’une utilisation élevée du processeur sur le nouveau nœud lorsque les nœuds existants déplacent certaines de leurs plages de jetons vers le nouveau nœud. Cette situation est la même lorsque vous désaffectez un nœud existant. Quoi qu’il en soit, l’API pour Cassandra effectue un scale-out sans occasionner le moindre problème dans le service ou l’application.
• Il n’est pas nécessaire de définir num_tokens sur chaque nœud du cluster comme dans Apache Cassandra. Azure Cosmos DB gère entièrement les nœuds et les plages de jetons.
• L’API pour Cassandra est complètement managée. Vous n’avez pas besoin des commandes, telles que la réparation et la désaffectation, qui sont utilisées dans Apache Cassandra.

L’API pour Cassandra pour Azure Cosmos DB prend en charge CQL (Cassandra Query Language) version 3.x. Sa compatibilité avec CQL est basée sur le référentiel GitHub Apache Cassandra public. Si vous avez des commentaires sur la prise en charge d’autres protocoles, envoyez un e-mail à askcosmosdbcassandra@microsoft.com.

Azure Cosmos DB définit le débit par défaut pour votre conteneur en fonction de l’emplacement à partir duquel vous créez la table : portail Azure ou CQL.

Azure Cosmos DB fournit des garanties de performances et de latence avec des limites supérieures pour les opérations. Ces garanties sont possibles lorsque le moteur peut assurer la gouvernance sur les opérations du client. La définition du débit est pour vous l’assurance de bénéficier du débit et de la latence garantis, car la plateforme réserve cette capacité et garantit le succès des opérations. Vous avez la possibilité de modifier le débit de façon élastique pour profiter de la saisonnalité de votre application et réaliser des économies.

Le concept de débit est expliqué dans l’article Unités de requête dans Azure Cosmos DB. Le débit d’une table est réparti uniformément entre les partitions physiques sous-jacentes.

Azure Cosmos DB utilise les unités de requête par seconde (RU/s) comme devise pour offrir le débit. Par défaut, les tables créées via CQL contiennent 400 unités de requête. Vous pouvez modifier les unités de requête à partir du portail.

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 fournit des garanties de performances et de latence avec des limites supérieures pour les opérations. Ces garanties sont possibles lorsque le moteur peut assurer la gouvernance sur les opérations du client. La définition du débit est pour vous l’assurance de bénéficier du débit et de la latence garantis, car la plateforme réserve cette capacité et garantit le succès des opérations.

Lorsque vous dépassez cette capacité, vous recevez le message d’erreur suivant, qui indique que votre capacité est épuisée :

Surcharge 0x1001 : impossible de traiter la requête, car « Le taux de demandes est élevé »

Il est essentiel d’identifier les opérations et les volumes à l’origine de ce problème. Vous pouvez avoir une idée de la capacité utilisée au-delà de la capacité approvisionnée grâce aux métriques du portail Azure. Vous devez ensuite vérifier que cette capacité est répartie presque uniformément entre toutes les partitions sous-jacentes. Si vous constatez qu’une partition utilise la majeure partie du débit, vous avez une asymétrie de la charge de travail.

Des indicateurs de performance sont disponibles pour vous montrer l’utilisation du débit au fil des heures, jours et semaines, sur les différentes partitions, ou sous forme agrégée. Pour plus d’informations, consultez la section Surveillance et débogage à l’aide de métriques dans Azure Cosmos DB.

Les journaux de diagnostic sont expliquées dans l’article Journalisation des diagnostics Azure Cosmos DB.

Oui. La clé de partition est utilisée pour placer l’entité au bon endroit. Dans Azure Cosmos DB, elle est utilisée pour trouver la bonne partition logique qui est stockée sur une partition physique. Le concept de partitionnement est également expliqué dans l’article Partitionner et mettre à l’échelle dans Azure Cosmos DB. Ce qu’il faut retenir, c’est qu’une partition logique ne doit pas dépasser la limite de 20 Go.

Azure Cosmos DB est un système basé sur un contrat de niveau de service (SLA). Il offre une mise à l’échelle illimitée, avec des garanties en matière de latence, de débit, de disponibilité et de cohérence. Cet espace de stockage illimité est basé sur un scale-out horizontal des données utilisant le partitionnement comme concept clé. Le concept de partitionnement est également expliqué dans l’article Partitionner et mettre à l’échelle dans Azure Cosmos DB.

Vous devez respecter la limite de 20 Go sur le nombre d’entités ou d’éléments par partition logique. Pour vous assurer que la mise à l’échelle de votre application fonctionne correctement, nous vous recommandons de ne pas créer de partition sensible en stockant toutes les informations dans une seule partition et en interrogeant celle-ci. Cette erreur ne peut se produire qu’en présence d’une asymétrie des données, c’est-à-dire si vous en avez trop pour une clé de partition (plus de 20 Go). La répartition des données est visible sur le portail de stockage. Pour corriger cette erreur, recréez la table et choisissez une clé principale granulaire (clé de partition), qui permet une meilleure répartition des données.

Azure Cosmos DB peut stocker des données illimitées en effectuant un scale-out du stockage. Ce stockage est indépendant du débit. Oui vous pouvez toujours utiliser l’API pour Cassandra pour stocker et récupérer des clés et valeurs en spécifiant la bonne clé primaire/de partition. Ces clés individuelles obtiennent leur propre partition logique et résident sur une partition physique sans problème.

Oui, l’API pour Cassandra permet de créer plusieurs tables. Chacune de ces tables est traitée en tant qu’unité de débit et de stockage.

Azure Cosmos DB est un système régi par les ressources pour les activités liées aux données et au plan de contrôle. Les conteneurs comme les collections et les tables sont des entités de runtime qui sont approvisionnées pour une capacité de débit déterminées. La création de ces conteneurs dans une succession rapide est une activité non spécifiquement prévue et potentiellement limitée. Si vous avez des tests qui suppriment ou créent des tables immédiatement, essayez de les espacer.

Il n’existe aucune limite physique au nombre de tables. Si vous avez un grand nombre de tables (dont la taille totale constante dépasse 10 To de données) à créer au lieu des dizaines ou centaines de tables habituelles, envoyez un e-mail à l’adresse askcosmosdbcassandra@microsoft.com.

Il n’existe aucune limite physique au nombre d’espaces de clés, car il s’agit de conteneurs de métadonnées. Si vous avez un grand nombre d’espaces de clés, envoyez un e-mail à l’adresse askcosmosdbcassandra@microsoft.com.

Oui. En supposant que les partitions sont distribuées de manière uniforme, la capacité de stockage est gérée automatiquement et augmente à mesure que vous envoyez des données supplémentaires. Par conséquent, vous pouvez importer en toute confiance autant de données que vous le souhaitez sans avoir à gérer et approvisionner des nœuds ou d’autres ressources. En revanche, si vous anticipez une croissance importante des données, il est plus judicieux d’effectuer l’approvisionnement du débit anticipé directement, au lieu de commencer à un niveau plus bas et devoir rehausser celui-ci immédiatement.

L’API pour Cassandra pour Azure Cosmos DB assure la compatibilité au niveau du protocole pour l’exécution des opérations. Elle masque la complexité des opérations de gestion, de supervision et de configuration. En tant que développeur/utilisateur, vous n’avez pas à vous soucier de la disponibilité, des enregistrements désactivés, du cache de clés, du cache de lignes, des filtres de Bloom et d’une multitude d’autres paramètres. L’API pour Cassandra s’attache à fournir les performances de lecture et d’écriture dont vous avez besoin, sans la surcharge associée à la configuration et à la gestion.

L’API pour Cassandra simplifie les processus de planification de la capacité et de réponse aux demandes d’élasticité pour le débit et le stockage. Azure Cosmos DB vous permet d’approvisionner le débit dont vous avez besoin. Vous pouvez ensuite augmenter ou réduire le débit autant de fois par jour que vous le souhaitez, sans vous soucier des tâches d’ajout, de suppression ou de gestion des nœuds. Vous n’avez pas besoin d’outils pour la gestion des nœuds et des clusters.

Azure Cosmos DB offre une fonctionnalité de distribution mondiale prête à l’emploi pour répondre aux besoins de haute disponibilité et de faible latence. Vous n’avez pas besoin de configurer des réplicas ou quoi que ce soit. Les écritures sont toujours validées durablement par un quorum dans toute région où vous écrivez des données, tout en offrant des garanties de performances.

Azure Cosmos DB offre des garanties de performances pour les lectures, les écritures et le débit. Vous ne devez pas craindre de toucher aux paramètres de configuration et de les manipuler accidentellement. Ces paramètres sont les suivants : filtre de Bloom, mise en cache, changement de réparation des lectures, période de grâce du garbage collection et période de vidage des memtables pour la compression.

Oui, TTL est pris en charge.

Azure Cosmos DB est un service de plateforme qui vous permet d’augmenter votre productivité sans vous soucier des opérations de gestion et de surveillance de l’infrastructure. Par exemple, vous n’avez pas à surveiller l’état du nœud, l’état du réplica, le garbage collection et les paramètres du système d’exploitation en amont avec différents outils. Vous devez simplement surveiller le débit relevé dans les métriques accessibles sur le portail pour voir si vous approchez de la limite, et augmenter ou réduire ce débit en conséquence. Vous pouvez :

• Analyser des contrats de niveau de service
• Utiliser des métriques
• Utiliser des journaux de diagnostic

Les pilotes clients du Kit de développement logiciel (SDK) Apache Cassandra reposant sur CQLv3 ont été utilisés pour les programmes clients. Si vous utilisez d’autres pilotes ou si vous rencontrez des difficultés, envoyez un e-mail à l’adresse askcosmosdbcassandra@microsoft.com.

Oui, vous pouvez utiliser une syntaxe ordinaire pour créer des clés de partition composites.

Non, sstableloader n’est pas pris en charge.

Azure Cosmos DB offre maintenant une expérience optimisée pour un environnement cloud, sans surcharge liée aux opérations. Si vous avez besoin de procéder à une association, envoyez un e-mail à l’adresse askcosmosdbcassandra@microsoft.com avec une description de votre scénario. Nous préparons une offre pour vous aider à coupler le cluster Cassandra local ou cloud avec l’API pour Cassandra pour Azure Cosmos DB.

Azure Cosmos DB réalise deux sauvegardes complètes gratuites toutes les quatre heures, sur toutes les API. Vous n’avez donc pas besoin de planifier les sauvegardes.

Vous pouvez gérer la fréquence et la conservation des sauvegardes vous-même.

Si vous souhaitez effectuer une restauration à partir d’une sauvegarde, envoyez un e-mail à askcosmosdbcassandra@microsoft.com ou soumettez un ticket de support. Pour en savoir plus sur la fonctionnalité de sauvegarde, consultez l’article Sauvegarde et restauration en ligne automatiques avec Azure Cosmos DB.

L’API pour Cassandra s’appuie sur la plateforme distribuée mondialement d’Azure Cosmos DB. Pour vérifier que votre application peut tolérer des temps d’arrêt de centre de données, activez au moins une région supplémentaire pour le compte dans le portail Azure. Pour plus d’informations, consultez Haute disponibilité avec Azure Cosmos DB.

Vous pouvez ajouter autant de régions que vous le souhaitez pour le compte, et contrôler l’emplacement de basculement en indiquant une priorité. Pour utiliser la base de données, vous devez également fournir une application à cet emplacement. Si vous procédez de la sorte, vos clients ne subissent aucun temps d’arrêt.

Non. L’API pour Cassandra prend en charge les index secondaires, qui se comportent comme dans Apache Cassandra. Par défaut, l’API n’indexe pas chaque attribut.

Oui, cette méthode est prise en charge. Pour plus d’informations sur la façon de l’activer, consultez l’article Utiliser l’émulateur Azure Cosmos DB à des fins de développement et de test en local.

Pour plus d’informations sur les options de migration, consultez le didacticiel Migrer vos données vers un compte d’API pour Cassandra dans Azure Cosmos DB.

Contenu connexe

• Prenez en main de la mise à l’échelle de manière élastique d’un compte Azure Cosmos DB for Apache Cassandra

Étape suivante