Hadoop (+ HBase/HDFS) vs MySQL (o Postgres) - Cargas de, datos estructurados independientes para ser procesada y preguntó

Question

Hola a SO,

me gustaría algunas ideas/comentarios sobre lo siguiente de usted honorable y venerable grupo.

Tengo 100M de registros que debo procesar. Tengo 5 nodos (en un grupo de rocas) para hacer esto. Los datos están muy estructurados y caen muy bien en el modelo de datos relacionales. Quiero hacer cosas en paralelo ya que mi procesamiento lleva tiempo.

Tal como lo veo yo tengo dos opciones principales:

instalar MySQL en cada nodo y poner 20M registros en cada uno. Use el nodo principal para delegar consultas a los nodos y agregar los resultados. Capacidades de consulta ++, pero podría arriesgarme a algunos dolores de cabeza cuando elijo estrategias de partición, etc. (P. ¿Es esto lo que llaman clúster mysql/postgres?). La parte realmente mala es que el procesamiento de los registros me queda ahora a mi cargo (cómo distribuir en máquinas, etc.) ...

O instale Hadoop, Hive y HBase (tenga en cuenta que esto podría no ser así) la forma más eficiente de almacenar mis datos, ya que HBase está orientado a columnas) y solo define los nodos. Escribimos todo en el paradigma MapReduce y, bang, vivimos felices para siempre. El problema aquí es que perdemos las capacidades de consulta en "tiempo real" (sé que puedes usar Hive, pero eso no se sugiere para las consultas en tiempo real, que necesito), ya que también tengo algunas consultas sql normales para ejecutar a veces " seleccione * del vino donde el color = 'marrón' ".

Tenga en cuenta que, en teoría, si tuviera máquinas de 100M podría hacer todo al instante ya que para cada registro el procesamiento es independiente del otro. Además, mis datos son de solo lectura. No preveo que ocurra ninguna actualización. No necesito/quiero registros de 100M en un nodo. No quiero que haya datos redundantes (ya que hay muchos), por lo que lo mantengo tanto en mysql/postgres como en Hadoop/HBase/HDFS. no es una opción real

Muchas Gracias

Answer 1

HI,

yo tuvimos una situación en la que tenía muchas mesas que he creado en el uso de sqlalchemy paralelo y la biblioteca de Python multiprocesamiento. Tenía varios archivos, uno por tabla, y los cargué usando procesos COPY paralelos. Si cada proceso corresponde a una tabla separada, eso funciona bien. Con una tabla, usar COPY sería difícil. Podría usar particiones de tablas en PostgreSQL, supongo. Si estás interesado, puedo darte más detalles.

Atentamente.

Answer 2

Hay algunas preguntas para hacer, antes de sugerir.
¿Puede formular sus consultas para acceder solo por clave principal? En otras palabras, si puede evitar todas las uniones y escaneos de tabla. Si es así, HBase es una opción, si necesita una tasa muy alta de accesos de lectura/escritura.
No creo que Hive sea una buena opción si tenemos en cuenta el bajo volumen de datos. Si espera que crezcan significativamente, puede considerarlo. En cualquier caso, Hive es bueno para las cargas de trabajo analíticas, no para el tipo de procesamiento OLTP.
Si necesita un modelo relacional con uniones y escaneos, creo que una buena solución podría ser un Nodo maestro y 4 esclavos, con replicación entre ellos. Dirigirá todas las escrituras al maestro y las lecturas de saldos entre el clúster completo. Es especialmente bueno si tiene muchas más lecturas que escrituras.
En este esquema tendrá todos los 100M registros (no coincide) en cada nodo. Dentro de cada nodo puede emplear la partición si corresponde.

Answer 3

¿Puedes demostrar que MySQL es el cuello de botella? Los registros de 100M no son tantos, y parece que no está realizando consultas complejas. Sin saber exactamente qué tipo de procesamiento, esto es lo que haría, en este orden:

1. Guarde los 100M en MySQL. Eche un vistazo a la utilidad Sqoop de Cloudera para importar registros de la base de datos y procesarlos en Hadoop.
2. Si MySQL es el cuello de botella en (1), considere configurar la duplicación esclava, que le permitirá paralelizar las lecturas, sin la complejidad de una base de datos fragmentada. Como ya ha indicado que no necesita volver a escribir en la base de datos, esta debería ser una solución viable. Puede replicar sus datos en tantos servidores como sea necesario.
3. Si está ejecutando consultas de selección complejas de la base de datos, y (2) aún no es viable, entonces considere usar Sqoop para importar sus registros y hacer las transformaciones de consulta que necesite en Hadoop.

En su situación, resistiría la tentación de saltar de MySQL, a menos que sea absolutamente necesario.

Answer 4

Quizás también desee considerar el uso de Cassandra. Recientemente descubrí este artículo en HBase vs. Cassandra que me acordé cuando leí su publicación.

Lo esencial es que Cassandra es una solución NoSQL altamente escalable con consultas rápidas, que suena como la solución que está buscando.

Por lo tanto, todo depende de si necesita mantener su modelo relacional o no.