Partager via

Fonctionnalités Apache Cassandra prises en charge par Azure Cosmos DB for Apache Cassandra

  • Article

S’APPLIQUE À : Cassandra

Azure Cosmos DB est le service de base de données multi-modèle de Microsoft distribué à l’échelle mondiale. Vous pouvez communiquer avec l’Azure Cosmos DB for Apache Cassandra par le biais des pilotes clients Cassandra open source et conformes au protocole de transmission CQL (Cassandra Query Language) Binary Protocol v4.

En utilisant l’Azure Cosmos DB for Apache Cassandra, vous pouvez bénéficier des avantages des API Cassandra Apache et des fonctionnalités d’entreprise fournies par Azure Cosmos DB. Parmi les fonctionnalités d’entreprise, citons la distribution mondiale, le partitionnement automatique de scale-out, des garanties de disponibilité et de latence, le chiffrement au repos, les sauvegardes et bien plus encore.

Protocole Cassandra

L’Azure Cosmos DB for Apache Cassandra est compatible avec l’API CQL (Cassandra Query Language) v3.11 (compatibilité descendante avec la version 2.x). Les commandes CQL, les outils, les limitations et les exceptions pris en charge sont listés ci-dessous. Les pilotes clients comprenant ces protocoles doivent pouvoir se connecter à Azure Cosmos DB for Apache Cassandra.

Azure Managed Instance pour Apache Cassandra

Pour certains clients, l’adaptation à l’API pour Cassandra peut s’avérer être un défi en raison de différences de comportement et/ou de configuration, en particulier pour des migrations lift-and-shift. Si une fonctionnalité critique pour votre application est répertoriée comme étant non prise en charge ci-dessous, envisagez d’utiliser Azure Managed Instance pour Apache Cassandra. Il s’agit d’un service Azure interne pour l’hébergement et la maintenance de clusters Apache Cassandra open source purs avec une compatibilité à 100 %.

Pilote Cassandra

Les versions suivantes des pilotes Cassandra sont prises en charge par Azure Cosmos DB for Apache Cassandra :

Types de données CQL

Azure Cosmos DB for Apache Cassandra prend en charge les types de données CQL suivants :

Type Pris en charge
ascii Oui
bigint Oui
blob Oui
boolean Oui
counter Oui
date Oui
decimal Oui
double Oui
float Oui
frozen Oui
inet Oui
int Oui
list Oui
set Oui
smallint Oui
text Oui
time Oui
timestamp Oui
timeuuid Oui
tinyint Oui
tuple Oui
uuid Oui
varchar Oui
varint Oui
tuples Oui
udts Oui
map Oui

Static est pris en charge pour la déclaration du type de données.

Fonctions CQL

Azure Cosmos DB for Apache Cassandra prend en charge les fonctions CQL suivants :

Commande Prise en charge
Token * Oui
ttl *** Oui
writetime *** Oui
cast ** Oui

Notes

* L’API pour Cassandra prend en charge le jeton en tant que projection/sélecteur et autorise uniquement token(pk) du côté gauche d’une clause Where. Par exemple, WHERE token(pk) > 1024 est pris en charge, contrairement à WHERE token(pk) > token(100) .
** La fonction cast() ne peut pas être imbriquée dans l’API pour Cassandra. Par exemple, SELECT cast(count as double) FROM myTable est pris en charge, contrairement à SELECT avg(cast(count as double)) FROM myTable .
*** Les horodatages personnalisés et la durée de vie spécifiés avec l’option USING sont appliqués au niveau de la ligne (et non par cellule).

Fonctions d’agrégation :

Commande Prise en charge
avg Oui
count Oui
min Oui
max Oui
sum Oui

Notes

Les fonctions d’agrégation fonctionnent sur les colonnes habituelles. Toutefois, les agrégats de colonnes de clustering ne sont pas pris en charge.

Fonctions de conversion blob :

Commande Prise en charge
typeAsBlob(value) Oui
blobAsType(value) Oui

Fonctions UUID et timeuuid :

Commande Prise en charge
dateOf() Oui
now() Oui
minTimeuuid() Oui
unixTimestampOf() Oui
toDate(timeuuid) Oui
toTimestamp(timeuuid) Oui
toUnixTimestamp(timeuuid) Oui
toDate(timestamp) Oui
toUnixTimestamp(timestamp) Oui
toTimestamp(date) Oui
toUnixTimestamp(date) Oui

Commandes CQL

Azure Cosmos DB prend en charge les commandes de base de données suivantes sur les comptes d’API pour Cassandra.

Commande Prise en charge
ALLOW FILTERING Oui
ALTER KEYSPACE N/A (service PaaS, réplication gérée en interne)
ALTER MATERIALIZED VIEW Oui
ALTER ROLE No
ALTER TABLE Oui
ALTER TYPE No
ALTER USER Non
BATCH Oui (lot non journalisé uniquement)
COMPACT STORAGE N/A (service PaaS)
CREATE AGGREGATE Non
CREATE CUSTOM INDEX (SASI) No
CREATE INDEX Oui (y compris les index nommés, mais la collection FROZEN complète n’est pas prise en charge)
CREATE FUNCTION Non
CREATE KEYSPACE (paramètres de réplication ignorés) Oui
CREATE MATERIALIZED VIEW Oui
CREATE TABLE Oui
CREATE TRIGGER No
CREATE TYPE Oui
CREATE ROLE Non
CREATE USER (Déprécié dans Apache Cassandra natif) Non
DELETE Oui
DISTINCT No
DROP AGGREGATE Non
DROP FUNCTION Non
DROP INDEX Oui
DROP KEYSPACE Oui
DROP MATERIALIZED VIEW Oui
DROP ROLE No
DROP TABLE Oui
DROP TRIGGER No
DROP TYPE Oui
DROP USER (Déprécié dans Apache Cassandra natif) Non
GRANT Non
INSERT Oui
LIST PERMISSIONS No
LIST ROLES Non
LIST USERS (Déprécié dans Apache Cassandra natif) Non
REVOKE Non
SELECT Oui
UPDATE Oui
TRUNCATE Oui
USE Oui

Transactions légères (LWT)

Composant Prise en charge
DELETE IF EXISTS Oui
DELETE conditions Oui
INSERT IF NOT EXISTS Oui
UPDATE IF EXISTS Oui
UPDATE IF NOT EXISTS Oui
UPDATE conditions Oui

Notes

Les transactions légères ne sont actuellement pas prises en charge pour les comptes avec des écritures multirégions activées.

Commandes de l’interpréteur de commandes CQL

Azure Cosmos DB prend en charge les commandes de base de données suivantes sur les comptes d’API pour Cassandra.

Commande Prise en charge
CAPTURE Oui
CLEAR Oui
CONSISTENCY * N/A
COPY Non
DESCRIBE Oui
cqlshExpand No
EXIT Oui
LOGIN N/A (la fonction CQL USER n’étant pas prise en charge, la fonction LOGIN est redondante)
PAGING Oui
SERIAL CONSISTENCY * N/A
SHOW Oui
SOURCE Oui
TRACING N/A (l’API pour Cassandra est adossée à Azure Cosmos DB ; utilisez la journalisation de diagnostic pour résoudre les problèmes)

Notes

Consistency fonctionne différemment dans Azure Cosmos DB. Cliquez ici pour plus d’informations.

Prise en charge de JSON

Commande Prise en charge
SELECT JSON Oui
INSERT JSON Oui
fromJson() No
toJson() Non

Limites de l’API pour Cassandra

Azure Cosmos DB for Apache Cassandra n’a aucune limite sur la taille des données stockées dans une table. Des centaines de téraoctets ou pétaoctets de données peuvent être stockées tout en garantissant le respect des limites de clé de partition. De même, chaque entité ou ligne équivalente n’a aucune limite de nombre de colonnes. Toutefois, la taille totale de l’entité ne doit pas dépasser 2 Mo. Les données par clé de partition ne peuvent pas dépasser 20 Go, comme dans toutes les autres API.

Outils

Azure Cosmos DB for Apache Cassandra est une plateforme de service géré. La plateforme ne nécessite aucune surcharge de gestion ni aucun utilitaire, comme le Garbage Collector, Java Virtual Machine (JVM) et nodetool, pour gérer le cluster. Des outils tels que cqlsh, qui utilise la compatibilité de CQLv4 binaire, sont pris en charge.

  • L’Explorateur de données du portail Azure, les métriques, les diagnostics de journaux, PowerShell et CLI sont d’autres mécanismes pris en charge pour gérer le compte.

Interpréteur de commandes CQL

Vous pouvez vous connecter à l’API pour Cassandra dans Azure Cosmos DB à l’aide de l’interpréteur CQLSH installé sur un ordinateur local. Il est fourni avec Apache Cassandra 3.11 et prêt à fonctionner moyennant la définition des variables d’environnement. Les sections suivantes incluent les instructions d’installation, de configuration et de connexion à l’API pour Cassandra dans Azure Cosmos DB sur Windows ou Linux à l’aide de CQLSH.

Avertissement

Les connexions à Azure Cosmos DB for Apache Cassandra ne fonctionnent pas avec les versions Cassandra 4.0 ou DataStax Enterprise (DSE) de CQLSH. Veillez à utiliser uniquement les versions Apache Cassandra de CQLSH open source v3.11 lors de la connexion à l’API pour Cassandra.

Windows :

  1. Installer Python 3
  2. Installer PIP
    1. Avant d’installer PIP, téléchargez le fichier get-pip.py.
    2. Lancez une invite de commandes si elle n’est pas déjà ouverte. Pour ce faire, ouvrez la barre de recherche Windows, tapez cmd puis sélectionnez l’icône.
    3. Ensuite, exécutez la commande suivante pour télécharger le fichier get-pip.py :
    curl https://bootstrap.pypa.io/get-pip.py -o get-pip.py
  3. Installer PIP sur Windows
python get-pip.py
  1. Vérifiez l’installation de PIP (recherchez un message de l’étape 3 pour voir dans quel dossier PIP a été installé, puis accédez à ce dossier et exécutez la commande pip help).
  2. Installer CQLSH à l’aide de PIP
pip3 install cqlsh==5.0.3
  1. Installer Python 2
  2. Exécutez CQLSH à l’aide du mécanisme d’authentification.

Notes

Vous devez configurer les variables d’environnement pour qu’elles pointent vers le dossier Python 2.

Installer sur Unix/Linux/Mac :

# Install default-jre and default-jdk
sudo apt install default-jre
sudo apt-get update
sudo apt install default-jdk

# Import the Baltimore CyberTrust root certificate:
curl https://cacert.omniroot.com/bc2025.crt > bc2025.crt
keytool -importcert -alias bc2025ca -file bc2025.crt

# Install the Cassandra libraries in order to get CQLSH:
echo "deb https://downloads.apache.org/cassandra/debian 311x main" | sudo tee -a /etc/apt/sources.list.d/cassandra.sources.list
curl https://downloads.apache.org/cassandra/KEYS | sudo apt-key add -
sudo apt-get update
sudo apt-get install cassandra=3.11.13

Se connecter avec Unix/Linux/Mac :

# Export the SSL variables:
export SSL_VERSION=TLSv1_2
export SSL_VALIDATE=false

# Connect to Azure Cosmos DB for Apache Cassandra:
cqlsh <YOUR_ACCOUNT_NAME>.cassandra.cosmosdb.azure.com 10350 -u <YOUR_ACCOUNT_NAME> -p <YOUR_ACCOUNT_PASSWORD> --ssl --protocol-version=4

Se connecter avec Docker :

docker run -it --rm -e SSL_VALIDATE=false -e SSL_VERSION=TLSv1_2 cassandra:3.11 cqlsh <account_name>.cassandra.cosmos.azure.com 10350 -u <YOUR_ACCOUNT_NAME> -p <YOUR_ACCOUNT_PASSWORD> --ssl

Toutes les opérations CRUD exécutées par le biais d’un Kit de développement logiciel (SDK) compatible CQL v4 retournent des informations supplémentaires sur l’erreur et les unités de demande consommées. Les commandes DELETE et UPDATE doivent être gérées en tenant compte de la gouvernance des ressources, afin de garantir l’utilisation la plus efficace du débit approvisionné.

  • Notez que la valeur gc_grace_seconds doit être égale à zéro si elle est spécifiée.
var tableInsertStatement = table.Insert(sampleEntity); 
var insertResult = await tableInsertStatement.ExecuteAsync(); 
 
foreach (string key in insertResult.Info.IncomingPayload) 
        { 
            byte[] valueInBytes = customPayload[key]; 
            double value = Encoding.UTF8.GetString(valueInBytes); 
            Console.WriteLine($"CustomPayload:  {key}: {value}"); 
        }

Mappage de cohérence

Azure Cosmos DB for Apache Cassandra offre un choix de cohérence pour les opérations de lecture. Le mappage de cohérence est détaillé ici.

Gestion des rôles et des autorisations

Azure Cosmos DB prend en charge le contrôle d’accès en fonction du rôle Azure (Azure RBAC) pour le provisionnement, la rotation de clés, l’affichage des métriques et les mots de passe/clés en lecture-écriture et en lecture seule, qui peuvent être obtenus via le portail Azure. Azure Cosmos DB ne prend pas en charge les rôles pour les activités CRUD.

Options d’espace de clé et de table

Les options pour le nom de région, la classe, replication_factor et le centre de centres dans la commande « CREATE KEYSPACE » sont actuellement ignorées. Le système utilise la méthode de réplication par distribution globale d’Azure Cosmos DB sous-jacente pour ajouter les régions. Si vous avez besoin de la présence de données inter-régions, vous pouvez l’activer au niveau du compte avec PowerShell, CLI ou le portail. Pour en savoir plus, consultez l’article expliquant comment ajouter des régions. Durable_writes ne peut pas être désactivé, car Azure Cosmos DB garantit la durabilité de chaque écriture. Dans chaque région, Azure Cosmos DB réplique les données dans le jeu de réplicas composé de 4 réplicas, et cette configuration de jeu de réplicas ne peut pas être modifiée.

Toutes les options sont ignorées lors de la création de la table, sauf gc_grace_seconds, qui doit être définie sur zéro. L’espace de clé et la table ont une option supplémentaire nommée « cosmosdb_provisioned_throughput » avec une valeur minimale de 400 RU/s. Le débit d’espace de clé permet de partager le débit entre plusieurs tables, et il est utile dans les scénarios où toutes les tables n’utilisent pas le débit provisionné. La commande ALTER TABLE permet de modifier le débit provisionné dans les régions.

CREATE  KEYSPACE  sampleks WITH REPLICATION = {  'class' : 'SimpleStrategy'}   AND cosmosdb_provisioned_throughput=2000;  

CREATE TABLE sampleks.t1(user_id int PRIMARY KEY, lastname text) WITH cosmosdb_provisioned_throughput=2000; 

ALTER TABLE gks1.t1 WITH cosmosdb_provisioned_throughput=10000 ;

Index secondaire

L’API pour Cassandra prend en charge les index secondaires sur tous les types de données, à l’exception des types de collections figés, et des types decimal et variant.

Utilisation de la stratégie de connexion de nouvelle tentative Cassandra

Azure Cosmos DB est un système régi par les ressources. Vous pouvez effectuer un certain nombre d’opérations durant une seconde donnée, en fonction des unités de requête consommées par les opérations. Si une application dépasse cette limite durant une seconde donnée, le taux des requêtes est limité et des exceptions sont levées. L’API pour Cassandra dans Azure Cosmos DB traduit ces exceptions en erreurs surchargées sur le protocole natif Cassandra. Pour vous assurer que votre application peut intercepter et effectuer de nouvelles tentatives de requête en cas de limitation du taux, les extensions spark et Java sont fournies. Consultez également les exemples de code Java pour les pilotes Datastax version 3 et version 4 lors de la connexion à l’API pour Cassandra dans Azure Cosmos DB. Si vous utilisez d’autres kits SDK pour accéder à l’API pour Cassandra dans Azure Cosmos DB, créez une stratégie de nouvelle tentative pour effectuer une nouvelle tentative quand ces exceptions se produisent. En guise d’alternative, activez les nouvelles tentatives côté serveur pour l’API pour Cassandra.

Étapes suivantes