Quando NON usare Cassandra?

Ultimamente si è parlato molto di Cassandra .

Twitter, Digg, Facebook, ecc. Lo usano tutti.

Quando ha senso:

• usa Cassandra,
• non usare Cassandra e
• usa un RDMS invece di Cassandra.

Non c'è niente come un proiettile d'argento, tutto è costruito per risolvere problemi specifici e ha i suoi pro e contro. Spetta a te quale affermazione del problema hai e qual è la soluzione migliore per quel problema.

Proverò a rispondere alle tue domande una ad una nello stesso ordine in cui le hai poste. Poiché Cassandra si basa sulla famiglia di database NoSQL, è importante comprendere perché utilizzare un database NoSQL prima di rispondere alle vostre domande.

Perché usare NoSQL

Nel caso di RDBMS, fare una scelta è abbastanza semplice perché tutti i database come MySQL, Oracle, MS SQL, PostgreSQL in questa categoria offrono quasi lo stesso tipo di soluzioni orientate verso le proprietà ACID. Quando si tratta di NoSQL, la decisione diventa difficile perché ogni database NoSQL offre soluzioni diverse e devi capire quale è la più adatta ai requisiti della tua app / sistema. Ad esempio, MongoDB è adatto ai casi d'uso in cui il sistema richiede un archivio documenti senza schema. HBase potrebbe essere adatto per i motori di ricerca, per l'analisi dei dati di registro o per qualsiasi luogo in cui è richiesta la scansione di enormi tabelle bidimensionali senza join. Redis è stato creato per fornire la ricerca in memoria di varietà di strutture di dati come alberi, code, liste collegate, ecc. E può essere una buona soluzione per creare classifiche in tempo reale, tipo di sistema pub-sub. Allo stesso modo ci sono altri database in questa categoria (compresa Cassandra) che sono adatti per diverse dichiarazioni di problemi. Ora passiamo alle domande originali e rispondiamo una ad una.

Quando usare Cassandra

Facendo parte della famiglia NoSQL, Cassandra offre una soluzione ai problemi in cui uno dei tuoi requisiti è avere un sistema di scrittura molto pesante e vuoi avere un sistema di reporting abbastanza reattivo in cima a quei dati memorizzati. Considerare il caso d'uso dell'analisi dei dati Web in cui sono archiviati i dati di registro per ogni richiesta e si desidera creare una piattaforma analitica attorno ad essa per contare gli hit all'ora, dal browser, dall'IP, ecc. In tempo reale. Puoi fare riferimento a questo post sul blog per capire di più sui casi d'uso in cui si inserisce Cassandra.

Quando utilizzare un RDMS anziché Cassandra

Cassandra si basa su un database NoSQL e non fornisce ACID e proprietà dei dati relazionali. Se hai un forte requisito per le proprietà ACID (ad esempio dati finanziari), Cassandra non sarebbe adatto a quel caso. Ovviamente, puoi fare una soluzione per questo, tuttavia finirai per scrivere un sacco di codice dell'applicazione per simulare le proprietà ACID e perderesti in tempo sul mercato. Anche gestire quel tipo di sistema con Cassandra sarebbe complesso e noioso per te.

Quando non usare Cassandra

Non credo che debba avere una risposta se la spiegazione sopra ha senso.

Quando si valutano i sistemi di dati distribuiti, è necessario considerare il teorema CAP: è possibile selezionare due delle seguenti opzioni: coerenza, disponibilità e tolleranza della partizione.

Cassandra è un sistema disponibile e tollerante alle partizioni che supporta l'eventuale coerenza. Per ulteriori informazioni, consultare questo post sul blog che ho scritto: Guida visiva ai sistemi NoSQL .

Cassandra è la risposta a un problema particolare: cosa fai quando hai così tanti dati che non si adattano a un server? Come memorizzi tutti i tuoi dati su molti server e non rompere il tuo conto bancario e non far impazzire i tuoi sviluppatori? Facebook ottiene 4 Terabyte di nuovi dati compressi OGNI GIORNO. E questo numero molto probabilmente crescerà più di due volte entro un anno.

Se non disponi di così tanti dati o se hai milioni da pagare per l'installazione del cluster Enterprise Oracle / DB2 e per gli specialisti necessari per configurarli e gestirli, allora stai bene con il database SQL.

Tuttavia Facebook non utilizza più cassandra e ora utilizza MySQL spostando quasi esclusivamente il partizionamento nello stack dell'applicazione per prestazioni più veloci e un migliore controllo.

L'idea generale di NoSQL è che dovresti usare qualunque archivio di dati sia la soluzione migliore per la tua applicazione. Se si dispone di una tabella di dati finanziari, utilizzare SQL. Se si dispone di oggetti che richiedono query complesse / lente per il mapping a uno schema relazionale, utilizzare un oggetto o un archivio chiave / valore.

Ovviamente qualsiasi problema del mondo reale in cui ti imbatti è da qualche parte tra quei due estremi e nessuna delle due soluzioni sarà perfetta. È necessario considerare le capacità di ciascun negozio e le conseguenze dell'utilizzo l'uno sull'altro, che saranno molto specifiche del problema che si sta tentando di risolvere.

Oltre alle risposte di cui sopra su quando usare e quando non usare Cassandra, se decidi di usare Cassandra potresti voler considerare di non usare Cassandra stesso, ma uno dei suoi numerosi cugini là fuori.

Alcune risposte sopra hanno già indicato vari sistemi "NoSQL" che condividono molte proprietà con Cassandra, con alcune piccole o grandi differenze, e potrebbero essere migliori della stessa Cassandra per le tue esigenze specifiche.

Inoltre, di recente (diversi anni dopo che questa domanda è stata posta inizialmente), è stato rilasciato un clone di Cassandra chiamato Scylla (vedi https://en.wikipedia.org/wiki/Scylla_(database) ). Scylla è una reimplementazione open source di Cassandra in C ++, che afferma di avere un throughput significativamente più elevato e latenze inferiori rispetto al Cassandra Java originale, pur essendo per lo più compatibile con esso (in funzionalità, API e formati di file). Quindi, se stai già considerando Cassandra, potresti prendere in considerazione anche Scilla.

Parlare con qualcuno nel mezzo dell'implementazione di Cassandra, non gestisce bene il molti-a-molti. Stanno facendo un lavoro di hacking per fare i test iniziali. Ne ho parlato con un consulente Cassandra e mi ha detto che non lo consiglierebbe se si fosse risolto questo problema.

Dovresti porti le seguenti domande:

1. (Volume, Velocità) Scriverai e leggerai TONNELLATE di informazioni, così tante informazioni che nessun computer potrebbe gestire le scritture.
2. (Globale) Avrai bisogno di questa capacità di scrittura e lettura in tutto il mondo in modo che le scritture in una parte del mondo siano accessibili in un'altra parte del mondo?
3. (Affidabilità) È necessario che questo database sia sempre attivo e funzionante e che non vada mai giù, indipendentemente da quale Cloud, quale paese, che sia VM, Container o Bare metal?
4. (Capacità di ridimensionamento ) È necessario questo database per poter continuare a crescere facilmente e ridimensionare in modo lineare
5. (Coerenza) È necessaria la coerenza TUNABLE in cui alcune scritture possono avvenire in modo asincrono, mentre altre devono essere certificate?
6. (Abilità) Sei disposto a fare tutto il necessario per apprendere questa tecnologia e la modellazione dei dati che si accompagna alla creazione di un database distribuito a livello globale che può essere veloce per tutti, ovunque?

Se per una qualsiasi di queste domande hai pensato "forse" o "no", dovresti usare qualcos'altro. Se hai avuto un "inferno sì" come risposta a tutti loro, allora dovresti usare Cassandra.

Usa RDBMS quando puoi fare tutto su una casella. Probabilmente è più facile della maggior parte e chiunque può lavorarci.

Un altro punto da considerare è la pesante query singola rispetto al carico leggero di query gazillion , oltre alle altre risposte qui. È intrinsecamente più difficile ottimizzare automaticamente una singola query in un DB di tipo NoSql. Ho usato MongoDB e ho riscontrato problemi di prestazioni durante il tentativo di calcolare una query complessa. Non ho usato Cassandra ma mi aspetto che abbia lo stesso problema.

D'altra parte, se si prevede che il carico sarà quello di moltissime piccole query e si desidera poter ridimensionare facilmente, è possibile sfruttare l'eventuale coerenza offerta dalla maggior parte dei DB NoSql. Si noti che l'eventuale coerenza non è in realtà una caratteristica di un modello di dati non relazionale, ma è molto più semplice da implementare e configurare in un sistema basato su NoSql.

Per una singola query molto pesante, qualsiasi moderno motore RDBMS può fare un lavoro decente parallelizzando parti della query e trarre vantaggio dalla quantità di CPU e memoria che si lancia su di essa (su una singola macchina). I database NoSql non dispongono di informazioni sufficienti sulla struttura dei dati per poter fare ipotesi che consentano una parallelizzazione veramente intelligente di una query di grandi dimensioni. Ti consentono di ridimensionare facilmente più server (o core) ma una volta che la query raggiunge un livello di complessità sei sostanzialmente costretto a dividerlo manualmente in parti che il motore NoSql sa come gestire in modo intelligente.

Nella mia esperienza con MongoDB, alla fine a causa della complessità della query, Mongo non poteva fare molto per ottimizzarlo ed eseguirne parti su più dati. Mongo parallelizza più query ma non è così bravo a ottimizzarne una singola.

Leggiamo alcuni casi del mondo reale:

http://planetcassandra.org/apache-cassandra-use-cases/

In questo articolo: http://planetcassandra.org/blog/post/agentis-energy-stores-over-15-billion-records-of-time-series-usage-data-in-apache-cassandra

Hanno elaborato il motivo per cui non hanno scelto MySql perché la sincronizzazione dei database è troppo lenta.

(Anche a causa di commit a 2 frasi, FK, PK)

Cassandra si basa sulla carta Amazon Dynamo

Caratteristiche:

Stabilità

Alta disponibilità

Il backup funziona bene

Leggere e scrivere è meglio di HBase, (clone di BigTable in Java).

wiki http://en.wikipedia.org/wiki/Apache_Cassandra

La loro conclusione è:

We looked at HBase, Dynamo, Mongo and Cassandra. 

Cassandra was simply the best storage solution for the majority of our data.

A partire dal 2018,

Consiglierei di usare ScyllaDB per sostituire la classica cassandra, se hai bisogno di supporto per la schiena.

Il plugin Postgres kv è anche veloce di cassandra. Come mai non avrà scalabilità multiistanza.

Mi concentrerò qui su alcuni degli aspetti importanti che possono aiutarti a decidere se hai davvero bisogno di Cassandra. L'elenco non è esaustivo, solo alcuni dei punti che ho in cima alla mia mente-

• Non considerare Cassandra come la prima scelta quando hai un requisito rigoroso sulla relazione (attraverso il tuo set di dati).

• Cassandra per impostazione predefinita è il sistema AP (di CAP). Ma supporta la coerenza sintonizzabile, il che significa che può essere configurato per supportare anche come CP. Quindi non ignorarlo solo perché leggi da qualche parte che è AP e stai cercando sistemi CP.Cassandra è definita in modo più preciso "coerentemente sintonizzabile", il che significa che consente di decidere facilmente il livello di coerenza richiesto, in equilibrio con il livello di disponibilità.

• Non usare Cassandra se la bilancia non è molto o se è possibile gestire un DB non distribuito.

• Pensa di più se il tuo team pensa che tutti i tuoi problemi saranno risolti se usi DB distribuiti come Cassandra. Iniziare con questi DB è molto semplice in quanto presenta molte impostazioni predefinite, ma ottimizzarlo e padroneggiarlo per risolvere un problema specifico richiederebbe una buona (se non molta) fatica ingegneristica.

• Cassandra è orientata alla colonna ma allo stesso tempo ogni riga ha anche una chiave univoca. Pertanto, potrebbe essere utile pensarlo come un negozio indicizzato orientato alle righe. Puoi persino usarlo come archivio documenti.

• Cassandra non ti obbliga a definire i campi in anticipo. Quindi, se sei in una modalità di avvio o le tue funzionalità si stanno evolvendo (come in agile) - Cassandra lo abbraccia. Quindi, prima pensa alle domande e poi pensa ai dati per rispondere.

• Cassandra è ottimizzato per un throughput davvero elevato nelle scritture. Se il tuo caso d'uso è pesante (come la cache), Cassandra potrebbe non essere la scelta ideale.

un'altra situazione che semplifica la scelta è quando si desidera utilizzare la funzione aggregata come somma, min, max, eccetera e query complesse (come nel sistema finanziario sopra menzionato), quindi un database relazionale è probabilmente più conveniente di un database nosql poiché entrambi sono impossibile su un databse nosql a meno che non si utilizzino davvero molti indici invertiti. Quando usi nosql dovresti eseguire le funzioni di aggregazione nel codice o memorizzarle separatamente nella propria famiglia di colonne, ma ciò rende tutto abbastanza complesso e riduce le prestazioni ottenute utilizzando nosql.

Se hai bisogno di un database completamente coerente con semantica SQL, Cassandra NON è la soluzione per te. Cassandra supporta ricerche di valori-chiave. Non supporta le query SQL. I dati in Cassandra sono "eventualmente coerenti". Le ricerche simultanee di dati possono essere incoerenti, ma alla fine le ricerche sono coerenti.

Se hai bisogno di una semantica rigorosa e hai bisogno di supporto per le query SQL, scegli un'altra soluzione come MySQL, PostGres o combina l'uso di Cassandra con Solr.

Cassandra è una buona scelta se:

1. Non sono necessarie le proprietà ACID dal proprio DB.

2. Ci sarebbe un numero enorme e enorme di scritture sul DB.

3. È necessario integrarsi con Big Data, Hadoop, Hive e Spark.

4. Sono necessarie analisi dei dati in tempo reale e generazione di report.

5. È richiesto un meccanismo di tolleranza ai guasti impressionante.

6. C'è un requisito di sistema omogeneo.

7. Sono necessarie molte personalizzazioni per la messa a punto.

Mongodb ha funzioni aggregate molto potenti e un framework aggregato espressivo. Ha molte delle funzionalità che gli sviluppatori sono abituati a utilizzare dal mondo dei database relazionali. La struttura dei dati / archiviazione dei documenti consente, ad esempio, modelli di dati più complessi rispetto a Cassandra.

Tutto questo ovviamente comporta dei compromessi. Quindi quando selezioni il tuo database (NoSQL, NewSQL o RDBMS) guarda quale problema stai cercando di risolvere e le tue esigenze di scalabilità. Nessun database fa tutto.

Secondo DataStax, Cassandra non è il miglior caso d'uso quando è necessario

1- Dispositivi hardware di fascia alta. 2- Conformità ACID senza rollback (transazione bancaria)

• Non supporta la gestione completa delle transazioni tra le tabelle.
• Indice secondario non supportato.
• Devi fare affidamento su Elastic search / Solr per l'indice secondario e il componente di sincronizzazione personalizzato deve essere scritto.
• Sistema non compatibile ACID.
• Il supporto per le query è limitato.

Apache cassandra è un database distribuito per la gestione di grandi quantità di dati strutturati su molti server di prodotti, fornendo al contempo un servizio altamente disponibile e nessun singolo punto di errore.

L'archicettura si basa puramente sul teorema del cap, che è disponibilità e tolleranza di partizione, e in modo interessante eventualmente coerente.

Non utilizzarlo, se non si archiviano volumi di dati su rack di cluster, Non utilizzare se non si memorizzano dati di serie temporali, Non utilizzare se non si brevettano i server, Non utilizzare se si richiede una forte coerenza.