sql >> Base de Datos >  >> RDS >> Mysql

Manejo de datos muy grandes con mysql

  • ¿Puede MySQL razonablemente realizar consultas en miles de millones de filas? -- MySQL puede 'manejar' miles de millones de filas. "Razonablemente" depende de las consultas; vamos a verlos.

  • ¿Es InnoDB (MySQL 5.5.8) la opción correcta para miles de millones de filas? -- 5.7 tiene algunas mejoras, pero 5.5 es bastante bueno, a pesar de ser casi 6 8 años y al borde de ya no es compatible.

  • El mejor almacén de datos para miles de millones de filas:si se refiere a 'Motor', entonces InnoDB.

  • ¿Qué tan grande puede llegar a ser una base de datos MySQL antes de que el rendimiento comience a degradarse? Nuevamente, eso depende de las consultas. Puedo mostrarle una tabla de filas de 1K que se colapsará; He trabajado con tablas de miles de millones de filas que zumban.

  • ¿Por qué MySQL podría ser lento con tablas grandes? -- los escaneos de rango conducen a E/S, que es la parte lenta.

  • ¿Puede Mysql manejar tablas que contengan alrededor de 300 millones de registros? -- de nuevo, sí. El límite es de alrededor de un billón de filas.

  • (para las tablas de InnoDB, que es mi caso) aumentando innodb_buffer_pool_size (por ejemplo, hasta el 80% de la RAM). Además, encontré otras configuraciones de ajuste de rendimiento de MySQL aquí en el blog de Percona, sí

  • tener índices adecuados en la tabla (usando EXPLAIN en las consultas), bueno, veámoslos. Hay muchos errores que se pueden cometer en este crítico área.

  • partición de la mesa -- "¡La partición no es una panacea!" Insisto en eso en mi blog

  • Fragmentación de MySQL -- Actualmente esto es DIY

  • Agrupación de MySQL:actualmente, la mejor respuesta es alguna opción basada en Galera (PXC, MariaDB 10, DIY con Oracle). La "replicación de grupo" de Oracle es un competidor viable.

  • La partición no es compatible con FOREIGN KEY o "global" UNIQUE .

  • Los UUID, a la escala de la que está hablando, no solo ralentizarán el sistema, sino que lo matarán. UUID de tipo 1 puede ser una solución.

  • Velocidad de inserción y creación de índices:hay demasiadas variaciones para dar una sola respuesta. Veamos tu CREATE TABLE provisional y cómo pretende introducir los datos.

  • Muchas uniones:"Normalice, pero no sobrenormalice". En particular, no normalice fechas y horas, flotantes u otros valores "continuos".

  • Cree tablas de resumen

  • 2,3 millones de transacciones por día -- Si eso es 2.3M insertar (30/seg), entonces no hay mucho problema de rendimiento. Si es más complejo, puede ser necesario RAID, SSD, procesamiento por lotes, etc.

  • lidiar con tal volumen de datos:si la mayor parte de la actividad es con las filas "recientes", entonces buffer_pool "almacenará" la actividad, evitando así la E/S. Si la actividad es "aleatoria", entonces MySQL (o cualquiera else) tendrá problemas de E/S.

  • Reducir los tipos de datos ayuda en una tabla como la suya. Dudo si necesita 4 bytes para especificar fuel_type . Existen múltiples enfoques de 1 byte.