Elaborazione di dati su larga scala Hbase vs Cassandra

Question

Sono quasi atterrato a Cassandra dopo le mie ricerche su soluzioni di archiviazione di dati su larga scala. Ma in generale ha affermato che Hbase è la soluzione migliore per l'elaborazione e l'analisi di dati su larga scala.

Mentre entrambi sono la stessa memoria di chiavi/valore ed entrambi sono/possono essere eseguiti (Cassandra di recente), il layer Hadoop rende quindi Hadoop un candidato migliore quando è richiesta l'elaborazione/analisi su dati di grandi dimensioni.

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

ma sto ancora cercando i vantaggi concreti di HBase.

Mentre sono più convinto di Cassandra perché la sua semplicità è l'aggiunta di nodi e funzionalità di replica continua e senza punti critici. E mantiene anche la funzionalità di indice secondario, quindi è un ottimo vantaggio.

Answer 1

Cercare di determinare quale sia il migliore per voi dipende in realtà da cosa lo userete, ognuno ha i suoi vantaggi e senza ulteriori dettagli diventa più una guerra religiosa. Quel post che hai fatto riferimento ha anche più di un anno ed entrambi hanno subito molti cambiamenti da allora. Tieni anche presente che non conosco gli sviluppi più recenti di Cassandra.

Detto questo, io parafrasare HBase committer Andrew Purtell e aggiungi alcune delle mie esperienze:

• HBase è negli ambienti di produzione più grandi (1000 nodi) anche se questo è ancora nel campo da baseball di Cassandra di ~ 400 installazioni di nodi quindi è davvero una differenza marginale.

• HBase e Cassandra supportano entrambi la replica tra cluster/datacenter. Credo che HBase's esponga di più all'utente in modo che appaia più complicato, ma poi si ottiene anche una maggiore flessibilità.

• Se la consistenza forte è ciò di cui l'applicazione ha bisogno, HBase è probabilmente più adatto. È progettato da zero per essere coerente. Ad esempio, consente un'implementazione più semplice dei contatori atomici (penso che Cassandra li abbia appena ottenuti) e le operazioni di Check e Put.

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

• Non sono sicuro dello stato corrente del partizionatore ordinato di Cassandra, ma in passato richiedeva il riequilibrio manuale. HBase gestisce quello per te se vuoi. Il partizionatore ordinato è importante per l'elaborazione in stile Hadoop.

• Cassandra e HBase sono entrambi complessi, Cassandra lo nasconde meglio. HBase lo espone di più usando HDFS per la sua archiviazione, se si guarda al codice base Cassandra è altrettanto stratificato. Se confronti i documenti Dynamo e Bigtable puoi vedere che la teoria del funzionamento di Cassandra è in realtà più complessa.

• HBase ha più test di unità 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 è disponibile.

• Ci sono vantaggi sia tra peer to peer che master to slave. L'impostazione master-slave generalmente semplifica il debug e riduce un po 'la complessità.

• HBase non è legato solo all'HDFS tradizionale, è possibile modificare lo storage sottostante in base alle proprie esigenze.MapR sembra abbastanza interessante e ho sentito cose buone anche se non l'ho usato da solo.

Answer 2

Come sviluppatore Cassandra, sto meglio a rispondere l'altro lato della domanda:

• Cassandra bilance meglio. Cassandra è noto per scalare a over 400 nodes in a cluster; quando Facebook ha implementato la messaggistica su HBase, hanno dovuto suddividerlo su 100-node HBase sub-clusters.
• Cassandra supporta centinaia, anche migliaia di ColumnFamilies. "HBase currently does not do well with anything above two or three column families."
• Come sistema completamente distribuito senza "special" nodes or processes, Cassandra è simpler to set up and operate, più facile da risolvere e più robusto.
• Il supporto di Cassandra per la replica multi-master significa che non solo si ottiene l'evidente potenza di più datacenter - ridondanza geografica, latenze locali - ma è anche possibile dividere i carichi di lavoro in tempo reale e analitici in gruppi separati, con realtime, bidirectional replication between them. Se non si suddividono questi carichi di lavoro, si contenderanno in modo spettacolare.
• Poiché ogni nodo Cassandra gestisce la propria memoria locale, Cassandra presenta un notevole vantaggio in termini di prestazioni che è improbabile che venga ridotto in modo significativo. Ad esempio, è normale mettere il commitlog di Cassandra su un dispositivo separato in modo che possa eseguire le sue scritture sequenziali senza impedimenti da richieste di lettura.)
• Cassandra consente di scegliere quanto forte si desidera richiedere coerenza a essere su una base operativa. A volte questo è frainteso come "Cassandra non ti dà una consistenza forte", ma non è corretto.
• Cassandra offre RandomPartitioner e il più ordinato OrderedPartitioner. RandomPartitioner è molto meno incline a punti caldi.
• Cassandra offre caching on- o off-heap con prestazioni paragonabili a memcached, ma senza i problemi di cache di consistenza o la complessità di richiedere parti extra in movimento
• client non-Java sono cittadini di seconda classe non

Per quanto ne so, il vantaggio principale che HBase ha ora (HBase 0.90.4 e Cassandra 0.8.4) è che Cassandra non supporta ancora la compressione dei dati trasparente. (Questo è stato added for Cassandra 1.0, previsto per i primi di ottobre, ma oggi è un vantaggio reale per HBase.) HBase potrebbe anche essere meglio ottimizzato per i tipi di scansioni di intervallo eseguite dall'elaborazione batch Hadoop.

Ci sono anche alcune cose che non sono necessariamente migliori, o peggio, solo diverse. HBase aderisce più strettamente al modello di dati di Bigtable, in cui ogni versione di una colonna è implicita.Cassandra rilascia il versioning e aggiunge invece SuperColumns.

Spero che questo aiuti!

Answer 3

Il motivo dell'utilizzo dei cluster hBase a 100 nodi non è dovuto al fatto che HBase non scala in dimensioni maggiori. È perché è più semplice eseguire gli aggiornamenti del software hBase/HDFS in modo continuo senza abbattere l'intero servizio. Un altro motivo è impedire a un singolo NameNode di essere un SPOF per l'intero servizio. Inoltre, HBase viene utilizzato per vari servizi (non solo messaggi FB) ed è prudente avere un approccio cookie-cutter per l'impostazione di numerosi cluster HBase basati su un approccio pod 100 nodi. Il numero 100 è ad hoc, non ci siamo concentrati sul fatto che 100 sia ottimale o meno.