Hadoop (+ HBase/HDFS) vs Mysql (o Postgres) - Carichi di dati indipendenti, strutturati per essere elaborato e interrogato

Question

Ciao a SO,

vorrei alcune idee/commenti su quanto segue dalla tu gruppo onorevole e venerabile.

Ho un record di 100 M che devo elaborare. Ho 5 nodi (in un gruppo di rocce) per fare questo. I dati sono molto strutturati e ricadono piacevolmente nel modello di dati relazionali. Voglio fare le cose in parallelo poiché la mia elaborazione richiede del tempo.

come la vedo io ho due opzioni principali:

installare MySQL su ogni nodo e messo 20M record su ciascuno. Utilizzare il nodo principale per delegare query ai nodi e aggregare i risultati. Funzionalità di query ++, ma potrei rischiare qualche mal di testa quando arriverò a scegliere le strategie di partizionamento ecc. (D. Questo è quello che chiamano cluster mysql/postgres?). La parte veramente brutta è che l'elaborazione dei record è lasciata a me ora a occuparmi di (come distribuire su macchine ecc.) ...

In alternativa installare Hadoop, Hive e HBase (si noti che questo potrebbe non essere il modo più efficiente per archiviare i miei dati, dato che HBase è orientato a colonne) e basta definire i nodi. Scriviamo tutto nel paradigma MapReduce e, bang, viviamo felici e contenti. Il problema qui è che perdiamo le funzionalità di query "in tempo reale" (so che puoi usare Hive, ma questo non è suggerito per le query in tempo reale - di cui ho bisogno) - dal momento che ho anche alcune query sql normali da eseguire a volte " seleziona * da vino dove colore = 'marrone' ".

Si noti che in teoria, se avessi macchine da 100M, potrei fare il tutto istantaneamente poiché per ogni registrazione l'elaborazione è indipendente dall'altra. Inoltre, i miei dati sono di sola lettura. Non prevedo alcun aggiornamento in corso. Non ho bisogno/voglio record 100M su un nodo. Non voglio che ci siano dati ridondanti (dato che ce ne sono molti) quindi tenerlo in ENTRAMBI mysql/postgres e Hadoop/HBase/HDFS. non è un'opzione reale.

Molte grazie

Answer 1

HI,

ho avuto una situazione in cui ho avuto molti tavoli che ho creato in parallelo utilizzando sqlalchemy e la libreria python multiprocessing. Ho avuto più file, uno per tabella, e li ho caricati usando processi COPY paralleli. Se ogni processo corrisponde a una tabella separata, ciò funziona bene. Con una tabella, usare COPIA sarebbe difficile. Potresti usare il partizionamento delle tabelle in PostgreSQL, suppongo. Se sei interessato posso dare maggiori dettagli.

Saluti.

Answer 2

Ci sono alcune domande da porre prima di suggerire.
È possibile formulare le query per accedere solo tramite chiave primaria? In altre parole, se puoi evitare tutti i join e le scansioni delle tabelle. Se è così - HBase è un'opzione, se hai bisogno di un tasso molto alto di accessi in lettura/scrittura.
Non credo che Hive sia una buona opzione che prende in considerazione il volume di dati basso. Se ti aspetti che cresca in modo significativo, puoi prenderlo in considerazione. In ogni caso Hive va bene per i carichi di lavoro analitici, non per il tipo di elaborazione OLTP.
Se hai bisogno di un modello relazionale con join e scansioni, penso che una buona soluzione potrebbe essere un nodo principale e 4 slave, con la replica tra di loro. Dirigierai tutte le scritture al master e legerai le letture tra tutto il cluster. È particolarmente utile se hai molte più letture e poi scrivi.
In questo schema saranno presenti tutti i record 100M (non corrispondenti) su ciascun nodo. All'interno di ciascun nodo è possibile utilizzare il partizionamento, se appropriato.

Answer 3

Potete dimostrare che MySQL è il collo di bottiglia? I record di 100 milioni non sono molti e sembra che tu non stia eseguendo query complesse. Senza sapere esattamente quale tipo di elaborazione, ecco cosa farei, in questo ordine:

1. Conserva il 100M in MySQL. Dai un'occhiata all'utilità Sqoop di Cloudera per importare i record dal database ed elaborarli in Hadoop.
2. Se MySQL è il collo di bottiglia in (1), prendere in considerazione l'impostazione della replica slave, che consente di eseguire il parallelismo delle letture, senza la complessità di un database semplificato. Poiché hai già affermato che non è necessario scrivere di nuovo al database, questa dovrebbe essere una soluzione valida. È possibile replicare i dati su tutti i server necessari.
3. Se si eseguono query di selezione complesse dal database e (2) non è ancora valido, prendere in considerazione l'utilizzo di Sqoop per importare i record e fare qualsiasi trasformazione di query richiesta in Hadoop.

Nella tua situazione, vorrei resistere alla tentazione di saltare fuori di MySQL, a meno che non sia assolutamente necessario.

Answer 4

Si potrebbe anche prendere in considerazione l'utilizzo di Cassandra. Recentemente ho scoperto questo articolo su HBase vs. Cassandra che mi è stato ricordato quando ho letto il tuo post.

L'essenza di ciò è che Cassandra è una soluzione NoSQL altamente scalabile con query veloce, che suona come la soluzione che stai cercando.

Quindi, tutto dipende dal fatto che sia necessario mantenere il modello relazionale o meno.