Interface Cassandra

Cette page compare l'architecture d'Apache Cassandra et de Spanner, et vous aide à comprendre les capacités et les limites de l'interface Spanner Cassandra. Il suppose que vous connaissez Cassandra et que vous souhaitez migrer des applications existantes ou en concevoir de nouvelles en utilisant Spanner comme base de données.

Cassandra et Spanner sont deux bases de données distribuées à grande échelle conçues pour les applications nécessitant une évolutivité élevée et une faible latence. Bien que les deux bases de données puissent prendre en charge les charges de travail NoSQL exigeantes, Spanner offre des fonctionnalités avancées pour la modélisation, l'interrogation et les opérations transactionnelles sur les données. Pour en savoir plus sur la façon dont Spanner répond aux critères des bases de données NoSQL, consultez Spanner pour les charges de travail non relationnelles.

Concepts fondamentaux

Cette section compare les principaux concepts de Cassandra et Spanner.

Terminologie

Cassandra Spanner
Cluster Instance

Un cluster Cassandra équivaut à une instance Spanner, qui est une collection de serveurs et de ressources de stockage. Spanner étant un service géré, vous n'avez pas à configurer le matériel ni le logiciel sous-jacents. Il vous suffit de spécifier le nombre de nœuds que vous souhaitez réserver pour votre instance ou d'utiliser l'autoscaling pour mettre automatiquement à l'échelle l'instance. Une instance agit comme un conteneur pour vos bases de données. Vous choisissez également la topologie de réplication des données (régionale, birégionale ou multirégionale) au niveau de l'instance.
Espace de clés Base de données

Un espace de clés Cassandra équivaut à une base de données Spanner, qui est une collection de tables et d'autres éléments de schéma (par exemple, des index et des rôles). Contrairement à un espace de clés, vous n'avez pas besoin de configurer l'emplacement de réplication. Spanner réplique automatiquement vos données dans la région désignée dans votre instance.
Table Table

Dans Cassandra et Spanner, les tables sont des collections de lignes identifiées par une clé primaire spécifiée dans le schéma de table.
Partition Fractionnement

Cassandra et Spanner évoluent en fractionnant les données. Dans Cassandra, chaque segment est appelé "partition", tandis que dans Spanner, il est appelé "division". Cassandra utilise le partitionnement par hachage, ce qui signifie que chaque ligne est attribuée indépendamment à un nœud de stockage en fonction d'un hachage de la clé primaire. Spanner est partitionné par plage, ce qui signifie que les lignes contiguës dans l'espace de noms de la clé primaire sont également contiguës dans le stockage (sauf aux limites de partitionnement). Spanner se charge de fractionner et de fusionner les données en fonction de la charge et du stockage, et ce de manière transparente pour l'application. La principale implication est que, contrairement à Cassandra, les analyses de plage sur un préfixe de la clé primaire sont une opération efficace dans Spanner.
Ligne Ligne

Dans Cassandra et Spanner, une ligne est une collection de colonnes identifiées de manière unique par une clé primaire. Comme Cassandra, Spanner accepte les clés primaires composites. Contrairement à Cassandra, Spanner ne fait pas de distinction entre la clé de partition et les colonnes de clustering, car les données sont segmentées par plage. Vous pouvez considérer que Spanner ne possède que des colonnes de clustering, le partitionnement étant géré en arrière-plan.
Colonne Colonne

Dans Cassandra et Spanner, une colonne est un ensemble de valeurs de données qui ont le même type. Il existe une valeur pour chaque ligne d'un tableau. Pour en savoir plus sur la comparaison des types de colonnes Cassandra avec Spanner, consultez Types de données.

Architecture

Un cluster Cassandra se compose d'un ensemble de serveurs et d'un espace de stockage colocalisé avec ces serveurs. Une fonction de hachage mappe les lignes d'un espace de clés de partition à un nœud virtuel (vnode). Un ensemble de vnodes est ensuite attribué de manière aléatoire à chaque serveur pour desservir une partie de l'espace de clés du cluster. Le stockage des nœuds virtuels est associé localement au nœud de diffusion. Les pilotes client se connectent directement aux nœuds de diffusion et gèrent l'équilibrage de charge et le routage des requêtes.

Une instance Spanner se compose d'un ensemble de serveurs dans une topologie de réplication. Spanner fragmente dynamiquement chaque table en plages de lignes en fonction de l'utilisation du processeur et du disque. Les partitions sont attribuées à des nœuds de calcul pour la diffusion. Les données sont stockées physiquement sur Colossus, le système de fichiers distribué de Google, séparément des nœuds de calcul. Les pilotes client se connectent aux serveurs frontend de Spanner, qui effectuent le routage des requêtes et l'équilibrage de charge. Pour en savoir plus, consultez le livre blanc Déroulement des opérations de lecture et d'écriture Spanner.

De manière générale, les deux architectures évoluent à mesure que des ressources sont ajoutées au cluster sous-jacent. La séparation du calcul et du stockage de Spanner permet de rééquilibrer plus rapidement la charge entre les nœuds de calcul en réponse aux changements de charge de travail. Contrairement à Cassandra, les déplacements de partitions n'impliquent pas de déplacement de données, car les données restent sur Colossus. De plus, le partitionnement basé sur des plages de Spanner peut être plus naturel pour les applications qui s'attendent à ce que les données soient triées par clé de partition. L'inconvénient du partitionnement basé sur une plage est que les charges de travail qui écrivent à une extrémité de l'espace de clés (par exemple, les tables indexées par le code temporel actuel) peuvent présenter des points chauds si d'autres conceptions de schéma ne sont pas envisagées. Pour en savoir plus sur les techniques permettant de surmonter les hotspots, consultez les bonnes pratiques de conception de schémas.

Cohérence

Avec Cassandra, vous devez spécifier un niveau de cohérence pour chaque opération. Si vous utilisez le niveau de cohérence "quorum", une majorité de nœuds d'instance répliquée doit répondre au nœud coordinateur pour que l'opération soit considérée comme réussie. Si vous utilisez un niveau de cohérence de un, Cassandra a besoin d'un seul nœud d'instance dupliquée pour répondre afin que l'opération soit considérée comme réussie.

Spanner offre une cohérence forte. L'API Spanner n'expose pas les répliques au client. Les clients Spanner interagissent avec Spanner comme s'il s'agissait d'une base de données sur une seule machine. Une écriture est toujours effectuée sur une majorité de réplicas avant que Spanner ne confirme son succès à l'utilisateur. Toute lecture ultérieure reflète les données nouvellement écrites. Les applications peuvent choisir de lire un instantané de la base de données à un moment donné dans le passé, ce qui peut améliorer les performances par rapport aux lectures fortes. Pour en savoir plus sur les propriétés de cohérence de Spanner, consultez la présentation des transactions.

Spanner a été conçu pour offrir la cohérence et la disponibilité nécessaires dans les applications à grande échelle. Spanner offre une cohérence forte à grande échelle et de hautes performances. Pour les cas d'utilisation qui le nécessitent, Spanner est compatible avec les lectures instantanées (obsolètes) qui assouplissent les exigences de fraîcheur.

Interface Cassandra

L'interface Cassandra vous permet de profiter de l'infrastructure Spanner entièrement gérée, évolutive et à haute disponibilité à l'aide d'outils et d'une syntaxe Cassandra familiers. Cette page vous aide à comprendre les capacités et les limites de l'interface Cassandra.

Avantages de l'interface Cassandra

  • Portabilité : l'interface Cassandra permet d'accéder à l'ensemble des fonctionnalités Spanner à l'aide de schémas, de requêtes et de clients compatibles avec Cassandra. Cela simplifie le transfert d'une application basée sur Spanner vers un autre environnement Cassandra ou inversement. Cette portabilité offre une flexibilité de déploiement et prend en charge les scénarios de reprise après sinistre, comme une sortie forcée.
  • Familiarité : si vous utilisez déjà Cassandra, vous pouvez rapidement commencer à utiliser Spanner en utilisant de nombreuses instructions et de nombreux types CQL.
  • Spanner sans compromis : l'interface Cassandra s'appuie sur la base existante de Spanner. Elle offre donc tous les avantages de Spanner en termes de disponibilité, de cohérence et de rapport prix/performances, sans avoir à faire de compromis sur les fonctionnalités disponibles dans l'écosystème GoogleSQL complémentaire.

Compatibilité avec CQL

  • Compatibilité avec le dialecte CQL : Spanner fournit un sous-ensemble du dialecte CQL, y compris le langage de requête de données (DQL), le langage de manipulation de données (DML), les transactions légères (LWT), les fonctions d'agrégation et de date/heure.

  • Fonctionnalités Cassandra compatibles : l'interface Cassandra est compatible avec de nombreuses fonctionnalités Cassandra les plus couramment utilisées. Cela inclut les parties principales du schéma et du système de types, de nombreuses formes de requêtes courantes, diverses fonctions et opérateurs, ainsi que les aspects clés du catalogue système de Cassandra. Les applications peuvent utiliser de nombreux clients ou pilotes Cassandra en se connectant à l'implémentation du protocole filaire Cassandra de Spanner.

  • Compatibilité avec le protocole client et réseau : Spanner est compatible avec les principales fonctionnalités de requête du protocole réseau Cassandra v4 à l'aide de l'adaptateur Cassandra, un client léger qui s'exécute en parallèle de votre application. Cela permet à de nombreux clients Cassandra de fonctionner tels quels avec une base de données d'interface Spanner Cassandra, tout en tirant parti du point de terminaison mondial, de la gestion des connexions et de l'authentification IAM de Spanner.

Types de données Cassandra acceptés

Le tableau suivant présente les types de données Cassandra compatibles et met en correspondance chaque type de données avec le type de données Spanner GoogleSQL équivalent.

Types de données Cassandra compatibles Type de données GoogleSQL Spanner
Types numériques tinyint (entier signé de 8 bits) INT64 (entier signé de 64 bits)

Spanner n'accepte qu'un seul type de données de 64 bits de large pour les entiers signés.
smallint (entier signé de 16 bits)
int (entier signé de 32 bits)
bigint (entier signé de 64 bits)
float (virgule flottante IEEE-754 32 bits) FLOAT32 (virgule flottante IEEE-754 32 bits)
double (virgule flottante IEEE-754 64 bits) FLOAT64 (virgule flottante IEEE-754 64 bits)
decimal Pour les nombres décimaux à précision fixe, utilisez le type de données NUMERIC (précision 38, échelle 9).
varint (entier à précision variable)
Types de chaînes text STRING(MAX)

text et varchar stockent et valident les chaînes UTF-8. Dans Spanner, les colonnes STRING doivent spécifier leur longueur maximale. Cela n'a aucun impact sur le stockage. Il s'agit d'une validation.
varchar
ascii STRING(MAX)
uuid STRING(MAX)
inet STRING(MAX)
blob BYTES(MAX)

Pour stocker des données binaires, utilisez le type de données BYTES.
Types de date et d'heure date DATE
time INT64

Spanner n'accepte pas de type de données temporelles dédié. Utilisez INT64 pour stocker la durée en nanosecondes.
timestamp TIMESTAMP
timeuuid STRING(MAX)
Types de conteneurs set ARRAY

Spanner n'accepte pas de type de données set dédié. Utilisez les colonnes ARRAY pour représenter un set.
list ARRAY

Utilisez ARRAY pour stocker une liste d'objets typés.
map JSON

Spanner n'accepte pas de type de carte dédié. Utilisez les colonnes JSON pour représenter les cartes.
Autres types boolean BOOL
counter INT64

Annotations de type de données

L'option de colonne cassandra_type vous permet de définir des mappages entre les types de données Cassandra et Spanner. Lorsque vous créez une table dans Spanner avec laquelle vous prévoyez d'interagir à l'aide de requêtes compatibles avec Cassandra, vous pouvez utiliser l'option cassandra_type pour spécifier le type de données Cassandra correspondant à chaque colonne. Ce mappage est ensuite utilisé par Spanner pour interpréter et convertir correctement les données lors de leur transfert entre les deux systèmes de base de données.

Par exemple, s'il existe une table dans Cassandra avec le schéma suivant :

CREATE TABLE Albums (
  albumId uuid,
  title varchar,
  artists set<varchar>,
  tags  map<varchar, varchar>,
  numberOfSongs tinyint,
  releaseDate date,
  copiesSold bigint,
  score frozen<set<int>>
  ....
  PRIMARY KEY(albumId)
)

Dans Spanner, vous utilisez des annotations de type pour mapper les types de données Cassandra, comme indiqué ci-dessous :

CREATE TABLE Albums (
  albumId       STRING(MAX) OPTIONS (cassandra_type = 'uuid'),
  title         STRING(MAX) OPTIONS (cassandra_type = 'varchar'),
  artists       ARRAY<STRING(max)> OPTIONS (cassandra_type = 'set<varchar>'),
  tags          JSON OPTIONS (cassandra_type = 'map<varchar, varchar>'),
  numberOfSongs INT64 OPTIONS (cassandra_type = 'tinyint'),
  releaseDate   DATE OPTIONS (cassandra_type = 'date'),
  copiesSold    INT64 OPTIONS (cassandra_type = 'bigint'),
  score         ARRAY<INT64> OPTIONS (cassandra_type = 'frozen<set<int>>')
  ...
) PRIMARY KEY (albumId);

Dans l'exemple précédent, la clause OPTIONS mappe le type de données Spanner de la colonne à son type de données Cassandra correspondant.

  • albumId (Spanner STRING(MAX)) est mappé sur uuid dans Cassandra.
  • title (Spanner STRING(MAX)) est mappé sur varchar dans Cassandra.
  • artists (Spanner ARRAY<STRING(MAX)>) est mappé sur set<varchar> dans Cassandra.
  • tags (Spanner JSON) est mappé sur map<varchar,varchar> dans Cassandra.
  • numberOfSongs (Spanner INT64) est mappé sur tinyint dans Cassandra.
  • releaseDate (Spanner DATE) est mappé sur date dans Cassandra.
  • copiesSold (Spanner INT64) est mappé sur bigint dans Cassandra.
  • score (Spanner ARRAY<INT64>) est mappé sur frozen<set<int>> dans Cassandra.
Modifier l'option cassandra_type

Vous pouvez utiliser l'instruction ALTER TABLE pour ajouter ou modifier l'option cassandra_type sur les colonnes existantes.

Pour ajouter une option cassandra_type à une colonne qui n'en comporte pas encore, utilisez l'instruction suivante :

ALTER TABLE Albums ALTER COLUMN uuid SET OPTIONS (cassandra_type='uuid');

Dans cet exemple, la colonne uuid de la table "Albums" est mise à jour avec l'option cassandra_type définie sur uuid.

Pour modifier une option cassandra_type existante, utilisez l'instruction ALTER TABLE avec la nouvelle valeur cassandra_type. Par exemple, pour modifier le cassandra_type de la colonne numberOfSongs dans la table "Albums" de tinyint à bigint, utilisez l'instruction suivante :

ALTER TABLE Albums ALTER COLUMN numberOfSongs SET OPTIONS (cassandra_type='bigint');

Vous n'êtes autorisé à modifier que les types suivants :

De À
tinyint smallint, int, bigint
smallint int, bigint
int bigint
Nombre à virgule flottante double
texte varchar
ascii varchar, text
Mappages directs et nuancés

Dans de nombreux cas, le mappage entre les types de données Spanner et Cassandra est simple. Par exemple, un STRING(MAX) Spanner correspond à un varchar Cassandra, et un INT64 Spanner correspond à un bigint Cassandra.

Toutefois, dans certains cas, le mappage nécessite plus de réflexion et d'ajustements. Par exemple, vous devrez peut-être mapper un smallint Cassandra à un INT64 Spanner.

Fonctions Cassandra compatibles

Cette section liste les fonctions Cassandra compatibles avec Spanner.

La liste suivante indique la compatibilité de Spanner avec les fonctions Cassandra.

Valeur TTL (Time To Live)

Lorsque vous migrez depuis Cassandra, ajoutez une règle de suppression de lignes à votre table Spanner pour utiliser l'option USING TTL dans les instructions INSERT ou UPDATE, ou la valeur TTL Spanner.

La logique TTL de Spanner fonctionne au niveau des lignes, contrairement à Cassandra, où elle peut être appliquée au niveau des cellules. Pour utiliser le TTL Spanner, vous devez inclure une colonne d'horodatage et un intervalle de temps dans la règle de suppression des lignes. Spanner supprime la ligne une fois qu'elle dépasse la durée spécifiée par rapport au code temporel.

La suppression TTL Spanner n'est pas instantanée. Un processus en arrière-plan asynchrone supprime les lignes expirées. La suppression peut prendre jusqu'à 72 heures.

Pour en savoir plus, consultez Activer le TTL sur les données Cassandra.

Fonctionnalités Cassandra non compatibles sur Spanner

Il est important de comprendre que l'interface Cassandra fournit les fonctionnalités de Spanner via des schémas, des types, des requêtes et des clients compatibles avec Cassandra. Il ne prend pas en charge toutes les fonctionnalités de Cassandra. La migration d'une application Cassandra existante vers Spanner, même en utilisant l'interface Cassandra, nécessite probablement un remaniement pour s'adapter aux fonctionnalités Cassandra non compatibles ou aux différences de comportement, comme l'optimisation des requêtes ou la conception de clés primaires. Toutefois, une fois la migration effectuée, vos charges de travail peuvent profiter de la fiabilité et des capacités multimodèles uniques de Spanner.

La liste suivante fournit plus d'informations sur les fonctionnalités Cassandra non compatibles :

  • Certaines fonctionnalités du langage CQL ne sont pas prises en charge : types et fonctions définis par l'utilisateur, timestamp d'écriture.
  • Spanner et plan de contrôle Google Cloud  : les bases de données avec des interfaces Cassandra utilisent Spanner et les outils Google Cloudpour provisionner, sécuriser, surveiller et optimiser les instances. Spanner n'est pas compatible avec les outils tels que nodetool pour les activités administratives.

Compatibilité avec le LDD

Les instructions LDD CQL ne sont pas directement compatibles avec l'interface Cassandra. Pour les modifications DDL, vous devez utiliser la console Spanner Google Cloud , la commande gcloud ou les bibliothèques clientes.

Connectivité

  • Assistance pour les clients Cassandra

    Spanner vous permet de vous connecter à des bases de données à partir de différents clients :

Contrôle des accès avec Identity and Access Management

Vous devez disposer des autorisations spanner.databases.adapt, spanner.databases.select et spanner.databases.write pour effectuer des opérations de lecture et d'écriture sur le point de terminaison Cassandra. Pour en savoir plus, consultez la présentation d'IAM.

Pour savoir comment accorder des autorisations IAM Spanner, consultez Appliquer des rôles IAM.

Surveillance

Spanner fournit les métriques suivantes pour vous aider à surveiller l'adaptateur Cassandra :

  • spanner.googleapis.com/api/adapter_request_count : capture et expose le nombre de requêtes d'adaptateur que Spanner effectue par seconde, ou le nombre d'erreurs qui se produisent sur le serveur Spanner par seconde.
  • spanner.googleapis.com/api/adapter_request_latencies : capture et expose le temps nécessaire à Spanner pour traiter les requêtes de l'adaptateur.

Vous pouvez créer un tableau de bord Cloud Monitoring personnalisé pour afficher et surveiller les métriques de l'adaptateur Cassandra. Le tableau de bord personnalisé contient les graphiques suivants :

  • Latences des requêtes au 99e centile : distribution au 99e centile des latences des requêtes de serveur par message_type pour votre base de données.

  • Latences des requêtes P50 : distribution du 50e centile des latences des requêtes de serveur par message_type pour votre base de données.

  • Nombre de requêtes API par type de message : nombre de requêtes API par message_type pour votre base de données.

  • Nombre de requêtes d'API par type d'opération : nombre de requêtes d'API par op_type pour votre base de données.

  • Taux d'erreur : taux d'erreur de l'API pour votre base de données.

Console Google Cloud

  1. Téléchargez le fichier cassandra-adapter-dashboard.json. Ce fichier contient les informations nécessaires pour remplir un tableau de bord personnalisé dans Monitoring.

  2. Dans la console Google Cloud , accédez à la page  Tableaux de bord :

    Accéder à la page Tableaux de bord

    Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est Monitoring.

  3. Sur la page Aperçu des tableaux de bord, cliquez sur Créer un tableau de bord personnalisé.
  4. Dans la barre d'outils du tableau de bord, cliquez sur l'icône Paramètres du tableau de bord. Sélectionnez ensuite JSON, puis Éditeur JSON.
  5. Dans le volet Éditeur JSON, copiez le contenu du fichier cassandra-adapter-dashboard.json que vous avez téléchargé et collez-le dans l'éditeur.
  6. Pour appliquer vos modifications au tableau de bord, cliquez sur Appliquer les modifications. Si vous ne souhaitez pas utiliser ce tableau de bord, revenez à la page "Présentation des tableaux de bord".
  7. Une fois le tableau de bord créé, cliquez sur Ajouter un filtre. Sélectionnez ensuite project_id ou instance_id pour surveiller l'adaptateur Cassandra.

CLI gcloud

  1. Téléchargez le fichier cassandra-adapter-dashboard.json. Ce fichier contient les informations nécessaires pour remplir un tableau de bord personnalisé dans Monitoring.

  2. Pour créer un tableau de bord dans un projet, utilisez la commande gcloud monitoring dashboards create :

    gcloud monitoring dashboards create --config-from-file=cassandra-adapter-dashboard.json

    Pour en savoir plus, consultez la documentation de référence sur gcloud monitoring dashboards create.

De plus, les métriques Spanner suivantes sont utiles pour surveiller l'adaptateur Cassandra :

Pour obtenir la liste complète des insights système, consultez Surveiller les instances avec les insights système. Pour en savoir plus sur la surveillance de vos ressources Spanner, consultez Surveiller les instances avec Cloud Monitoring.

Tarifs

L'utilisation du point de terminaison Cassandra n'entraîne aucun coût supplémentaire. Vous êtes facturé au tarif standard de Spanner pour la capacité de calcul utilisée par votre instance et pour l'espace de stockage utilisé par votre base de données.

Pour en savoir plus, consultez la page Tarifs de Spanner.

Étapes suivantes