Elaborazione dati su larga scala Hbase vs Cassandra [chiuso]


84

Sono quasi arrivato a Cassandra dopo la mia ricerca su soluzioni di archiviazione dati su larga scala. Ma è generalmente detto che Hbase è la soluzione migliore per l'elaborazione e l'analisi dei dati su larga scala.

Sebbene entrambi siano la stessa memoria chiave / valore ed entrambi siano / possano eseguire (Cassandra di recente) il livello Hadoop, ciò che rende Hadoop un candidato migliore quando l'elaborazione / analisi è richiesta su dati di grandi dimensioni.

Ho anche trovato buoni dettagli su entrambi su http://ria101.wordpress.com/2010/02/24/hbase-vs-cassandra-why-we-moved/

ma sto ancora cercando vantaggi concreti di Hbase.

Mentre sono più convinto di Cassandra perché la sua semplicità per l'aggiunta di nodi e la replica senza interruzioni e le funzionalità senza punto di errore. E mantiene anche la funzionalità dell'indice secondario, quindi è un buon vantaggio.

Risposte:


91

Cercare di determinare quale sia il migliore per te dipende davvero da come lo utilizzerai, ognuno di loro ha i suoi vantaggi e senza ulteriori dettagli diventa più una guerra di religione. Anche il post a cui hai fatto riferimento ha più di un anno ed entrambi hanno subito molti cambiamenti da allora. Tieni inoltre presente che non ho familiarità con i più recenti sviluppi di Cassandra.

Detto questo, parafraserò il committer di HBase Andrew Mal e aggiungerò alcune delle mie esperienze:

  • HBase è in ambienti di produzione più grandi (1000 nodi) sebbene sia ancora nello stadio di baseball delle installazioni di ~ 400 nodi di Cassandra, quindi è davvero una differenza marginale.

  • Sia HBase che Cassandra supportano la replica tra cluster / data center. Credo che HBase esponga di più all'utente, quindi sembra più complicato, ma poi ottieni anche maggiore flessibilità.

  • Se una forte coerenza è ciò di cui la tua applicazione ha bisogno, HBase è probabilmente una soluzione migliore. È stato progettato da zero per essere coerente. Ad esempio, consente un'implementazione più semplice dei contatori atomici (penso che Cassandra li abbia appena ricevuti) così come le operazioni Check and Put.

  • Le prestazioni di scrittura sono fantastiche, da quello che ho capito che è stato uno dei motivi per cui Facebook ha scelto HBase per il loro messenger.

  • Non sono sicuro dello stato attuale del partizionatore ordinato di Cassandra, ma in passato richiedeva un ribilanciamento manuale. HBase lo gestisce per te, se lo desideri. Il partitioner ordinato è importante per l'elaborazione in stile Hadoop.

  • Cassandra e HBase sono entrambi complessi, Cassandra lo nasconde meglio. HBase lo espone di più utilizzando HDFS per la sua memorizzazione, se si guarda alla base di codice Cassandra è altrettanto stratificata. Se si confrontano i documenti di Dynamo e Bigtable si può vedere che la teoria del funzionamento di Cassandra è in realtà più complessa.

  • HBase ha più unit test FWIW.

  • Tutto Cassandra RPC è parsimonioso, HBase ha un parsimonia, REST e Java nativo. Thrift e REST offrono solo un sottoinsieme dell'API client totale, ma se si desidera la velocità pura, il client Java nativo è presente.

  • Ci sono vantaggi sia per il peer to peer che per il master to slave. La configurazione master-slave generalmente rende più facile il debug e riduce un po 'di complessità.

  • HBase non è legato solo all'HDFS tradizionale, puoi cambiare lo storage sottostante a seconda delle tue esigenze. MapR sembra piuttosto interessante e ho sentito cose buone anche se non l'ho usato da solo.


117

In qualità di sviluppatore Cassandra, sono più bravo a rispondere all'altro lato della domanda:

  • Cassandra scala meglio. Cassandra è noto per scalare fino a oltre 400 nodi in un cluster ; quando Facebook ha distribuito la messaggistica su HBase, ha dovuto suddividerla in sotto-cluster HBase a 100 nodi .
  • Cassandra supporta centinaia, persino migliaia di ColumnFamilies. " HBase attualmente non funziona bene con qualcosa al di sopra di due o tre famiglie di colonne ".
  • Essendo un sistema completamente distribuito senza nodi o processi "speciali" , Cassandra è più semplice da configurare e utilizzare , più facile da risolvere e più robusto.
  • Il supporto di Cassandra per la replica multi-master significa che non solo ottieni l'ovvia potenza di più datacenter - ridondanza geografica, latenze locali - ma puoi anche suddividere carichi di lavoro in tempo reale e analitici in gruppi separati, con replica bidirezionale in tempo reale tra di loro . Se non dividi questi carichi di lavoro, si contenderanno in modo spettacolare.
  • Poiché ogni nodo Cassandra gestisce il proprio archivio locale, Cassandra ha un vantaggio sostanziale in termini di prestazioni che è improbabile che venga ridotto in modo significativo. (Ad esempio, è pratica standard mettere il commitlog di Cassandra su un dispositivo separato in modo che possa eseguire le sue scritture sequenziali senza impedimenti da i / o casuali da richieste di lettura.)
  • Cassandra ti consente di scegliere quanto forte vuoi che richieda coerenza per operazione. A volte questo viene frainteso come "Cassandra non ti dà una forte coerenza", ma non è corretto.
  • Cassandra offre RandomPartitioner e OrderedPartitioner più simile a Bigtable. RandomPartitioner è molto meno incline agli hot spot.
  • Cassandra offre la memorizzazione nella cache all'interno o all'esterno dell'heap con prestazioni paragonabili a memcached, ma senza i problemi di coerenza della cache o la complessità di richiedere parti mobili aggiuntive
  • I client non Java non sono cittadini di seconda classe

Per quanto ne so, il vantaggio principale che HBase ha in questo momento (HBase 0.90.4 e Cassandra 0.8.4) è che Cassandra non supporta ancora la compressione trasparente dei dati. (Questo è stato aggiunto per Cassandra 1.0 , previsto per l'inizio di ottobre, ma oggi è un vero vantaggio per HBase.) HBase può anche essere ottimizzato meglio per i tipi di scansioni di intervallo eseguite dall'elaborazione batch di Hadoop.

Ci sono anche alcune cose che non sono necessariamente migliori, o peggiori, solo diverse. HBase aderisce più strettamente al modello di dati Bigtable, in cui ogni colonna ha una versione implicita. Cassandra elimina il controllo delle versioni e aggiunge invece SuperColumns.

Spero che aiuti!


13
Sono abbastanza sicuro che i frammenti di Facebook su 100 nodi HBAse cluster per altri motivi legati al loro stack software modulare. In un recente discorso Todd Lipcon di Cloudera ha menzionato i cluster HBase 1PT 1000 nodi e ho visto menzionare più di 700 cluster HBase nodi.
cftarnas

1
Buon punto. Potrebbe anche essere qualcosa di specifico del carico di lavoro.
jbellis

1
Tanti vantaggi Cassandra sopra. Ma perché alla fine Facebook ha scelto HBase invece di Cassandra !?
Ivan Voroshilin

5
Una combinazione di (a) persone del team di messaggistica che hanno già familiarità con Hadoop e HBase, (b) scarsa comprensione del modello di coerenza di Cassandra e (c) non contattare la comunità di Apache Cassandra per chiedere aiuto con (b). Più recentemente, le divisioni facebook come Instagram e Parse hanno scelto Cassandra: planetcassandra.org/blog/post/… planetcassandra.org/blog/post/…
jbellis

23

Il motivo per cui si utilizzano cluster hBase a 100 nodi non è perché HBase non scala a dimensioni maggiori. È perché è più facile eseguire gli aggiornamenti del software hBase / HDFS in modo continuo senza interrompere l'intero servizio. Un altro motivo è impedire che un singolo NameNode sia uno SPOF per l'intero servizio. Inoltre, HBase viene utilizzato per vari servizi (non solo messaggi FB) ed è prudente avere un approccio da cookie per la creazione di numerosi cluster HBase basati su un approccio pod a 100 nodi. Il numero 100 è ad hoc, non ci siamo concentrati sul fatto che 100 sia ottimale o meno.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.