Interfaccia Cassandra

Questa pagina confronta l'architettura di Apache Cassandra e Spanner, oltre a aiutarti a comprendere le funzionalità e i limiti dell'interfaccia Spanner Cassandra. Presuppone che tu abbia familiarità con Cassandra e che tu voglia eseguire la migrazione delle applicazioni esistenti o progettare nuove applicazioni utilizzando Spanner come database.

Cassandra e Spanner sono entrambi database distribuiti su larga scala creati per applicazioni che richiedono elevata scalabilità e bassa latenza. Sebbene entrambi i database possano supportare carichi di lavoro NoSQL impegnativi, Spanner offre funzionalità avanzate per la modellazione, l'interrogazione e le operazioni transazionali dei dati. Per saperne di più su come Spanner soddisfa i criteri dei database NoSQL, consulta Spanner per carichi di lavoro non relazionali.

Concetti principali

Questa sezione confronta i concetti chiave di Cassandra e Spanner.

Terminologia

Cassandra Spanner
Cluster Istanza

Un cluster Cassandra equivale a un'istanza Spanner, ovvero una raccolta di server e risorse di archiviazione. Poiché Spanner è un servizio gestito, non devi configurare l'hardware o il software sottostante. Devi solo specificare la quantità di nodi che vuoi riservare per la tua istanza o utilizzare la scalabilità automatica per scalare automaticamente l'istanza. Un'istanza funge da contenitore per i tuoi database. Scegli anche la topologia di replica dei dati (regionale, a due regioni o multiregionale) a livello di istanza.
Keyspace Database

Uno spazio delle chiavi Cassandra equivale a un database Spanner, ovvero una raccolta di tabelle e altri elementi dello schema (ad esempio indici e ruoli). A differenza di uno spazio delle chiavi, non è necessario configurare la posizione di replica. Spanner replica automaticamente i dati nella regione designata nell'istanza.
Tabella Tabella

Sia in Cassandra che in Spanner, le tabelle sono una raccolta di righe identificate da una chiave primaria specificata nello schema della tabella.
Partizione Divisione

Sia Cassandra che Spanner scalano dividendo i dati. In Cassandra, ogni shard è chiamato partizione, mentre in Spanner, ogni shard è chiamato split. Cassandra utilizza il partizionamento hash, il che significa che ogni riga viene assegnata in modo indipendente a un nodo di archiviazione in base a un hash della chiave primaria. Spanner è partizionato per intervallo, il che significa che le righe contigue nello spazio delle chiavi della chiave primaria sono contigue anche nell'archiviazione (tranne ai confini della suddivisione). Spanner si occupa della suddivisione e dell'unione in base al carico e allo spazio di archiviazione, e questo è trasparente per l'applicazione. La principale implicazione è che, a differenza di Cassandra, le scansioni di intervalli su un prefisso della chiave primaria sono un'operazione efficiente in Spanner.
Riga Riga

Sia in Cassandra che in Spanner, una riga è una raccolta di colonne identificate in modo univoco da una chiave primaria. Come Cassandra, Spanner supporta le chiavi primarie composite. A differenza di Cassandra, Spanner non fa distinzione tra la chiave di partizione e le colonne di clustering, perché i dati sono suddivisi in intervalli. Puoi pensare a Spanner come se avesse solo colonne di clustering, con il partizionamento gestito in background.
Colonna Colonna

Sia in Cassandra che in Spanner, una colonna è un insieme di valori di dati dello stesso tipo. Esiste un valore per ogni riga di una tabella. Per saperne di più sul confronto tra i tipi di colonne Cassandra e Spanner, vedi Tipi di dati.

Architettura

Un cluster Cassandra è costituito da un insieme di server e spazio di archiviazione collocato con questi server. Una funzione hash mappa le righe di uno spazio delle chiavi di partizione a un nodo virtuale (vnode). Un insieme di vnode viene quindi assegnato in modo casuale a ogni server per gestire una parte dello spazio delle chiavi del cluster. Lo spazio di archiviazione per i vnode è collegato localmente al nodo di servizio. I driver client si connettono direttamente ai nodi di servizio e gestiscono il bilanciamento del carico e il routing delle query.

Un'istanza Spanner è costituita da un insieme di server in una topologia di replica. Spanner divide dinamicamente ogni tabella in intervalli di righe in base all'utilizzo di CPU e disco. Gli shard vengono assegnati ai nodi di computing per la pubblicazione. I dati sono archiviati fisicamente su Colossus, il file system distribuito di Google, separati dai nodi di calcolo. I driver client si connettono ai server frontend di Spanner, che eseguono il routing delle richieste e il bilanciamento del carico. Per saperne di più, consulta il white paper sul ciclo di vita delle letture e delle scritture di Spanner.

A livello generale, entrambe le architetture scalano man mano che le risorse vengono aggiunte al cluster sottostante. La separazione tra calcolo e archiviazione di Spanner consente di ribilanciare più rapidamente il carico tra i nodi di calcolo in risposta alle modifiche del carico di lavoro. A differenza di Cassandra, gli spostamenti degli shard non comportano spostamenti di dati, in quanto i dati rimangono su Colossus. Inoltre, il partizionamento basato sull'intervallo di Spanner potrebbe essere più naturale per le applicazioni che prevedono l'ordinamento dei dati in base alla chiave di partizionamento. Il rovescio della medaglia del partizionamento basato sull'intervallo è che i carichi di lavoro che scrivono a un'estremità dello spazio delle chiavi (ad esempio, tabelle con chiave in base al timestamp corrente) potrebbero avere hotspot se non vengono presi in considerazione ulteriori progetti di schema. Per saperne di più sulle tecniche per superare gli hotspot, consulta Best practice per la progettazione degli schemi.

Coerenza

Con Cassandra, devi specificare un livello di coerenza per ogni operazione. Se utilizzi il livello di coerenza del quorum, la maggior parte dei nodi replica deve rispondere al nodo coordinatore affinché l'operazione venga considerata riuscita. Se utilizzi un livello di coerenza pari a 1, Cassandra ha bisogno di un singolo nodo replica per rispondere affinché l'operazione venga considerata riuscita.

Spanner offre una elevata coerenza. L'API Spanner non espone le repliche al client. I client Spanner interagiscono con Spanner come se fosse un database di una singola macchina. Una scrittura viene sempre eseguita sulla maggior parte delle repliche prima che Spanner ne comunichi l'esito positivo all'utente. Le letture successive riflettono i dati appena scritti. Le applicazioni possono scegliere di leggere uno snapshot del database in un momento del passato, il che potrebbe offrire vantaggi in termini di prestazioni rispetto alle letture coerenti. Per ulteriori informazioni sulle proprietà di coerenza di Spanner, consulta la panoramica delle transazioni.

Spanner è stato creato per supportare la coerenza e la disponibilità necessarie nelle applicazioni su larga scala. Spanner offre una coerenza solida su larga scala e con prestazioni elevate. Per i casi d'uso che lo richiedono, Spanner supporta letture istantanee (obsolete) che allentano i requisiti di aggiornamento.

Interfaccia Cassandra

L'interfaccia Cassandra ti consente di sfruttare l'infrastruttura completamente gestita, scalabile e a disponibilità elevata di Spanner utilizzando strumenti e sintassi di Cassandra familiari. Questa pagina ti aiuta a comprendere le funzionalità e i limiti dell'interfaccia Cassandra.

Vantaggi dell'interfaccia Cassandra

  • Portabilità: l'interfaccia Cassandra fornisce l'accesso all'ampia gamma di funzionalità di Spanner, utilizzando schemi, query e client compatibili con Cassandra. In questo modo è più semplice spostare un'applicazione basata su Spanner in un altro ambiente Cassandra o viceversa. Questa portabilità offre flessibilità di deployment e supporta scenari diripristino di emergenzay, come un'uscita forzata.
  • Familiarità: se utilizzi già Cassandra, puoi iniziare rapidamente a utilizzare Spanner utilizzando molte delle stesse istruzioni e tipi CQL.
  • Spanner senza compromessi: poiché è basata sulla base esistente di Spanner, l'interfaccia Cassandra offre tutti i vantaggi esistenti di disponibilità, coerenza e rapporto prezzo/prestazioni di Spanner senza dover scendere a compromessi su nessuna delle funzionalità disponibili nell'ecosistema GoogleSQL complementare.

Compatibilità CQL

  • Supporto del dialetto CQL: Spanner fornisce un sottoinsieme del dialetto CQL, tra cui Data Query Language (DQL), Data Manipulation Language (DML), transazioni leggere (LWT), funzioni di aggregazione e data/ora.

  • Funzionalità Cassandra supportate: l'interfaccia Cassandra supporta molte delle funzionalità di Cassandra più utilizzate. Sono inclusi i componenti principali dello schema e del sistema di tipi, molte forme di query comuni, una serie di funzioni e operatori e gli aspetti chiave del catalogo di sistema di Cassandra. Le applicazioni possono utilizzare molti client o driver Cassandra connettendosi tramite l'implementazione di Spanner del protocollo di rete Cassandra.

  • Supporto del client e del protocollo di rete: Spanner supporta le funzionalità di query di base del protocollo di rete Cassandra v4 utilizzando Cassandra Adapter, un client leggero che viene eseguito insieme all'applicazione. In questo modo, molti client Cassandra funzionano così come sono con un database di interfaccia Spanner Cassandra, sfruttando la gestione delle connessioni e dell'endpoint globale di Spanner e l'autenticazione IAM.

Tipi di dati Cassandra supportati

La tabella seguente mostra i tipi di dati Cassandra supportati e mappa ciascun tipo di dati al tipo di dati GoogleSQL Spanner equivalente.

Tipi di dati Cassandra supportati Tipo di dati GoogleSQL di Spanner
Tipi numerici tinyint (numero intero con segno a 8 bit) INT64 (numero intero firmato a 64 bit)

Spanner supporta un singolo tipo di dati a 64 bit per i numeri interi con segno.

smallint (numero intero con segno a 16 bit)
int (intero con segno a 32 bit)
bigint (numero intero firmato a 64 bit)
float (virgola mobile IEEE-754 a 32 bit) FLOAT32 (virgola mobile IEEE-754 a 32 bit)
double (virgola mobile IEEE-754 a 64 bit) FLOAT64 (virgola mobile IEEE-754 a 64 bit)
decimal Per i numeri decimali a precisione fissa, utilizza il tipo di dati NUMERIC (precisione 38, scala 9).
varint (numero intero a precisione variabile)
Tipi di stringa text STRING(MAX)

text e varchar memorizzano e convalidano le stringhe UTF-8. In Spanner, le colonne STRING devono specificare la lunghezza massima. Non influisce sullo spazio di archiviazione; serve a scopo di convalida.

varchar
ascii STRING(MAX)
uuid STRING(MAX)
inet STRING(MAX)
blob BYTES(MAX)

Per archiviare dati binari, utilizza il tipo di dati BYTES.

Tipi di data e ora date DATE
time INT64

Spanner non supporta un tipo di dati temporali dedicato. Utilizza INT64 per memorizzare la durata in nanosecondi.

timestamp TIMESTAMP
timeuuid STRING(MAX)
Tipi di container set ARRAY

Spanner non supporta un tipo di dati set dedicato. Utilizza le colonne ARRAY per rappresentare un set.

list ARRAY

Utilizza ARRAY per archiviare un elenco di oggetti digitati.

map JSON

Spanner non supporta un tipo di mappa dedicato. Utilizza le colonne JSON per rappresentare le mappe.

Altri tipi boolean BOOL
counter INT64

Annotazioni del tipo di dati

L'opzione della colonna cassandra_type consente di definire le mappature tra i tipi di dati Cassandra e Spanner. Quando crei una tabella in Spanner con cui intendi interagire utilizzando query compatibili con Cassandra, puoi utilizzare l'opzione cassandra_type per specificare il tipo di dati Cassandra corrispondente per ogni colonna. Questa mappatura viene quindi utilizzata da Spanner per interpretare e convertire correttamente i dati durante il trasferimento tra i due sistemi di database.

Ad esempio, se in Cassandra è presente una tabella con il seguente schema:

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)
)

In Spanner, utilizzi le annotazioni di tipo per eseguire il mapping ai tipi di dati Cassandra, come mostrato di seguito:

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);

Nell'esempio precedente, la clausola OPTIONS mappa il tipo di dati Spanner della colonna al tipo di dati Cassandra corrispondente.

  • albumId (Spanner STRING(MAX)) è mappato a uuid in Cassandra.
  • title (Spanner STRING(MAX)) è mappato a varchar in Cassandra.
  • artists (Spanner ARRAY<STRING(MAX)>) è mappato a set<varchar> in Cassandra.
  • tags (Spanner JSON) viene mappato a map<varchar,varchar> in Cassandra.
  • numberOfSongs (Spanner INT64) è mappato a tinyint in Cassandra.
  • releaseDate (Spanner DATE) è mappato a date in Cassandra.
  • copiesSold (Spanner INT64) è mappato a bigint in Cassandra.
  • score (Spanner ARRAY<INT64>) è mappato a frozen<set<int>> in Cassandra.
Modificare l'opzione cassandra_type

Puoi utilizzare l'istruzione ALTER TABLE per aggiungere o modificare l'opzione cassandra_type nelle colonne esistenti.

Per aggiungere un'opzione cassandra_type a una colonna che ancora non la include, utilizza la seguente istruzione:

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

In questo esempio, la colonna uuid della tabella Album viene aggiornata con l'opzione cassandra_type impostata su uuid.

Per modificare un'opzione cassandra_type esistente, utilizza l'istruzione ALTER TABLE con il nuovo valore cassandra_type. Ad esempio, per modificare il cassandra_type della colonna numberOfSongs nella tabella Albums da tinyint a bigint, utilizza la seguente istruzione:

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

Puoi modificare solo i seguenti tipi:

Da A
tinyint smallint, int, bigint
smallint int, bigint
int bigint
float double
testo varchar
ascii varchar, text
Mappature dirette e sfumate

In molti casi, la mappatura tra i tipi di dati Spanner e Cassandra è semplice. Ad esempio, un STRING(MAX) Spanner corrisponde a un varchar Cassandra e un INT64 Spanner corrisponde a un bigint Cassandra.

Tuttavia, ci sono situazioni in cui la mappatura richiede maggiore attenzione e modifica. Ad esempio, potresti dover mappare un smallint di Cassandra a un INT64 di Spanner.

Funzioni Cassandra supportate

Questa sezione elenca le funzioni Cassandra supportate in Spanner.

Il seguente elenco mostra il supporto di Spanner per le funzioni Cassandra.

Durata (TTL)

Quando esegui la migrazione da Cassandra, aggiungi una policy di eliminazione delle righe alla tabella Spanner per utilizzare l'opzione USING TTL nelle istruzioni INSERT o UPDATE o il TTL di Spanner.

La logica TTL di Spanner opera a livello di riga, a differenza di Cassandra, dove la logica TTL può essere applicata a livello di cella. Per utilizzare il TTL di Spanner, devi includere una colonna timestamp e un intervallo di tempo nel criterio di eliminazione delle righe. Spanner elimina la riga dopo che la riga supera la durata specificata rispetto al timestamp.

L'eliminazione del TTL di Spanner non è istantanea. Un processo asincrono in background elimina le righe scadute e le eliminazioni possono richiedere fino a 72 ore.

Per maggiori informazioni, vedi Attivare il TTL per i dati Cassandra.

Funzionalità di Cassandra non supportate su Spanner

È importante capire che l'interfaccia Cassandra fornisce le funzionalità di Spanner tramite schemi, tipi, query e client compatibili con Cassandra. Non supporta tutte le funzionalità di Cassandra. La migrazione di un'applicazione Cassandra esistente a Spanner, anche utilizzando l'interfaccia Cassandra, richiede probabilmente alcune modifiche per adattarsi alle funzionalità di Cassandra non supportate o alle differenze di comportamento, come l'ottimizzazione delle query o la progettazichiave primariaarie. Tuttavia, una volta eseguita la migrazione, i tuoi carichi di lavoro possono sfruttare l'affidabilità e le funzionalità multimodello uniche di Spanner.

Il seguente elenco fornisce ulteriori informazioni sulle funzionalità di Cassandra non supportate:

  • Alcune funzionalità del linguaggio CQL non sono supportate: tipi e funzioni definiti dall'utente, write-timestamp.
  • Spanner e Google Cloud control plane: i database con interfacce Cassandra utilizzano Spanner e Google Cloud strumenti per eseguire il provisioning, proteggere, monitorare e ottimizzare le istanze. Spanner non supporta strumenti come nodetool per le attività amministrative.

Supporto DDL

Le istruzioni DDL CQL non sono supportate direttamente tramite l'interfaccia Cassandra. Per le modifiche DDL, devi utilizzare la console Spanner Google Cloud , il comando gcloud o le librerie client.

Connettività

Controllo dell'accesso con Identity and Access Management

Per eseguire operazioni di lettura e scrittura sull'endpoint Cassandra, devi disporre delle autorizzazioni spanner.databases.adapt, spanner.databases.select e spanner.databases.write. Per ulteriori informazioni, consulta la panoramica di IAM.

Per saperne di più su come concedere le autorizzazioni IAM di Spanner, consulta Applicare i ruoli IAM.

Monitoraggio

Spanner fornisce le seguenti metriche per aiutarti a monitorare l'adattatore Cassandra:

  • spanner.googleapis.com/api/adapter_request_count: acquisisce ed espone il numero di richieste dell'adattatore eseguite da Spanner al secondo o il numero di errori che si verificano sul server Spanner al secondo.
  • spanner.googleapis.com/api/adapter_request_latencies: acquisisce ed espone il tempo impiegato da Spanner per gestire le richieste dell'adattatore.

Puoi creare una dashboard di Cloud Monitoring personalizzata per visualizzare e monitorare le metriche per l'adattatore Cassandra. La dashboard personalizzata contiene i seguenti grafici:

  • Latenze di richiesta P99: la distribuzione del 99° percentile delle latenze di richiesta del server per message_type per il tuo database.

  • Latenze di richiesta P50: la distribuzione del 50° percentile delle latenze di richiesta del server per message_type per il tuo database.

  • Conteggio richieste API per tipo di messaggio: il conteggio delle richieste API per message_type per il tuo database.

  • Conteggio richieste API per tipo di operazione: il conteggio delle richieste API per op_type per il tuo database.

  • Tassi di errore: i tassi di errore dell'API per il tuo database.

Console Google Cloud

  1. Scarica il file cassandra-adapter-dashboard.json. Questo file contiene le informazioni necessarie per compilare una dashboard personalizzata in Monitoring.
  2. Nella console Google Cloud , vai alla pagina  Dashboard:

    Vai a Dashboard

    Se utilizzi la barra di ricerca per trovare questa pagina, seleziona il risultato con il sottotitolo Monitoring.

  3. Nella pagina Panoramica delle dashboard, fai clic su Crea dashboard personalizzata.
  4. Nella barra degli strumenti della dashboard, fai clic sull'icona Impostazioni dashboard. Poi seleziona JSON e poi Editor JSON.
  5. Nel riquadro Editor JSON, copia i contenuti del file cassandra-adapter-dashboard.json scaricato e incollali nell'editor.
  6. Per applicare le modifiche alla dashboard, fai clic su Applica modifiche. Se non vuoi utilizzare questa dashboard, torna alla pagina Panoramica delle dashboard.
  7. Dopo aver creato il prospetto, fai clic su Aggiungi filtro. Poi seleziona project_id o instance_id per monitorare l'adattatore Cassandra.

Interfaccia a riga di comando gcloud

  1. Scarica il file cassandra-adapter-dashboard.json. Questo file contiene le informazioni necessarie per compilare una dashboard personalizzata in Monitoring.
  2. Per creare un dashboard in un progetto, utilizza il comando gcloud monitoring dashboards create:

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

    Per ulteriori informazioni, consulta il riferimento gcloud monitoring dashboards create.

Inoltre, le seguenti metriche di Spanner sono utili per monitorare l'adattatore Cassandra:

Per un elenco completo degli approfondimenti di sistema, consulta Monitorare le istanze con gli approfondimenti di sistema. Per scoprire di più sul monitoraggio delle risorse Spanner, consulta Monitorare le istanze con Cloud Monitoring.

Prezzi

Non sono previsti costi aggiuntivi per l'utilizzo dell'endpoint Cassandra. Ti viene addebitato il prezzo standard di Spanner per la quantità di capacità di calcolo utilizzata dall'istanza e per la quantità di spazio di archiviazione utilizzata dal database.

Per ulteriori informazioni, consulta la pagina Prezzi di Spanner.

Passaggi successivi