MySQL Partitioning/Sharding/Splitting: ¿qué camino tomar?

Question

Tenemos una base de datos InnoDB de unos 70 GB y esperamos que crezca a varios cientos de GB en los próximos 2 o 3 años. Alrededor del 60% de los datos pertenecen a una sola tabla. Actualmente, la base de datos funciona bastante bien ya que tenemos un servidor con 64 GB de RAM, por lo que casi toda la base de datos se adapta a la memoria, pero nos preocupa el futuro cuando la cantidad de datos será considerablemente mayor. En este momento estamos considerando alguna manera de dividir las tablas (especialmente la que representa la mayor parte de los datos) y ahora me pregunto cuál sería la mejor manera de hacerlo.

Las opciones actualmente estoy en cuenta son

• Usar MySQL particionamiento que viene con la versión 5.1
• El uso de algún tipo de biblioteca de terceros que encapsula la partición de los datos (como fragmentos de hibernación)
• La implementación de nosotros mismos dentro de nuestra aplicación

nuestra aplicación está construida en J2EE y EJB 2.1 (esperemos que estamos cambiando a EJB 3 algún día).

¿Qué sugeriría?

EDITAR (2011-02-11):
Apenas una actualización: En la actualidad el tamaño de la base de datos es de 380 GB, el tamaño de los datos de nuestra mesa "grande" es de 220 GB y el tamaño de su índice es de 36 GB . Entonces, aunque toda la tabla ya no cabe en la memoria, el índice sí lo hace.
El sistema sigue funcionando bien (todavía en el mismo hardware) y todavía estamos pensando en particionar los datos.

EDITAR (2014-06-04): Una actualización más: El tamaño de toda la base de datos es de 1,5 TB, el tamaño de nuestra tabla "grande" es de 1,1 TB. Actualizamos nuestro servidor a una máquina de 4 procesadores (Intel Xeon E7450) con 128 GB de RAM. El sistema sigue funcionando bien. Lo que estamos planificando hacer ahora es poner nuestra gran mesa en un servidor de base de datos separado (ya hemos hecho los cambios necesarios en nuestro software) al tiempo que actualizamos a un nuevo hardware con 256 GB de RAM.

Esta configuración se supone que durará dos años. Entonces tendremos que finalmente comenzar a implementar una solución de fragmentación o simplemente comprar servidores con 1 TB de RAM que nos mantendrán activos por un tiempo.

EDITAR (18/01/2016):

Desde entonces, hemos puesto nuestra mesa grande en su propia base de datos en un servidor independiente. Actualmente el tamaño de esta base de datos es de aproximadamente 1.9 TB, el tamaño de la otra base de datos (con todas las tablas excepto la "grande") es de 1.1 TB.

configuración de hardware actual:

• HP ProLiant DL 580
• 4 x (R) Xeon (R) CPU Intel S7- 4830
• 256 GB RAM

rendimiento es fina con esta configuración

Answer 1

Si cree que va a tener IO/memoria, no creo que la partición sea útil. Como de costumbre, la evaluación comparativa primero te ayudará a descubrir la mejor dirección. Si no tiene servidores de repuesto con 64 GB de memoria dando vueltas, siempre puede pedirle a su proveedor una 'unidad de demostración'.

Me inclinaría por la fragmentación si no se esperan 1 informes agregados de consultas. Supongo que harías fragmentos de toda la base de datos y no solo de tu gran mesa: es mejor mantener entidades enteras juntas. Bueno, si tu modelo se divide muy bien, de todos modos.

Answer 2

En primer lugar, no importa tanto dividir las tablas a menos que también mueva algunas de las tablas a un volumen físico por separado.

En segundo lugar, no es necesariamente la tabla con el tamaño físico más grande que desea mover. Puede tener una tabla mucho más pequeña que obtiene más actividad, mientras que su tabla grande permanece bastante constante o solo agrega datos.

Hagas lo que hagas, no lo implementes. Deje que el sistema de base de datos lo maneje.

Answer 3

Hace un tiempo en un evento Microsoft ArcReady, vi una presentación sobre los patrones de escala que podrían serle útiles. Puede view the slides en línea.

Answer 4

¿Qué hace la gran mesa?

Si usted va a dividir, tienes algunas opciones:
- dividirlo usando el sistema de base de datos (no sé mucho acerca de eso)
- dividirlo por fila.
- divídalo por columna.

Dividirlo por filas solo sería posible si los datos se pueden separar fácilmente en fragmentos. p.ej. Algo como Basecamp tiene varias cuentas que están completamente separadas. Puede mantener el 50% de las cuentas en una tabla y el 50% en una tabla diferente en una máquina diferente.

Dividir por columna es bueno para situaciones en las que el tamaño de fila contiene campos de texto grandes o BLOB. Si tiene una tabla con (por ejemplo) una imagen de usuario y un gran bloque de texto, puede cultivar la imagen en una tabla completamente diferente. (en una máquina diferente)

Se rompe la normalización aquí, pero no creo que cause demasiados problemas.

Answer 5

Como de costumbre, la evaluación comparativa primero le ayudará a determinar la mejor dirección.

Eso es lo que la mayoría de la gente me dice, así que creo que por fin voy a tener que tomar esa pastilla ...

Answer 6

Es probable que desee dividir esa mesa grande con el tiempo. Probablemente desee colocarlo en un disco duro por separado antes de pensar en un segundo servidor. Hacerlo con MySQL es la opción más conveniente. Si es capaz, entonces ve por ello.

PERO

Todo depende de cómo se está utilizando su base de datos, de verdad. Estadística.

Answer 7

Definitivamente comenzará a tener problemas en esa tabla de 42 GB una vez que ya no cabe en la memoria. De hecho, tan pronto como ya no cabe en la memoria, el rendimiento se degradará extremadamente rápido. Una forma de probar es poner esa tabla en otra máquina con menos RAM y ver qué tan pobre funciona.

En primer lugar, no importa tanto dividir las tablas a menos que también mueva algunas de las tablas a un volumen físico por separado.

Esto es incorrecto. La partición (ya sea a través de la característica en MySQL 5.1, o lo mismo con las tablas MERGE) puede proporcionar importantes beneficios de rendimiento, incluso si las tablas están en la misma unidad.

Como ejemplo, supongamos que está ejecutando consultas SELECT en su gran tabla con un intervalo de fechas. Si la tabla es completa, la consulta se verá obligada a escanear toda la tabla (y en ese tamaño, incluso utilizando índices puede ser lenta). La ventaja de la partición es que sus consultas solo se ejecutarán en las particiones donde sea absolutamente necesario. Si cada partición tiene un tamaño de 1 GB y su consulta solo necesita acceder a 5 particiones para cumplirse, la tabla combinada de 5 GB es mucho más fácil de manejar para MySQL que una versión monstruosa de 42 GB.

Una cosa que debes hacerte es cómo estás consultando los datos. Si existe la posibilidad de que sus consultas solo necesiten acceder a ciertos fragmentos de datos (es decir, un rango de fechas o un rango de ID), las particiones de algún tipo resultarán beneficiosas.

He oído que todavía hay algunos errores con el particionado de MySQL 5.1, particularmente relacionado con MySQL que elige la clave correcta. Las tablas MERGE pueden proporcionar la misma funcionalidad, aunque requieren un poco más de sobrecarga.

Espero que ayude ... ¡buena suerte!

Answer 8

Este es un gran ejemplo de lo que puede hacer MySql partición en un ejemplo de la vida real de los datos enormes flujos:

http://web.archive.org/web/20101125025320/http://www.tritux.com/blog/2010/11/19/partitioning-mysql-database-with-high-load-solutions/11/1

esperando que sea útil para su caso.

Answer 9

Me gustaría ir a MariaDB InnoDB + Particiones (ya sea por clave o por fecha, dependiendo de sus consultas).

Lo hice y ahora ya no tengo ningún problema en la base de datos.

MySQL se puede reemplazar con MariaDB en segundos ... todos los archivos de la base de datos permanecen iguales.