Puede MySQL Cluster manejar una base de datos de terabytes

Tengo que buscar soluciones para proporcionar una base de datos MySQL que pueda manejar volúmenes de datos en el rango de terabytes y estar altamente disponible (cinco nueves). Cada fila de la base de datos es probable que tenga una marca de tiempo y hasta 30 valores flotantes. La carga de trabajo esperada es de hasta 2500 inserciones/seg. Es probable que las consultas sean menos frecuentes, pero podrían ser de gran tamaño (quizás con 100 Gb de datos), aunque probablemente solo involucren tablas individuales.Puede MySQL Cluster manejar una base de datos de terabytes

He estado buscando en MySQL Cluster dado que es su oferta de HA. Debido al volumen de datos, necesitaría hacer uso del almacenamiento basado en disco. De manera realista, creo que solo las marcas de tiempo podrían mantenerse en la memoria y todos los demás datos tendrían que almacenarse en el disco.

¿Alguien tiene experiencia en el uso de MySQL Cluster en una base de datos de esta escala? ¿Es incluso viable? ¿Cómo afecta el almacenamiento basado en disco al rendimiento?

También estoy abierto a otras sugerencias sobre cómo lograr la disponibilidad deseada para este volumen de datos. Por ejemplo, ¿sería mejor utilizar una biblioteca de terceros como Sequoia para manejar la agrupación de instancias estándar de MySQL? ¿O una solución más directa basada en la replicación de MySQL?

La única condición es que debe ser una solución basada en MySQL. No creo que MySQL sea la mejor manera de buscar los datos que manejamos, pero es un requisito difícil.

Fuente

2009-05-11 Mark

Si está buscando tecnologías, puede considerar algunos proyectos basados en BigTable de Google. HBase de Hadoop, e Hypertable son proyectos interesantes a tener en cuenta. http://hadoop.apache.org/hbase/ y http://www.hypertable.org/ – Kekoa

Esa pregunta se puede hacer mejor en serverfault.com. – lothar

Velocidad sabia, se puede manejar. En términos de tamaño, la pregunta no es el tamaño de sus datos, sino el tamaño de su índice, ya que los índices deben encajar completamente en la memoria.

Estaría encantado de ofrecer una mejor respuesta, pero el trabajo de la base de datos de alta gama es muy dependiente de la tarea. Necesito saber mucho más sobre lo que está pasando con los datos para ser de ayuda adicional.

Fuente

2009-05-11 22:17:46

La base de datos almacenará una secuencia de datos con marca de tiempo que recibimos a 50Hz para varias ubicaciones, por lo tanto, las 2500 inserciones/seg. La configuración de la transmisión puede cambiar en cualquier momento, por lo tanto, podría haber una cantidad variable de valores flotantes. La marca de tiempo será la clave principal y tendrá un índice. Estamos asumiendo que la columna de marca de tiempo estará en la memoria con el resto de los datos en el disco. – Mark

Me gustaría insertar por lotes, entonces. Una inserción/cliente/segundo para múltiples filas. La replicación maestra maestra simple le permitirá conmutación por error y cumplir fácilmente con una carga de 50 insertos por segundo. La única pregunta real es cuán importante es evitar perder una muestra, y supongo que puede lidiar con 2 o 3 segundos de datos perdidos por un bloqueo del servidor. Como una sugerencia adicional, la partición de su tabla puede ser útil si tiene un índice que no sea la clave principal. También puede haber trucos de almacenamiento de datos para acelerar esas grandes consultas. –

Gracias por los comentarios. Pensamos que los insertos de lotes serían el camino a seguir. Hice algunos cálculos con el script ndb_size.pl y tenía razón sobre el tamaño del índice. La memoria requerida no hace que sea posible usar Cluster. Sin embargo, también aprendimos hoy que algo de pérdida de datos está bien, así que, como dijiste, ahora estamos buscando usar una replicación simple. – Mark

Bien, I hizo lea la parte sobre mySQL que es un requisito duro.

Dicho eso, permítanme primero señalar que la carga de trabajo de la que está hablando: 2500 inserciones/seg., Consultas raras, consultas que probablemente tengan conjuntos de resultados de hasta el 10 por ciento de todo el conjunto de datos. es casi pésimo para cualquier sistema de base de datos relacional.

(Esto me recuerda un proyecto, hace mucho tiempo, donde tenía un requisito difícil para cargar 100 megabytes de datos de programa en una línea RS-422 de 9600 baudios (también un requisito difícil) en menos de 300 segundos (también un requisito duro.) el hecho de que no parecían 1kByte/seg × 300 segundos = 300Kbytes para comunicarse.)

Luego está la parte de "contener hasta 30 flotadores." La redacción al menos sugiere que el número de muestras por inserción es variable, lo que sugiere a su vez algunos problemas de normalización, o la necesidad de hacer que cada fila de 30 entradas sea amplia y use NULLs.

Pero con todo lo dicho, está bien, estás hablando de 300Kbytes/seg y 2500 TPS (suponiendo que esto realmente sea una secuencia de muestras no relacionadas). Este set of benchmarks, al menos, sugiere que no está fuera del ámbito de la posibilidad.

Fuente

2009-05-11 23:58:07

¡Gracias por los comentarios y por enseñarme una nueva palabra! (pésimo) Para manejar el número variable de muestras, estamos pensando en crear una nueva tabla cada vez que esto cambie, ya que no debería ser demasiado frecuente. A continuación, tendremos una tabla de búsqueda que le permitirá encontrar la tabla de datos adecuada para un período de tiempo. – Mark

This article es realmente útil para identificar lo que puede ralentizar una gran base de datos MySQL.

Fuente

2009-05-12 00:01:16

Posiblemente pruebe hibernar fragmentos y ejecutar MySQL en 10 nodos con 1/2 terabyte cada uno para que pueda manejar 5 terabytes entonces;) muy por encima de su límite, ¿no?

Fuente

2010-11-23 17:27:02

Puede MySQL Cluster manejar una base de datos de terabytes

Respuesta

Cuestiones relacionadas