2011-10-15 13 views
8

Tenemos un clúster (hadoop, pig) que genera 350Gb de datos (crece un par de GB por semana).NoSql o MySQL para análisis de datos

Todos estos datos deben estar disponibles para Analytics.

Tenemos una solución Msyql con esquema de estrella (solo se cargan partes de los datos en este). Pero

¿Hasta qué punto se puede estirar esto?

¿Debería estar buscando NoSQL como Hive para el análisis de datos?

leí este artículo http://anders.com/cms/282/Distributed.Data/Hadoop/Hbase/Hive

¿Qué tan grande es grande de datos, y cuando debo buscar lejos de MySQL? ¿La rigidez estructural de Mysql causará problemas?

Actualmente, los datos son solo unos pocos GB (en MySQL), pero ciertamente crecerán. ¿Qué hay de la agrupación de MySQL?

¿Debería ir por este camino en absoluto?

Respuesta

14

350 GB (GB creciente par de una semana) ... Todos necesitan estos datos estén disponibles para Analítica

¿Tiene gurús de MySQL en casa? Si es así, seguro => solo crea y crece ese clúster MySQL. El único problema con esta solución no es que sea MySQL, y no es que sea no un NoSQL => es literalmente porque requiere un experto para configurarlo y siempre estará allí a tu lado por si acaso Necesita ser cambiado. Pero adivine qué => SQL es MUCHO mejor y más simple para el análisis que una simulación de SQL de mapa/reducción.

Algo que puede convertirse un problema más adelante con una solución de Oracle MySQL es . Así que asegúrese de comprender qué características de MySQL puede usar de forma gratuita y qué funciones debería pagar.

Si lo hace no tiene un experto en MySQL en la casa, o no le gustaría pagar por uno, definitivamente puede recurrir a NoSQL. Sin embargo, esto no significa que no necesite una experiencia en productos NoSQL, sino que configure y ejecute nodos X ya que un solo sistema es un proceso extremadamente simple y natural para las soluciones NoSQL.

Por ejemplo, en Riak, y un par de otras bestias NoSQL, la mayoría de las complejidades de distribución son resueltas por el producto sin necesidad de hacer nada en absoluto => realmente es así de simple.

El precio que se paga con NoSQL está perdiendo SQL (pensar en buenas características de agregación) y la consistencia, que es eventual, y si estrictamente haciendo análisis, para usted, la consistencia no puede ser un precio en absoluto.

A cambio, obtiene un manejo Big Data muy natural, tolerancia a fallas y much more.

Si está en el espacio Hadooooxyz, y está bien que pague, eche un vistazo a Hadapt, que promete 5 veces el rendimiento de Hive.

1

se cambia cuando empieza a tener los tipos de problemas descritos en algo parecido a esta pregunta comparativa: https://dba.stackexchange.com/questions/5/what-are-the-differences-between-nosql-and-a-traditional-rdbms

Aparte de eso, es un poco difícil de responder a la pregunta más allá de consejos generales, ya que no plantea una problema específico que está tratando de resolver (por ejemplo, escala, velocidad de lectura, problemas con la exigencia del 100% de consistencia, etc.).

+0

¿Debo evitar un problema al intentar extraer más y más datos en mysql? – AlgoMan

+0

No se trata tanto de la cantidad de datos que se almacenan, sino de cómo se usa, y de cómo el uso y el diseño subyacente del DB afecta el rendimiento resultante/satisface las necesidades del negocio. Supongo que mi punto es que (a) NoSQL no es de ninguna manera un reemplazo de MySQL, es solo otra opción, y (b) es una especie de "herramienta adecuada para el trabajo correcto" tipo de pregunta. – jefflunt

2

La pregunta es, por supuesto, ahora hace muchos meses, pero ... Recientemente me encontré con InfiniDB, que pone una interfaz de MySQL en un motor de Big Data basado en MapReduce altamente escalable y dirigido específicamente a análisis. Puede ser una solución para este problema. En principio, debería incluirse y requerir muy poca administración y pocos cambios de código. Se admite el escalado en una caja o en varios servidores ...

1

InfiniDB no es gratuito.

Salida http://code.google.com/p/shard-query

Esto es como Map-Reduce durante un fragmentada compartido nada conjunto de bases de datos. Funciona muy bien para los esquemas STAR. Fragmenta la tabla de hechos sobre N nodos y duplica las tablas de dimensiones en cada servidor.

Se puede extraer de esta entrada del blog para más información y resultados de pruebas de rendimiento:

http://www.mysqlperformanceblog.com/2011/05/06/scale-out-mysql/

FYI: Soy el autor de Shard-consulta.

Cuestiones relacionadas