¿Qué tan grande es demasiado grande para una tabla MySQL?

Question

Finalmente me convencieron para poner mis tablas más pequeñas en una grande, pero ¿qué tan grande es demasiado grande para una tabla MySQL?

Tengo una tabla con 18 campos. Algunos son TEXT, algunos son cortos VARCHAR(16), otros más largos VARCHAR(100).

Ahora mismo obtenemos unas 200,000 filas por día, que serían 6 millones + por mes. ¿Cuán grande es muy grande? ¿Importa cuántos campos tiene o solo filas?

Answer 1

No hay una gran solución general a la pregunta "¿Qué tan grande es demasiado grande" - tales preocupaciones son frecuentemente depende de lo que estás haciendo con sus datos y lo sus consideraciones de rendimiento son

Existen algunos límites fundamentales en el tamaño de las tablas. No puedes tener más de 1000 columnas. Sus registros no pueden ser más grandes que 8k cada uno. Estos límites cambian según el motor de la base de datos. (Los de aquí son para InnoDB.)

Parece que ha combinado varios conjuntos de datos diferentes en una sola tabla. Es probable que tenga algunos campos que le dicen a qué conjunto de datos pertenece este registro, junto con algunos campos de datos y alguna información de marca de tiempo. No es un registro muy amplio (a menos que esté registrando, por ejemplo, todos los parámetros de entrada de cada solicitud). Su problema principal será con selectividad. Indexar esta tabla de una manera significativa será un desafío. Si sus campos comunes pueden ser lo suficientemente selectivos como para poder usarlos para obtener los registros que desea sin consultar la tabla, eso será una gran ventaja. (Cf. escaneo de tabla)

Para tantos registros por día (básicamente, dos por segundo todo el día, y supongo que tiene un período de carga pico donde es mucho mayor), también querrá hacer Asegúrese de que específicamente vea las optimizaciones en mejorando la velocidad de inserción. Como regla general, más índices = inserciones más lentas. Si puede, considere archivar registros obsoletos a otra tabla por completo. En lugares de trabajo anteriores, hemos utilizado una estrategia de archivo del último mes, tres meses anteriores y seis meses anteriores, cada uno en tablas separadas. Otra idea es eliminar registros antiguos. Muchos entornos simplemente no necesitan información más allá de una fecha determinada. Continuar con los registros de hace tres meses a menudo es demasiado caro.

Por último, no olvide el almacenamiento físico de su mesa. Cuanto más delgados sean sus registros, menos IO física necesita ocurrir para leer (o para el caso, para insertar) un registro. Puede almacenar sus índices en un disco duro físico separado. Si hay una gran cantidad de datos redundantes en sus registros, almacenar la tabla comprimida podría ser un aumento de velocidad. Si tiene un poco de efectivo para quemar, considere el valor de una buena matriz RAID para dividir sus datos.

Por lo tanto, para responder a su pregunta básica: es un montón de registros, pero con una mirada cuidadosa hacia la afinación, no será un problema.

Answer 2

Creo que depende, básicamente. ¿Qué versión de MySQL está usando, qué sistema operativo y está utilizando las tablas MyISAM o innoDB? También es different on 32-bit and 64-bit, y varía en su configuración de registro. El MySQL manual dice:

El tamaño máximo de la mesa eficaz para bases de datos MySQL se determina generalmente por operan las limitaciones del sistema en tamaños de archivo, no por MySQL límites internos

Hay más detalles sobre lo que esos límites están en esa página también.

Answer 3

La elección de cuántas columnas colocar en una sola tabla también depende del tipo de datos que se representan y de cuánto se preocupa por la normalización. Algunas relaciones se pueden representar fácilmente con una tabla; otros deben hacerse en varias tablas más pequeñas, especialmente cuando tiene una mezcla de relaciones uno a uno, uno a muchos y muchos a muchos en su conjunto de datos.

http://en.wikipedia.org/wiki/Database_normalization

Answer 4

No

una respuesta a la pregunta exacta ...

¿Por qué estabas convencido de que poner las tablas más pequeñas en una grande? Lo que estaba haciendo se llama "Partición vertical" y puede ser muy útil, dependiendo de su situación. Con muchos campos grandes de TEXTO o BLOB, una partición vertical puede mantener sus datos más consultados físicamente juntos y más rápido de acceder.

Ver: http://en.wikipedia.org/wiki/Partition_(database)

partición vertical implica la creación de tablas con un menor número de columnas y el uso de tablas adicionales para almacenar las columnas restantes. La normalización también implica esta división de columnas en las tablas, pero la partición vertical va más allá de eso y divide las columnas incluso cuando ya están normalizadas. Se puede usar un almacenamiento físico diferente para realizar particiones verticales también; almacenar columnas poco utilizadas o muy anchas en un dispositivo diferente, por ejemplo, es un método de partición vertical. Hecho explícita o implícitamente, este tipo de partición se llama "división de fila" (la fila se divide por sus columnas). Una forma común de partición vertical es dividir (es difícil encontrar) datos dinámicos de datos estáticos (rápidos de encontrar) en una tabla donde los datos dinámicos no se usan con tanta frecuencia como los estáticos. La creación de una vista en las dos tablas creadas recientemente restaura la tabla original con una penalización de rendimiento; sin embargo, el rendimiento aumentará al acceder a los datos estáticos, p. Para el análisis estadístico

Consulte también: http://dev.mysql.com/tech-resources/articles/performance-partitioning.html

Answer 5

Considera lo que tienes que hacer con la tabla. Si la tabla es puramente para lograr, nunca necesitarás cambiar su estructura ni nada. Si lo necesita para la minería de datos, esperaría cambiar su estructura. Intente, por ejemplo, hacer una tabla alternativa en una copia ahora. Espere que esta función disminuya su rendimiento una vez que alcanza un nivel en el que las tablas temporales son demasiado grandes para almacenarse en la memoria.

He estado en la misma situación, donde la cantidad de datos me ha impedido modificar la estructura de la base de datos. Lo que debe hacer AHORA MISMO es pedirle a alguien que cree una base de datos en una máquina (es decir, una instancia EC2) con la cantidad de datos que espera tener en dos años. Solo pídales que creen datos falsos en el mismo formato de tabla. Intente trabajar con esta tabla y decidir si el rendimiento es aceptable. Si no es aceptable, debe cambiar las cosas lo antes posible.

Si yo fuera usted, consideraría probar Greenplum o (GridSQL si no tiene el dinero para gastar). Ambos se basan en PostgreSQL y usan muchas computadoras para trabajar juntas.

Answer 6

Tengo una tabla con ~ 98M filas y las inserciones/eliminaciones ocurren durante todo el día. Mantenemos registros durante 90 días ... Espero que esta tabla sea ~ 100 millones de filas este mes. Personalmente, habría diseñado el esquema de la base de datos de forma diferente, pero se compró y debemos mantenerlo intacto para que no anule el soporte de ningún proveedor.

Estamos utilizando la replicación de mysql (MASTER-MASTER) y realizando las inserciones/eliminaciones en una & realizando las consultas en la otra. Esto realmente ha ayudado con el rendimiento ya que las eliminaciones bloquearían la tabla y bloquearían las consultas antes de cambiar a usar la replicación.

No tenemos problemas de rendimiento con esta implementación.

también realizo una optimizan la mesa una vez a la semana ...