Elaborazione dati su larga scala Hbase vs Cassandra [chiuso]

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.

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.

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!

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.