Domande frequenti su Azure Cosmos DB for Apache Cassandra

Ecco alcune differenze principali tra l'API per il servizio Cassandra e Apache Cassandra:

• Apache Cassandra consiglia un limite di 100 MB per le dimensioni di una chiave di partizione. L'API Azure Cosmos DB for Apache Cassandra consente fino a 20 GB per partizione.
• Apache Cassandra consente di disabilitare i commit durevoli. È possibile ignorare la scrittura nel log di commit e passare direttamente alla struttura dei dati in memoria. Ciò può causare la perdita di dati se il nodo si arresta prima che le strutture di dati in memoria vengano scaricate su SSTable su disco. Azure Cosmos DB esegue sempre commit durevoli per evitare la perdita di dati.
• In Apache Cassandra possono verificarsi riduzioni delle prestazioni se il carico di lavoro richiede molte sostituzioni o eliminazioni. Questo è causato dalle rimozioni definitive che il carico di lavoro di lettura deve superare per recuperare i dati più recenti. Nell'API per Cassandra non si verificano riduzioni delle prestazioni di lettura quando il carico di lavoro include molte sostituzioni o eliminazioni.
• Negli scenari con elevati carichi di lavoro di sostituzione, è necessario eseguire la compattazione per unire le SSTable su disco (l'unione è necessaria perché le scritture di Apache Cassandra sono di solo accodamento e vengono archiviati più aggiornamenti come singole voci SSTable, da unire periodicamente). Questo può anche comportare una riduzione delle prestazioni di lettura durante la compattazione. Questo impatto sulle prestazioni non si verifica nell'API per Cassandra perché l'API non implementa la compattazione.
• Con Apache Cassandra è possibile impostare un fattore di replica 1. Questo, però, determina una disponibilità bassa se l'unico nodo con i dati non funziona. Questo problema non si verifica con l'API Azure Cosmos DB for Apache Cassandra perché c'è sempre un fattore di replica 4 (quorum di 3).
• L'aggiunta o la rimozione di nodi in Apache Cassandra richiede l'intervento manuale, nonché un utilizzo elevato della CPU nel nuovo nodo, mentre i nodi esistenti spostano alcuni intervalli di token nel nuovo nodo. La situazione è uguale quando si rimuovono le autorizzazioni da un nodo esistente. Tuttavia, l'API per Cassandra aumenta la capacità senza problemi a livello di servizio o applicazione.
• Non è necessario impostare num_tokens su ogni nodo nel cluster come in Apache Cassandra. Azure Cosmos DB gestisce completamente i nodi e gli intervalli di token.
• L'API per Cassandra è completamente gestita. Non sono necessari i comandi, come la riparazione o la rimozione di autorizzazione, che vengono usati in Apache Cassandra.

L'API Azure Cosmos DB for Apache Cassandra supporta la versione 3.x di Cassandra Query Language (CQL). La compatibilità CQL è basata sul repository GitHub Apache Cassandra pubblico. In caso di feedback sul supporto di altri protocolli,inviare un messaggio di posta elettronica all'indirizzo askcosmosdbcassandra@microsoft.com.

Azure Cosmos DB configura la velocità effettiva predefinita per il contenitore in base alla posizione in cui è stata creata la tabella, ovvero nel portale di Azure o in CQL.

Azure Cosmos DB offre garanzie di prestazioni e latenza, con limiti superiori nelle operazioni. Queste garanzie sono possibili quando il motore può applicare la governance nelle operazioni del tenant. La configurazione della velocità effettiva assicura la velocità effettiva e la latenza garantite, perché la piattaforma riserva tale capacità e garantisce l'esito positivo delle operazioni. È possibile modificare in modo flessibile la velocità effettiva per usufruire della stagionalità delle applicazioni e ridurre i costi.

Il concetto di velocità effettiva è illustrato nell'articolo Unità richiesta in Azure Cosmos DB. La velocità effettiva per una tabella viene distribuita equamente tra le partizioni fisiche sottostanti.

Azure Cosmos DB usa le unità richiesta al secondo (UR/s) come misura per fornire la velocità effettiva. Per impostazione predefinita, le tabelle create con CQL hanno 400 UR. È possibile modificare le UR dal portale di Azure.

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 offre garanzie di prestazioni e latenza, con limiti superiori nelle operazioni. Queste garanzie sono possibili quando il motore può applicare la governance nelle operazioni del tenant. La configurazione della velocità effettiva assicura la velocità effettiva e la latenza garantite, perché la piattaforma riserva tale capacità e garantisce l'esito positivo delle operazioni.

Quando si supera questa capacità, viene visualizzato il seguente messaggio di errore che indica che è stata superata la capacità:

0x1001 Overloaded: the request can't be processed because "Request Rate is large" (0x1001 In overload: impossibile elaborare la richiesta perché "La frequenza delle richieste è troppo elevata")

È essenziale esaminare le operazioni che, unitamente al loro volume, determinano questo problema. Le metriche del portale di Azure consentono di avere un'idea della capacità utilizzata che supera la capacità di cui è stato effettuato il provisioning. È poi necessario verificare che la capacità venga usata pressoché equamente tra tutte le partizioni sottostanti. Se si nota che la maggior parte della velocità effettiva viene usata da una partizione, si è in presenza di un'asimmetria del carico di lavoro.

Sono disponibili metriche che indicano in che modo la velocità effettiva viene usata in intervalli di ore, giorni e sette giorni, nelle varie partizioni o in modo aggregato. Per altre informazioni, vedere Eseguire il monitoraggio e il debug con le metriche in Azure Cosmos DB.

I log di diagnostica sono illustrati nell'articolo Registrazione diagnostica di Azure Cosmos DB.

Sì, la chiave di partizione viene usata per collocare l'entità nella posizione corretta. In Azure Cosmos DB consente di individuare la partizione logica corretta archiviata in una partizione fisica. Il concetto di partizionamento è illustrato in dettaglio nell'articolo Partizionamento e ridimensionamento in Azure Cosmos DB. Il fulcro della questione è che una partizione logica non deve superare il limite di 20 GB.

Azure Cosmos DB è un sistema basato su contratti di servizio. Offre scalabilità illimitata, con garanzie per quanto riguarda latenza, velocità effettiva, disponibilità e coerenza. Questo tipo di archiviazione illimitata si basa sull'aumento del numero di istanze per i dati usando il partizionamento come concetto chiave. Il concetto di partizionamento è illustrato in dettaglio nell'articolo Partizionamento e ridimensionamento in Azure Cosmos DB.

È necessario rispettare il limite di 20 GB sul numero di entità o elementi per partizione logica. Per assicurare la scalabilità dell'applicazione, è consigliabile non creare una partizione critica archiviando tutte le informazioni in una partizione ed eseguendo query su di essa. Questo errore può verificarsi solo in presenza di dati asimmetrici, ovvero con un numero elevato di dati per una chiave di partizione (più di 20 GB). La distribuzione dei dati è disponibile tramite il portale di archiviazione. Per correggere l'errore, occorre creare nuovamente la tabella e scegliere una chiave primaria (di partizione) granulare, per una migliore distribuzione dei dati.

Azure Cosmos DB può archiviare un numero illimitato di dati grazie alla scalabilità orizzontale di archiviazione, in modo indipendente dalla velocità effettiva. Sì, è comunque possibile usare l'API per Cassandra semplicemente per archiviare e recuperare chiavi e valori specificando la chiave primaria o di partizione corretta. Queste singole chiavi ottengono una specifica partizione logica e si trovano al di sopra della partizione fisica.

Sì, è possibile creare più di una tabella con l'API per Cassandra. Ogni tabella viene trattata come una singola unità per velocità effettiva e archiviazione.

Azure Cosmos DB è un sistema basato su risorse per attività a livello di dati e di controllo. I contenitori come le raccolte e le tabelle sono entità di runtime sottoposte a provisioning per una determinata capacità di velocità effettiva. La creazione di questi contenitori in rapida successione non è un'attività prevista e potrebbe essere limitata. Se si hanno test che creano o eliminano tabelle immediatamente, provare a distanziarli.

Non esiste alcun limite fisico al numero di tabelle. Se è necessario creare un numero elevato di tabelle (con una dimensione totale che supera regolarmente i 10 TB di data), anziché le consuete decine o centinaia, inviare un messaggio di posta elettronica all'indirizzo askcosmosdbcassandra@microsoft.com.

Non esiste alcun limite fisico al numero di keyspace perché si tratta di contenitori di metadati. Se si ha un numero elevato di keyspace, inviare un messaggio di posta elettronica all'indirizzo askcosmosdbcassandra@microsoft.com.

Sì. Supponendo che le partizioni siano distribuite in modo uniforme, la capacità di archiviazione viene gestita automaticamente e aumenta con l'inserimento di dati aggiuntivi. È quindi possibile importare tranquillamente la quantità di dati necessaria senza la gestione e il provisioning dei nodi e così via. Se però si prevede una crescita elevata di dati nell'immediato, è preferibile eseguire direttamente il provisioning della velocità effettiva prevista piuttosto che iniziare con una quantità limitata e aumentarla subito.

L'API Azure Cosmos DB for Apache Cassandra fornisce compatibilità a livello di protocollo per l'esecuzione di operazioni. Nasconde la complessità della gestione, del monitoraggio e della configurazione. Gli utenti e gli sviluppatori non devono preoccuparsi di disponibilità, rimozioni definitive, cache delle chiavi, cache delle righe, filtri Bloom e di molte altre impostazioni. L'API per Cassandra fornisce le prestazioni di lettura e di scrittura necessarie, senza il carico di configurazione e gestione.

L'API per Cassandra semplifica la pianificazione della capacità e la risposta a richieste di elasticità per la velocità effettiva e le risorse di archiviazione. Con Azure Cosmos DB è possibile effettuare il provisioning della velocità effettiva necessaria. È quindi possibile aumentare o ridurre il numero di unità ogni volta che risulta necessario durante la giornata, senza doversi preoccupare di aggiungere, eliminare o gestire i nodi. Non è necessario usare strumenti per la gestione di nodi e cluster.

Azure Cosmos DB offre la distribuzione globale predefinita per motivi di disponibilità e di bassa latenza. Non è necessario configurare repliche o altro. Viene eseguito il commit durevole nel quorum di tutte le operazioni di scrittura in qualsiasi area in cui vengono scritti i dati, fornendo al tempo stesso garanzie relative alle prestazioni.

Azure Cosmos DB offre garanzie di prestazioni per lettura, scrittura e velocità effettiva. In questo modo si elimina la preoccupazione di toccare e modificare accidentalmente le impostazioni di configurazione. Queste impostazioni includono bloom filter, caching, read repair chance, gc_grace e compression memtable_flush_period.

Sì, la Durata (TTL) è supportata.

Azure Cosmos DB è un servizio di piattaforma che consente di incrementare la produttività, senza doversi preoccupare della gestione e del monitoraggio dell'infrastruttura. Ad esempio, non è necessario monitorare in anticipo lo stato dei nodi, lo stato delle repliche, gc e parametri del sistema operativo con vari strumenti. È sufficiente occuparsi della velocità effettiva disponibile nelle metriche del portale per individuare eventuali limitazioni delle richieste e aumentare o diminuire la velocità effettiva. È possibile:

• Monitorare i contratti di servizio
• Usare le metriche
• Usare i log di diagnostica

Per i programmi client sono stati usati i driver del client Apache Cassandra SDK che usano CQLv3. In caso di uso di altri driver o se si verificano problemi, inviare un messaggio di posta elettronica all'indirizzo askcosmosdbcassandra@microsoft.com.

Sì, è possibile usare la sintassi normale per creare chiavi di partizione composte.

No, sstableloader non è supportato.

Attualmente Azure Cosmos DB offre un'esperienza ottimizzata per un ambiente cloud, senza il carico delle operazioni. Se è necessaria l'associazione, inviare un messaggio di posta elettronica all'indirizzo askcosmosdbcassandra@microsoft.com con una descrizione dello scenario. Stiamo lavorando a un'offerta che consenta di associare il cluster Cassandra locale o cloud all'API Azure Cosmos DB for Apache Cassandra.

Azure Cosmos DB fornisce due backup completi gratuiti, creati a intervalli di quattro ore, in tutte le API. Non è quindi necessario configurare una pianificazione dei backup.

La conservazione e la frequenza dei backup possono essere gestite manualmente.

Per eseguire un ripristino da backup, inviare un messaggio di posta elettronica all'indirizzo askcosmosdbcassandra@microsoft.com o aprire un caso di supporto. Informazioni sulla funzionalità di backup sono disponibili nell'articolo Backup online automatico e ripristino con Azure Cosmos DB.

L'API per Cassandra sfrutta la piattaforma distribuita a livello globale di Azure Cosmos DB. Affinché l'applicazione possa tollerare i tempi di inattività del data center, abilitare almeno un'altra area per l'account nel portale di Azure. Per altre informazioni, vedere Disponibilità elevata con Azure Cosmos DB.

È possibile aggiungere il numero di aree desiderato per l'account e controllare in quale potrà essere effettuato il failover specificando una priorità di failover. Per usare il database, è necessario includere anche un'applicazione. Nel corso di questa operazione, i clienti non riscontrano tempi di inattività.

No. L'API per Cassandra supporta indici secondari che si comportano in modo analogo ad Apache Cassandra. Per impostazione predefinita, l'API non indicizza tutti gli attributi.

Sì, è possibile. Per informazioni dettagliate su come abilitare questa impostazione, vedere l'articolo Usare l'emulatore di Azure Cosmos DB per sviluppo e test locali.

Per informazioni sulle opzioni di migrazione, vedere l'esercitazione relativa alla migrazione dei dati in un account di API per Cassandra in Azure Cosmos DB.

Contenuto correlato

• Introduzione alla scalabilità elastica di un account Azure Cosmos DB for Apache Cassandra

Passaggio successivo