DesenoFisico MySQL

BD3: Diseno Fısico - MySQL

Bases de Datos III

Diseno Fısico - MySQL

Enxenarıa Informatica

Curso 2013/2014

Miguel R. LuacesLaboratorio de Bases de Datos

Universidade da Coruna

Enxenarıa Informatica Miguel R. Luaces ([email protected]) - Juan Ramon Lopez Rodrıguez


Contenidos

1 Introduccion a MySQL2 Replicacion3 Copia de seguridad y recuperacion4 Medicion de rendimiento y perfilado

Medicion del rendimientoPerfilado de aplicaciones

5 OptimizacionOptimizacion de esquemas e ındicesOptimizacion de hw. y sw.Optimizacion del servidor



Introduccion a MySQL

Contenidos







MySQL Community Server

Version actual: 5.6.17

Documentacion: http://dev.mysql.com/doc/

Funciona sobre todas las plataformas: Mac OS X, Windows,GNU/Linux, Solaris, FreeBSD

Punto diferenciador: arquitectura diferente a otros SGBDs

Orientado a entornos de gran demanda (ej.: aplicaciones web)

OLTPAplicaciones incrustadasData warehouseIndexado de contenido


http://dev.mysql.com/doc/



MariaDB

An enhanced, drop-in replacement for MySQL

Version actual: 5.5.36

Documentacion: https://kb.askmonty.org/en/

Funciona sobre todas las plataformas: Mac OS X, Windows,GNU/Linux

Mejoras sobre MySQL 5.5:

Mas motores de almacenamiento (ej.: No-SQL)OptimizacionesExtensiones (ej.: virtual columns)Completamente Open Source


https://kb.askmonty.org/en/



Arquitectura de MySQL

Clientes

Conexión / Control de subprocesos

Caché de consultas

Analizador sintáctico

optimizador

Motores de almacenamiento

API del motor de almacenamiento

(“Iniciar transacción”, “recuperar registro con

clave x”)





Cada consulta es atendida por un thread del pool servidor

La cache consultas almacena sentencias select junto con su resultado

Si la consulta no esta en cache, tras el analisis sintactico, se realizala optimizacion del plan de ejecucion

Reescritura de la consultaDeterminacion del orden de acceso a las tablasSeleccion de los ındices a utilizarInclusion de las caracterısticas especıficas de los motores dealmacenamiento





Caracterıstica unica: separacion de tareas de servidor (conexiones,procesamiento de consultas, optimizacion) de tareas dealmacenamiento y recuperacion de datos

Se puede elegir el motor de almacenamiento a nivel de tabla

Se pueden cargar motores de almacenamiento en tiempo de ejecucion

Describiremos brevemente los siguientes aspectos de MySQL:

Control de concurrenciaGestion de transaccionesMotores de almacenamientoCriterios de seleccion




Control de concurrencia

Los bloqueos permiten evitar que un cliente lea un fragmento dedatos mientras otro lo esta cambiando

Hay dos tipos de bloqueos: compartidos (lectura) y exclusivos(escritura)

Los SGBD permiten distintas granularidades a los bloqueos (tabla,pagina o fila)

Los bloqueos de fila minimizan la cantidad de datos por lo queaumenta la concurrencia

Los bloqueos de tabla minimizan el consumo de memoria por lo queaumenta el rendimiento

Cada motor de almacenamiento de MySQL define su propia polıticay granularidad. El servidor no es consciente de los bloqueos.




Control de concurrencia

MyISAM, Memory y Merge realizan bloqueos a nivel de tabla

Cada motor lo implementa a su modo con optimizaciones paramejorar el rendimientoNecesita muy poca memoriaIdeal en el caso de que las lecturas sean mucho mas frecuentes quelas modificacionesEs eficiente en el caso de modificaciones simultaneas en varias filas

InnoDB realiza bloqueos a nivel de fila

Permite la maxima concurrencia a costa de mayor consumo dememoriaIdeal en el caso de cambios frecuentes o transacciones largasEs muy eficiente en el caso de cancelacion de transacciones

El servidor de MySQL puede bloquear tablas independiente del motorpara garantizar correccion de sentencias DDL como ALTER TABLE




Gestion de transacciones

MySQL incluye motores transaccionales (InnoDB) y notransaccionales (MyISAM, Memory)

El estandar SQL define cuatro niveles de aislamiento:

Read uncommitedRead commitedRepeatable readSerializable

Las figuras de las siguientes diapositivas se extrajeron de aquı:http://www.byteslounge.com/tutorials/spring-transaction-isolation-tutorial


http://www.byteslounge.com/tutorials/spring-transaction-isolation-tutorial




Read uncommited

No hay bloqueos, por lo que una transaccion lee datos sin confirmarde otra transaccionPermite lecturas sucias porque la segunda transaccion podrıa sercancelada





Read commited

Los bloqueos de escritura se mantienen hasta el fin de la transaccionLos de lectura se liberan al finalizar la lecturaUna transaccion solo lee datos de transacciones confirmadasPermite lecturas no-repetibles porque los datos podrıan cambiardespues de leidos





Repeatable read

Todos los bloqueos se mantienen durante toda la transaccionCualquier fila que lea una transaccion sera igual en sucesivas lecturasComo no hay bloqueo de rangos, permite lecturas fantasmaEs la predeterminada en InnoDB





Serializable

Aislamiento completo de las transacciones usando bloqueos de rango.InnoDB permite el nivel de aislamiento serializable medianteMultiversion Concurrency Control (MVCC)

Mantiene instantaneas de los datos tal y como existıan en undeterminado momentoDiferentes transacciones ven simultaneamente datos distintos en lasmismas tablasEvita la necesidad de bloquear filas en modo lectura





Interbloqueos (Deadlocks)

El funcionamiento de los bloqueos es especıfico del motor dealmacenamientoLos interbloqueos son inevitables ya que ocurren por conflictos realesen las transaccionesLos interbloqueos producen consultas lentas o que sobrepasan tiempomaximoLa solucion consiste en reanudar alguna de las transaccionesInnoDB detecta dependencias circulares y reanuda la transaccion conlos bloqueos de fila menos exclusivos





Registro de transacciones (Write-ahead logging)

El almacenamiento inmediato de los cambios en los datos es lentoLos cambios realizan en la copia en memoria de la pagina de discoEl almacenamiento en disco se realiza mediante un registro detransacciones usando escritura secuencial (y por tanto, rapida)Los datos en disco se escriben cuando la pagina se elimina dememoriaEn caso de fallo del servidor, los cambios se pueden recuperar

Uso de varios motores de almacenamiento en transacciones

Cada motor de almacenamiento gestiona el funcionamiento de lastransaccionesNo se pueden combinar de forma fiable motores de almacenamientodiferentes en una transaccionPor ejemplo, los cambios en tablas MyISAM no se pueden deshacercon un rollbackMySQL no informa del error de ninguna manera




Motores de almacenamiento: MyISAM

Motor predeterminado para las tablas hasta MySQL 5.1

No soporta transacciones ni claves foraneas, y solo permite bloqueosa nivel de tabla

El tamano maximo de una tabla es 256 TB

Cada tabla se almacena en un fichero del sistema operativo

Variantes:

Tablas con filas de tamano fijo (estaticas) y tamano variable(dinamicas)Tablas comprimidas y de solo lectura

El espacio usado en disco es mınimoOptimo para soportes de solo lectura y/o lentosSe construyen con la utilidad myisampack




Motores de almacenamiento: InnoDB

Motor predeterminado para las tablas desde MySQL 5.5Soporta transacciones, claves foraneasy bloqueos a nivel de filaEl tamano maximo de una tabla es 64 TBLas tablas se almacenan en archivos de datos administrados por elmotor y que pueden utilizar particiones raw

Indices agrupados (clustered indexes)Se crea un ındice para la clave principal de la tabla que se almacenaen las mismas paginas que las filasLas busquedas por clave principal son rapidas porque ahorran unacceso a discoLos ındices secundarios (todos los demas) siempre incluyen losatributos de la clave principal para usar el ındice agrupado en lasbusquedas

Inconvenientes:Tiene problemas de escalabilidad debido al soporte transaccionalCambios en la estructura de las tablas implican copiar todos losdatos y recrear los ındices




Motores de almacenamiento: Memory

Tablas que se guardan en la memoria del servidor y que no permitenla persistencia

No soportan transacciones ni claves foraneas. Los bloqueos son anivel de tabla

El tamano maximo de una tabla depende de la memoria del servidor

Permite un acceso muy rapido a los datos (un orden de magnitudmas rapido que el motor MyISAM)

El espacio ocupado por una tabla solo se devuelve al borrar o recrearla tabla

Ejemplos de posibles usos:

Tablas de busqueda rapida (i.e. codigos postales)Guardar en cache datos agregados periodicamenteResultados intermedios de procesosMySQL lo usa para procesar consultas que necesitan tablastemporales




Motores de almacenamiento: otros

Motor Merge

Combinacion de varias tablas MyISAM en una unica tabla virtualPermite la particion de informacion en diferentes bloquesPosibles usos: gestion de archivos de log, superar la limitacion detamano de archivo del SO

Motor Blackhole

No almacena datos. Todas las inserciones se descartanMantiene un registro de operaciones realizadasPosibles usos: auditorıa, algunas configuraciones de replicacion

Motor CSV

Tablas creadas sobre archivos con valores separados por comas(comma-separated values)No admite ındicesPosibles usos: intercambio de datos con aplicaciones externas




Motores de almacenamiento: seleccion

Dado que podemos elegir el motor de almacenamiento para cadatabla, necesitamos conocer como se va a utilizar cada tabla, comofunciona la aplicacion, y su evolucion potencial

En funcion del uso de transacciones:

Si la aplicacion requiere transacciones, la unica opcion es InnoDBSi no requieren transacciones y las consultas son SELECT e INSERT,MyISAM es buena opcion

En funcion de la concurrencia en las operaciones:

Depende de la carga de trabajo esperadaSi solo hay inserciones y lecturas: MyISAMSi queremos una mezcla de operaciones concurrentes sininterferencia, necesitamos un motor con bloqueo a nivel de fila(InnoDB)




Motores de almacenamiento: seleccion

En funcion de las copias de seguridad:

Algunos motores (InnoDB) no permiten la copia de seguridad con elSGBD on-lineSi se puede detener el servidor: cualquier motor.El uso de multiples motores complica el proceso de copia deseguridad

En funcion de la necesidad de operaciones especiales:

Solo InnoDB incluye ındices agrupados y optimizaciones basadas enellosInnoDB solo permite busquedas de texto completo desde la version5.6.4




Motores de almacenamiento: cambios

Metodos para el cambio de motor de almacenamiento de tablas

Mediante la sentencia ALTER TABLERealizando una copia de seguridad, y editando el fichero de volcadoCreando una nueva tabla e insertando los datos mediante unasentencia INSERT INTO

En todos los casos, las opciones especıficas del motor dealmacenamiento se pierden

Todos los metodos son lentos pues implican la copia de los datos

El metodo basado en ALTER TABLE implica un bloqueo deescritura en la tabla




Motores de almacenamiento: ejemplos

Registro de llamadas de central telefonica en tiempo realLa velocidad es el requisito principal. MyISAM impone unasobrecarga baja y permite miles de inserciones por segundoSi son necesarios informes de resumen, la recopilacion de datosralentiza las insercionesAlternativas:

Realizar la recopilacion en horas de poca cargaReplicar la base de datos en un segundo servidor esclavo en el que seharan las consultasParticionar el registro de llamadas por mes, semana o dıa, y crear unatabla de tipo Merge para las consultas

Servicio de cotizacionesSi es una herramienta de consumo interno con un numero limitadode usuarios, MyISAMSi es un servicio web con mucho trafico, miles de usuarios yalimentacion de cotizaciones en tiempo real, InnoDB

Una consulta no debe esperarMiles de usuarios intentando leer mientras simultaneamente seactualizan filas requiere bloqueos a nivel de fila




Motores de almacenamiento: ejemplos

Boletines de anuncios y foros de discusion

Cientos de aplicaciones PHP y Perl que dan soporte a este tipo desitios WebNo suelen tener en cuenta la eficiencia de la BD

Ejecutan muchas consultas para cada solicitud que sirvenMuchos usan tablas monolıticas con mucha actividad pesada delectura y escrituraLa carga suele ser mediana o pequena, MyISAM no es imprescindibleInnoDB no es capa de ejecutar rapidamente esta consulta sinoptimizaciones por parte del usuario

SELECT COUNT(*) FROM TABLE

Aplicaciones distribuidas en DVD / USB

El motor MyISAM trabaja directamente sobre el sistema de ficherosUtilizando el formato comprimido se optimiza el acceso a disco,aunque la BD es de solo lectura



Replicacion

Contenidos






Replicacion

Definicion de replicacion

Consiste en configurar uno o varios servidores como esclavos - oreplicas - de otro servidor

Problema a resolver: mantener los datos de los servidoressincronizados

Base para construir aplicaciones extensas y de alto rendimiento

Admite diferentes topologıas

Muchos esclavos pueden conectarse a un maestroUn esclavo puede, a su vez, actuar como maestro

Se puede replicar:

todo el servidordeterminadas bases de datossolo algunas tablas



Replicacion

Problemas resueltos por la replicacion

Distribucion de datosNo exige un ancho de banda intensivo y funciona con una conexionintermitenteUtil para mantener una copia de los datos en una ubicaciongeograficamente distante

Balanceo de cargaPermite distribuir peticiones de datos entre varios servidores

Alta disponibilidad y failoverLos esclavos ayudan a reducir el tiempo de caıda del servidor principal

Prueba de actualizaciones de MySQLConfiguramos un servidor esclavo con la nueva version de MySQL, yla utilizamos para ver que las aplicaciones siguen funcionando

Copias de seguridadLa carga de la copia se realiza sobre el esclavo, no sobre el servidororiginalUn servidor replicado no es una copia de seguridad



Replicacion

Funcionamiento de la replicacion

El maestro registra todos sus cambios como eventos del registrobinario (binary log)El esclavo copia los eventos del registro binario a su registro derepeticion (relay log)El esclavo repite todos los eventos del registro de repeticion sobresus propios datos



Replicacion


El registro binario de mySQL:

Registra todas las operaciones del servidor que modifican datos (opodrıan modificarlos, por ejemplo, un DELETE con filtro) conindependencia de los motores de almacenamiento

Esta formado por una secuencia de eventos, cada de uno de ellosformado por:

La fecha y hora del evento (un timestamp)Identificador del servidor de origen (evita bucles infinitos)Byte de desplazamiento del evento siguienteId del thread que ejecuto el evento en el servidor de origenTipo de evento (por ejemplo, Query)Detalles del evento



Replicacion


El registro binario de mySQL permite tres tipos de replicacion:

Basada en sentencias (statement-based replication)Se registra la instruccion que cambia los datos en el maestroLa utilizada por defecto. Sencilla de implementar y compacta.Estable desde MySQL 3.23Hay instrucciones que no se pueden replicar (detalles en el manual)

Basada en filas (row-based replication)Se registran las filas cambiadas y el cambio realizadoPermite la replicacion de cualquier instruccionEl registro aumenta de tamanoNo es facil auditar los cambios realizados

Mixta (mixed-format replication)MySQL decide en funcion de la instruccion que se ejecuta si se usareplicacion basada en sentencias o en filasSe usa la replicacion basada en sentencias a no ser que la instruccionno sea seguraVer la descripcion en el manual


http://dev.mysql.com/doc/refman/5.6/en/replication-sbr-rbr.html

http://dev.mysql.com/doc/refman/5.6/en/binary-log-mixed.html


Replicacion


El proceso para configurar la replicacion es el siguiente:

Configurar cuentas de replicacion en cada servidor

El thread E/S del esclavo hace una conexion TCP/IP al maestropara leer el registro binario. Por lo tanto, necesita una cuenta deusuario en el maestro con los permisos apropiados

Configurar maestro

Activar el registro binario y asignarle un id al servidor

Configurar esclavo

Asignarle un id al servidor y activar el registro de repeticionInidicar al esclavo como conectarse al maestro y desde que punto delregistro binario hay que replicarOpcionalmente, activar el registro binario y configurar suactualizacion



Replicacion


Es posible replicar solo parte de los eventos de un servidor,utilizando diferentes tipos de filtros

Filtros sobre el registro binario del maestroFiltros sobre el registro de repeticion



Replicacion

Topologıas de replicacion

Las restricciones en la replicacion son las siguientes:

Cada esclavo solo puede tener un maestroUn maestro puede tener muchos esclavosUn esclavo puede actuar tambien como maestro

Estas restricciones permiten diferentes topologıas con diferentesaplicaciones

Un maestro, multiples esclavosMaestro-maestro en modo activo-activoMaestro-maestro en modo activo-pasivoAnilloMaestro, maestro de distribucion, esclavosArbol o piramide



Replicacion


Un maestro, multiples esclavos



Replicacion


Un maestro, multiples esclavos

La topologıa mas sencilla y mas comun

Todas las escrituras se realizan en el maestro, las lecturas se puedenrealizar en cualquier servidor

El numero de esclavos esta limitado por la capacidad deprocesamiento y el ancho de banda del maestro

Variantes:

Usar cada esclavo para funciones diferentes (ej.: ındices diferentes,motores diferentes)Tener un esclavo en un centro remoto para recuperarse de undesastreRetrasar un esclavo en el tiempo para facilitar la recuperacionUtilizar un esclavo para copia de seguridad, para pruebas o paradesarrollo



Replicacion


Maestro-maestro en modo activo-activo

Cada maestro es a su vez esclavo del otroCualquier servidor se puede utilizar para cualquier operacionPosible uso: oficinas separadas geograficamente, donde cada oficinanecesita su copia local de los datosProblemas: cambios conflictivos

Actualizacion simultanea de la misma fila en ambos servidoresInserciones simultaneas con columnas AUTO INCREMENT¿Y si la replicacion se detiene por un tiempo? ¿Como reenganchamosdespues?

Solo se recomienda si tenemos datos bien particionados y buenreparto de privilegios



Replicacion


Maestro-maestro en modo activo-pasivo

Uno de los servidores es un servidor “pasivo” de solo lecturaPermite intercambiar los papeles de forma muy sencilla: lasconfiguraciones son simetricasMantenimiento, optimizacion de tablas, actualizaciones del sistemaoperativo no implican inactividad del sistema.Por ejemplo, ALTER TABLE bloquea toda la tabla, incluyendolecturas y escrituras sobre la misma. Para no ralentizar el sistema:

Detenemos los hilos esclavos en el maestro activoHacemos el cambio en el maestro pasivoCambiamos los papeles de activo y pasivoReiniciamos los hilos esclavos en el antiguo maestro activo



Replicacion


Anillo



Replicacion


Anillo

Tres o mas maestros

Cada servidor es un esclavo del servidor que esta antes en el anillo, ymaestro del servidor que esta despues

Configuracion simetrica, failover facil.

Es una configuracion fragil:

Depende enormemente de que todos los nodos funcionencorrectamenteDifıcil que esten todos sincronizados a la vez: detener algun nodo escomplicadoSi eliminamos un nodo sin tener cuidado, sus eventos puedenpropagarse de forma infinita por el anillo. ¡El unico nodo que filtra unevento es el que lo ha generado!



Replicacion


Maestro, maestro de distribucion, esclavos



Replicacion


Maestro, maestro de distribucion, esclavos

Similar a la topologıa maestro-esclavos, pero no sobrecarga almaestro principal

El maestro principal solo tiene un esclavo que a su vez actua comomaestro de distribucion

El maestro de distribucion usa el motor BlackHole que graba en elregistro binario pero no mantiene tablas ni datos



Replicacion


Arbol o piramide



Replicacion


Arbol o piramide

Si hay muchos esclavos, puede ser mas rentable un diseno enpiramide

Esto alivia la carga del maestro y la redistribuye por los diferentesesclavos

Desventaja: fallos en niveles intermedios afectan a un gran numerode servidores

Ademas, cuantos mas niveles intermedios, mas difıcil y complicadoes manejar los fallos



Replicacion

Problemas en la replicacion

La replicacion implica varias tareas complejas:

Medir el desfase de los esclavos para saber en que estado seencuentran

Determinar la consistencia de los esclavos con respecto al maestro

Resincronizar un esclavo con el maestro

Intercambiar un esclavo por un maestro

La replicacion solo escala las lecturas, no las escrituras

La distribucion de la carga debe ser realizada por otro software

La complejidad de la replicacion se ve claramente en la longitud dela seccion del manual


http://dev.mysql.com/doc/refman/5.6/en/replication-features.html


Copia de seguridad y recuperacion

Contenidos







Introduccion

Recuperacion no es restauracionRestaurar: recuperar datos desde una copia de seguridad y cargarlosen una base de datosRecuperar: todo el proceso de rescatar un sistema o parte de el.Incluye todos los pasos para lograr que un servidor vuelva a sercompletamente funcional y operativo:

Restaurar copia de seguridadReiniciar servidorCambiar configuracionCalentar las caches del servidor

Utilidades de las copias de seguridadRecuperacion ante desastres. Un error importante corrompe los datoso el servidorRecuperacion ante cambios no deseados. La gente cambia de idea, yocurre mas a menudo que los desastresAuditorıas. Necesidad de recuperar datos o esquema en algunmomento del pasado (ej. temas judiciales)Pruebas. La manera mas facil de cargar un servidor de pruebas condatos es usando una copia de seguridad




Introduccion

El mejor sistema de copias de seguridad no es suficiente. Un buenplan de recuperacion es fundamental

El procedimiento de recuperacion es complejo. Es facil cometererroresLas copias de seguridad son rutinarias y no se realizan bajosituaciones de presion extrema. La recuperacion se hace en medio deuna situacion de crisisUna persona puede planear, disenar e implementar las copias deseguridad, pero podrıa no estar disponible cuando se produzca eldesastre. Es necesario formar a personal cualificado para que seencargue de la recuperacion

Alternativas que no son copias de seguridad

La replicacion no es una copia de seguridadUsar discos en RAID¿Como nos recuperamos en estos casos de un DROP DATABASE?




Estrategia para la copia de seguridad

No olvidar realizar copias de seguridad de recursos no obvios

Registro binario y registro de transacciones de InnoDBCodigo: disparadores y procedimientos almacenados (estan en la BDmysql)Configuracion del servidor y de la replicacionFicheros seleccionados del SO (trabajos cron, configuraciones deusuario y de grupo, scripts administrativos, reglas sud0, etc)

¿Que podemos permitirnos perder?La respuesta a esa pregunta guıa la estrategia de copia de seguridad

¿Basta con la copia de la noche anterior y podemos perder el trabajode hoy?¿Necesitamos retroceder a un instante de tiempo predeterminado?

Cuanto mas nos permitamos perder, mas facil es hacer la copiaLas copias de seguridad en MySQL son mucho mas complicadas delo que parece




Tipos de copia de seguridad

¿Copias calientes, templadas o frıas?

Calientes: sin detener el servidor ni bloquear las tablasTempladas: sin detener el servidor pero bloqueando las tablasFrıas: deteniendo el servidor

¿Copias logicas o sin procesar?

Copia logica: en un formato que MySQL puede interpretar (SQL,CSV)Copia sin procesar: los archivos de mySQL tal y como estanalmacenados en disco





Inconvenientes de copias calientes

Buferes sucios en el grupo de buffers de InnoDB (u otras caches)Datos modificados mientras se esta haciendo la copia

Inconvenientes de copias frias

Desconectar servidor es costoso, aun si se minimiza el tiempo decopia de seguridadLas paginas sucias en grupo de buffers InnoDB requieren tiempo paravolcarse a discoReiniciar tambien requiere tiempo: abrir tablas, calentar caches, etc.

Inconvenientes de copias templadas

Tiempo de espera indeterminado debido al proceso de adquirirbloqueos





Ventajas de las copias logicas

Archivos que se pueden manipular e inspeccionar con editores detextosFaciles de restaurarSe pueden restaurar en una maquina diferenteIndependientes del motor de almacenamientoSe pueden retocar para exportar a otros SGBD

Desventajas de las copias logicas

El servidor debe hacer el trabajo de generarlasPueden llegar a ocupar mucho mas que los datos en algunos casosLa reconstruccion implica volver a ejecutar todas las sentencias yregenerar todos los ındices.





Ventajas de las copias sin procesar

No hay trabajo adicional: se copian los archivos tal cualLa restauracion puede ser sencillısima: para MyISAM, simplementecopiar los archivos en su sitio; InnoDB, en cambio, obliga a detenerel servidorLa restauracion es mas rapida: no hay que ejecutar sentencias, nireconstruir ındices

Desventajas de las copias sin procesar

Suelen ocupar mucho mas espacio que las copias logicas (porejemplo, el espacio de tabla InnoDB incluye mucho espacio sinutilizar)No siempre se pueden mover a traves de las plataformas, SO yversiones de SQL (mayusculas/minusculas, representacion puntoflotante)




Procedimiento de copia logica

Copia

Realizar un volcado SQL con mysqldump o CSV con SELECT *INTO OUTFILE

Restauracion

Ejecutar el script SQL o importar el CSV con LOAD DATA INFILEINTO TABLE

Problemas:

En el volcado SQL los esquemas y datos almacenados juntos, en elvolcado CSV no hay esquemasLos archivos pueden ser enormes (y los editores de texto no podranabrirlos)




Procedimiento de copia logica

Hay que asegurar que los datos son consistentes en un punto detiempo determinado (por ejemplo, en una BD de comercioelectronico debe haber una factura por cada pago). Es complicadoen copias calientes

En motores transaccionales: realizar la copia en una transaccionEn motores no transaccionales, bloquear todas las tablas que sedeben copiar juntasEsto no nos protege de una aplicacion mal disenada (por ejemplo, siel pago y la factura se registran en dos transacciones distintas)




Procedimiento de copia sin procesar

Copia

MyISAM: bloquear las tablas y copiar los archivos de datosInnoDB:

Bloquear las tablas no es suficiente porque los cambios se reflejan enel registro de transacciones y no en el espacio de tablasAlternativa: parar el servidor o usar tecnicas de gestion de ficheros delSO (por ejemplo, LVM)

Restauracion:

MyISAM: bloquear las tablas y copiar los archivos de datosInnoDB: parar el servidor y sustituir los archivos




Procedimiento de copias de seguridad incrementales

Activar el registro binario de mySQL

Copia:

Realizar copias completas con los procedimientos anterioresRealizar copias incrementales del registro binario

Restauracion:

Restaurar la copia completa y ejecutar todos los registro binarios

Restauracion a un punto concreto del tiempo

Localizar el punto de tiempo en los registros binarios y ejecutar hastaesa posicion

Eliminar el resultado de una instruccion

Localizar la instruccion y ejecutar el registro binario hasta esaposicion y desde despues de esa posicion



Medicion de rendimiento y perfilado

Contenidos







Medicion del rendimiento y perfilado

El objetivo de la optimizacion es aumentar el rendimiento de MySQL

Los elementos a optimizar son muchos. Ej: esquemas, ındices,consultas, configuracion del servidor, hardware, software, aplicaciones

Necesitamos dos practicas basicas:Medicion del rendimiento. Responde a ¿Como se ejecuta?

Permiten evaluar el desempeno del SGBDPermiten determinar la capacidad maxima del sistemaPermiten discriminar los cambios que importan de los que noMuestran como se ejecuta la aplicacion con datos diferentes

Perfilado. Responde a ¿Por que se ejecuta ası?

Indica cuanto contribuye cada elemento de un sistema al coste deproducir el resultadoLugares donde se pierde mas tiempoLugares donde se consumen mas recursos




Medicion del rendimiento

Contenidos

1 Introduccion a MySQL

2 Replicacion

3 Copia de seguridad y recuperacion

4 Medicion de rendimiento y perfilado


Perfilado de aplicaciones

5 Optimizacion

Optimizacion de esquemas e ındices

Optimizacion de hw. y sw.

Optimizacion del servidor





Objetivos de las medidas

Las medidas de rendimiento permiten realizar las siguientes tareas:

Medir rendimiento actual de nuestra aplicacion

Necesario para poder comparar efecto de cambiosDiagnosticar problemas no previstos

Validar la escalabilidad del sistema

Pruebas comparativas con cargas masivas

Planificar el crecimiento

Estimar hw., capacidad de red y otros recursos para la carga futuraprevista

Probar la capacidad de adaptacion a entornos cambiantes

Picos esporadicos, configuraciones diferentes de servidores

Probar configuraciones diferentes de hw., sw. y so.

¿RAID5 o RAID10? ¿nucleo 2.4 o 2.6 de Linux? ¿escala bien condoble de memoria?





Estrategias para medir

Existen dos estrategias en la medida de rendimiento:

Aplicacion como un todo

La preocupacion ultima es el rendimiento de toda la aplicacionMySQL no es siempre el cuello de botella. Una prueba de pilacompleta pude revelarloLos puntos de referencia para medir rendimiento son buenos sireflejan el comportamiento real de toda la aplicacion. Es mas difıcil sisolo probamos una parte de ella

Aislar mySQL (SGBD, en general)

Es difıcil aislar puntos de referencia y de configuracion de laaplicacionAcercamiento paulatino: empezar por mySQLInteresan medidas de rendimiento cortas, con “tiempo de ciclo mascorto”Facil aislar consultas tıpicas y repetirlas muchas veces





Ejemplos de medidas de rendimiento

Transacciones por unidad de tiempo (clasica)

Se ajusta bien a aplicaciones interactivas de multiples usuarios, OLTPUnidad tıpica: transacciones por segundo

Tiempo de respuesta (latencia)

Mide tiempo total requerido por una tarea (ej: milesimas, minutos)La ejecucion repetida permite derivar tiempos de respuesta mınimo,maximo o medioLos tiempos mınimos y maximos no son muy utiles porque no sonrepetibles, cuanto mas tiempo se ejecute la medida, mas extremosseran, y varıan mucho entre diferentes ejecucionesEn general es mejor agregar utilizando percentiles (ej: el 95 % de lasrespuestas se responden en menos de 5 ms)





Ejemplos de medidas de rendimiento

Concurrencia

Medimos el rendimiento de la aplicacion bajo diferentes niveles deconcurrenciaUn ejemplo de medida: numero solicitudes atendidas respecto a lassolicitadas en un segundoEs importante mediar las consultas que se realizan, no las conexionesestablecidas, ya que los servidores y los clientes actuales incluyen un poolde conexionesNo solo es un resultado, tambien es una propiedad que debemosconfigurar en nuestras pruebas

Escalabilidad

Util en sistemas que tienen que mantener un rendimiento estable bajocarga de trabajo cambianteGeneralmente se utilizan medidas de tiempo de respuesta probando condiferentes intensidades de cargaLa intensidad de carga se varia cambiando (entre otros):

El tamano de la base datosEl numero de conexiones concurrentesEl hw. disponible





Errores comunes en las medidas

Algunos errores comunes en la definicion de medidas de rendimiento:

Usar un subconjunto no representativo de los datos

Utilizar datos sinteticos distribuidos uniformemente

Definir un escenario con un solo usuario

Medir en un solo servidor el rendimiento de una aplicacion distribuida

Fallo en imitar el comportamiento del usuario: clics en vınculos unotras otro sin parar, en una aplicacion web

Ejecutar consultas identicas en un bucle, olvidando posibles perdidasen cache

No detectar los errores en el proceso de medida (ej: que unaoperacion lenta se agilice mucho puede ser debido a un error desintaxis en SQL)

Olvidar tener en cuenta latencia del servidor despues de reinicio





Planificacion de medidas de rendimiento

Proceso de planificacion de una medida de rendimiento

Identificar el objetivo de la medida y definir indicadores paraevaluarlo

Un objetivo mal definido: “El nuevo ındice agiliza las consultas”Un objetivo bien definido: “El nuevo ındice reduce el tiempo derespuesta de la consulta en un 10 %”

Decidir si usaremos una prueba estandar o una prueba de disenopropio

Definir un plan de toma de medidas porque tendremos que repetir laprueba varias veces y necesitamos reproducirla exactamente

Datos de partida de la pruebaPasos seguidos para configurar sistemaPlan de calentamientoDocumentacion de los parametrosAlmacenamiento de los resultados





Planificacion de medidas de rendimiento

Proceso de planificacion de una medida de rendimiento

Realizar la toma de medidas

Usar diferentes intervalos de tiempo para cubrir todas las actividades delsistemaDebemos asegurar que la prueba es significativa y repetible (ej: usandouna instantanea de los datos, usando el servidor en caliente)Debemos tener cuidado con la carga externa y con las tareas periodicasCambiar la menor cantidad de parametros posible en cada prueba (losindependientes)Es recomendable automatizar las ejecuciones de las pruebas (scripts,makefiles)El numero de repeticiones depende del grado de certeza que se quieraalcanzar. Comunmente:

Ejecutar varias veces y eliminar los resultados discrepantesEjecutar hasta que los resultados no varıen demasiado (reducir la varianza)Utilizar tecnicas estadısticas

Analizar los resultados

Los resultados agregados permiten dar una idea general de la medidaLos resultados detallados permiten detectar picos ocultos por laagregacion





Herramientas para medidas de rendimiento

Herramientas especıficas de mySQL

mysqlslap

Incluido desde la version 5.1 con mySQLSimula carga en el servidor e informa sobre el tiempoMuy configurable, ej: numero de conexiones concurrentesPermite una instruccion SQL en lınea de comandos o un archivo coninstrucciones SQL

MySQL Benchmark suite

Incluido desde la version 5.0 con mySQLMide lo rapido que ejecuta el servidor las consultasMuchas pruebas predefinidas, que permiten comparar diferentesmotores de almacenamiento y configuracionesMejorable (un solo usuario, el conjunto de datos es pequeno, y usaun solo proceso (no multiples CPU)






Herramientas especıficas de mySQL

sysbench

Tests predefinidos para medir rendimiento de servidor y SGBDPruebas de rendimiento de CPU, memoria, threads, etc.Pruebas de rendimiento de la E/S de archivos: comparar discosduros, tarjetas RAID, modos RAID, etc.Pruebas de comparacion OLTPDesarrollo parado

Super Smack

Pruebas de comparacion + Prueba de estres + Herramienta degeneracion de carga para MySQL y PostgreSQLMultiples usuarios, carga datos de prueba (aleatorios)Lenguaje neutro (smack) para definir clientes, tablas, consultas, etc.Desarrollo parado






Herramientas de pila completa

Ab

Incluida con el servidor HTTP ApacheCalcula el numero de solicitudes que puede servir por segundoSolo prueba una URL todo lo rapido que pueda

httpload

Utiliza un archivo de entrada con muchas URLs de las que eligealeatoriamentePrueba lo mas rapido que pueda, o segun una velocidad establecida(-rate)Tambien simula usuarios concurrentes (-parallel)

JMeter

Aplicacion Java para medir el rendimiento de otros programasSimula usuarios reales (tiempo de escalada configurable)Interfaz grafica que permite reproducir prueba fuera de lınea





Contenidos

1 Introduccion a MySQL

2 Replicacion

3 Copia de seguridad y recuperacion

4 Medicion de rendimiento y perfilado



5 Optimizacion








Objetivos del perfilado

El perfilado de un sistema nos indica cuanto contribuye cadaelemento al coste total de produccion de un resultado

Permite entender por que un sistema se ejecuta como lo hace

Es necesesario considerar el sistema completo porque:Si nos centramos en ejecutar, analizar, y optimizar consultasperdemos mucha informacion

Procesamiento de resultados en memoriaLlamadas a recursos externosAlgoritmos poco optimos

Si nos limitamos a medir tiempo de respuesta del servidor web

No tenemos estadısticas del sistema que permitan determinar queesfuerzo permite una mayor mejora

El cuello de botella puede estar en otra parte.





Proceso de perfilado

Es necesario incluir codigo de perfilado en las aplicaciones que tomemediciones de:

Tiempo total de ejecucion de la paginaTiempo de ejecucion de las consultasTiempo de llamadas a recursos externos (servicios web)

Es una sobrecarga al sistema, por lo que es necesario aplicar tacticascomo

Solo realizar el perfilado en un porcentaje pequeno de las peticionesGuardar los datos en memoria y hacerlos persistentes en bloque





Perfilado en MySQL

MySQL mantiene dos registros de consultas: el registro general y elregistro de consultas lentas

El registro general

Se guardan todas las consultas que se reciben aunque por error no seterminen ejecutandoSe guardan los eventos de conexion y desconexionSin tiempos de ejecucion: de poco interes para el perfilado

El registro de consultas lentas

Registra las consultas ejecutadas que sobrepasan un determinadotiempoSe puede configurar para registrar tambien las consultas que noutilizan ındicesGuarda tiempos de ejecucion: permite perfiladoEs difıcil de utilizar:

Una consulta es lenta porque tarda mas de lo esperado, no porquetarda mas que un umbral de tiempoHay consultas que no tienen que usar el ındice de ningun modo





Perfilado en MySQL

Desde la version 5.1.28, MySQL permite realizar perfilado de losrecursos usados en una sesion

Se activa mediante la variable profilingSe consulta mediante SHOW PROFILES y SHOW PROFILE [FORQUERY n]Registra multitud de variables para cada uno de los estados de todaslas consultas ejecutadasLos datos se pueden consultar agregados o a nivel de consultaindividualLos datos se guardan en memoria mientras dure la sesion

La estrategia de analisis de resultados puede ser:

Comprobar que consultas tienen mas impactoComprobar el plan de ejecucion de esas consultas con EXPLAINRealizar los ajustes necesariosRepetir el analisis



Optimizacion


Contenidos






Optimizacion



Optimizar esquema mal disenado o mal indizado mejora delrendimiento en ordenes de magnitud

Sin embargo, hay que tener cuidado con los efectos secundarios

Un nuevo ındice INSERT y UPDATE mas lentasLas tablas de resumen y los contadores agilizan consultas, pero elmantenimiento es mas costosoLos cambios requieren conocer todo el sistema y cada elementoafectado

Describiremos estas tecnicas:

Eleccion de tipos de datos optimos y seleccion de clave primariaDistintos tipos de ındices: B+, Hash y agrupadosEstrategias de indexadoIndices para ordenacionTablas de cache y de resumenTablas de contadoresDesnormalizacion



Optimizacion


Eleccion de tipos de datos optimos

Elegir adecuadamente el tamano es importante

Usar el tipo de datos mas pequeno posible

Menos espacio en disco, memoria y CPU

Cuanto mas sencillos mejor

Tipos de datos simples, menos ciclos de CPU.Por ejemplo, enteros para IPs, y no cadenas (una IP es un entero de32 bits sin signo): INET ATON(), INET NTOA()

Evitar valores NULL. Indicar NOT NULL siempre que sea posible

Complicado optimizar si hay columnas con valores NULLColumnas NULL usan mas espacio de almacenamiento y requierenprocesamiento especial. (i.e. byte adicional en ındice)A ser posible, usar cero, valor especial, cadena vacıa, . . .

Proceso:

Paso 1: Determinar tipo de datos: numerico, cadena, temporalPaso 2: Elegir tipo especıfico



Optimizacion



DATETIME vs. TIMESTAMPDatetime: Entero empaquetado (YYYMMDDHHMMSS) de 8 bytes.Mayor rango de valores (1001-9999, con precision de 1 segundo).Timestamp: Entero de 4 bytes. Numero de segundos desde 0:00 del1/1/1970 en meridiano Greenwich. Mitad de espacio y utiliza zonahoraria.

CHAR vs. VARCHARCHAR

Longitud fijaVale la pena para valores muy cortos o cuando todos los valorestienen aprox. la misma longitud.

VARCHARMenos espacio por ser longitud variable1 o 2 bytes adicionales para almacenar longitud (varchar(10): hasta11 bytes; varchar(1000): hasta 1002 bytes)Filas ocupan menos, pero pueden crecer mas adelante(fragmentacion, reasignacion de espacio)Vale la pena cuando la longitud maxima de columna es mucho mayorque la media y hay pocas actualizaciones, o cuando el cjto. caracterescomplejo, codificacion variable (UTF-8).



Optimizacion



VARCHAR(5) vs. VARCHAR(200)

Un texto de cuatro caracteres ocupa lo mismo en ambos casos, nohay diferencia en almacenamiento secundarioMySQL asigna fragmentos de tamano fijo a la memoriaTabla temporal para ordenacion: reservarıa espacio para el maximotamano posible (motor Memory necesita filas de tamano fijo)Mejor reservar el tamano justo

BLOB y TEXT

Guardan grandes cantidades de datos (binarios y de cadena)Cada motor, diferente gestionEvitar usarlos en el ORDER BY ya que el motor Memory no permitecampos TEXT ni BLOB, ası que habrıa que usar myISAM para latabla temporal de ordenacion)Truco (longitud lo bastante corta para que la tabla no sobrepasetmp table size) ORDER BY SUBSTRING(columna text, longitud)



Optimizacion



ENUM en lugar de cadenasAhorro de espacioEs solucion solo para listas fijas de cadenas. Ampliarla: ALTERTABLEAdemas: sobrecarga de conversion de valores (por ejemplo, alconcatenar o al comparar)Usar solo si la lista de cadenas no va a cambiar en el futuro



Optimizacion


Seleccion de clave primaria

Debe ser el mismo tipo en todas las tablas relacionadas ya que tiposdistintos afectan al rendimiento debido a las conversiones

InnoDB no permite claves foraneas si no hay coincidencia exactaConversiones de tipo implıcitas pueden provocar errores difıciles dedetectar

Elegir tamano mas pequeno necesario dejando espacio paracrecimiento futuro

Por ejemplo: un entero (4 bytes) para codigos de provincias implicamucho espacio en claves externas

Las cadenas de caracteres son una mala eleccion porque ocupanmucho espacio y son mas lentas que los enterosLas cadenas de caracteres aleatorias (estilo UUID) implican:

ralentizacion de los INSERT ya que el valor se inserta en una posicionaleatoria del ındice que puede crear fragmentacion de paginasmal rendimiento de las caches ya que se elimina la localidadralentizacion de los SELECT porque filas adyacentes en el resultadoquedan dispersas en disco y memoria si las filas se almacenanordenadas por clave



Optimizacion


Revision de los esquemas generados automaticamente

Proceso tradicional: Modelado conceptual, logico y fısico

Proceso de mapeado objeto-relacional: anotacion de clases ycreacion de esquemas

Proceso model-driven engineering: modelado conceptual y creacionautomatica de esquemas

Posibles problemas

Uso reiterado de tipos VARCHAR sin lımiteTipos de datos en columnas de combinacion que no coincidenEl objetivo principal es que cualquier clase puede ser almacenada encualquier SGBD, lo que puede provocar:

Tablas con cada propiedad de un objeto en una filaVersiones de cada propiedad usando timestamps



Optimizacion


Indices

Mas importantes a medida que nuestros datos crecen

Por ejemplo, en una consulta como

SELECT first_name FROM actor where actor_id=5;

Si hay ındice sobre actor id se busca sobre el ındice y se recuperanpunteros a las filas en la tabla

Si se define el ındice sobre varias columnas el orden en el que seindican las columnas es muy importante ya que MySQL solo buscaeficientemente el prefijo en la parte mas a la izquierda del ındice

Crear un ındice sobre dos columnas no es lo mismo que crear dosındices de una sola columna independientes

Los ındices se implementan a nivel de motor de almacenamiento (noen capa de servidor), por lo que no todos los motores admiten todoslos tipos de ındices



Optimizacion


Arbol B y B+

Admitido por todos los motores (menos Archive)Cada motor lo implementa a su modo. Por ejemplo, MyISAM usacompresion mientras que InnoDB no usa compresionIdea general: todos los valores se almacenan en orden y se accedemediante un arbol en el que cada hoja esta a la misma distancia dela raız y las paginas de hojas contienen punteros a los registros de latabla.Agiliza acceso a los datos. Se realiza un acceso al nodo raız y e vadescendiendo por las ramas escogiendo punteros adecuados hastallegar al valor correcto.



Optimizacion


Arbol B y B+



Optimizacion


Arbol B y B+

Tipos de consulta que pueden usar ındice de un arbol B

Coincidencia con valor completo.

apellidos = ’Allen’ and nombre = ’Cuba’ and fnac = ’01-01-1960’

Coincidencia parcial con prefijo de columna

apellidos like ’A %’

Coincidencia parcial con prefijo mas a la izquierda

apellidos = ’Allen’ and nombre like ’C %’

Coincidencia con rango de valores

apellidos >= ’Allen %’ and apellidos <= ’Barrimore %’

Clausulas ORDER BY por los campos del ındice



Optimizacion


Arbol B y B+

Limitaciones. No son utiles en:

Busquedas que no empiezan en la parte mas izquierda de lascolumnas indizadas. Ejemplos:

nombre = ’Cuba’ and fnac = ’01-01-1960’

apellidos like ’ %Z’

No permiten saltar columnas del ındice. Ejemplo:

apellidos = ’Allen’ and fnac = ’01-01-1960’

No se optimiza el acceso a columnas a la derecha de la primeracondicion de rango. Por ejemplo:

apellidos = ’Allen’ AND nombre >= ’J’ AND fnac = ’23-12-1976’



Optimizacion


Indices Hash

Solo soportado por el motor Memory (el indice por defecto)Para cada fila se crea un codigo hash con las columnas indizadasEl ındice es una tabla hash con apuntadores de fila (muy compactos)Las colisiones de la funcion hash se almacenan con una lista enlazadaUtil solo para busquedas que usan todas las columnas del ındice. Noadmiten coincidencia parcial de claveProblemas

No se pueden usar los ındices para ordenar ya que el ındice ordenapor hash, no por el valor original.No evita leer las filas ya que en el ındice solo se almacena un puntoal registroSolo permite comparaciones de igualdad (=, IN) pero no consultasde rangos (>100)Las colisiones de la funcion hash ralentizan el acceso y elmantenimiento

Es posible simular ındice hash con una columna extra, un arbol B+ ytriggers



Optimizacion


Indices agrupados

Las filas de las tablas se guardan en las paginas hoja del ındice

Las filas con valores de clave adyacentes se guardan juntas

Ahorra operaciones de E/S en consultas con datos relacionados

Los ındices tradicionales pueden ocupar mas espacio del esperado yaque en vez de punteros a registros almacenan valores de claveprimaria

No todos los motores los admiten

InnoDB lo hace implıcito con la clave primaria, con un ındice unicosin valores NULL, o con una clave interna ocultaInconvenientes:

Solo ahorra E/S si los datos no caben en memoriaLa velocidad de insercion depende del orden de insercion (lo mejor,en el orden de la clave primaria)La actualizacion es costosa debido a la reubicacion de paginasPaginas mas sujetas a fragmentacion al insertar filas nuevasPueden ser mas lentas para escaneos completos



Optimizacion


Otros ındices

Indices espaciales (arbol R)

Solo en motor MyISAMSolo para los tipos de datos y operaciones de geometrıa espacial(GEOMETRY)El soporte espacial de MySQL no es muy completo

Indices de texto completo

Solo en el motor MyISAMPermite busquedas de palabras clave en textos y calculo derelevanciasSoporta conceptos de recuperacion de informacion (stopwords,lematizacion, busqueda booleana)



Optimizacion


Estrategias de indexado: aislar columnas

Aislar la columna en las consultas para que no forme parte de unaexpresion ni sea argumento de funciones

Ejemplos que no usan el ındice:

SELECT actor_id FROM actor WHERE actor_id+1=5;

SELECT ... WHERE TO_DAYS(CURRENT_DATE) - TO_DAYS(date_col) <= 10;

Ejemplos que usan el ındice:

SELECT actor_id FROM actor WHERE actor_id=4;

SELECT ... WHERE date_col >= DATE_SUB(CURRENT_DATE, INTERVAL 10

DAY);



Optimizacion


Estrategias de indexado: Construir ındices sobre prefijos

Permite indexar columnas de caracteres largas

Indexar solo los primeros caracteres en lugar de todo el valor

Es necesario buscar el tamano idoneo que mantiene el ındicealtamente selectivo

Selectividad = Valores diferentes indexados / Valores totalesBastante largo para proporcionar buena selectividadBastante corto como para ahorrar espacio



Optimizacion



Distribucion de los valores diferentes



Optimizacion



Calculo de las selectividades



Optimizacion



Distribucion con prefijo de 3 caracteres



Optimizacion






Optimizacion


Estrategias de indexado: Indices de cobertura

Incluır en el ındice todas las columnas necesarios para resolver unaconsultaMySQL puede utilizar ındices para recuperar valores de una columnasin tener que acceder para nada a la filaVentajas:

Como las entradas del ındice son mas pequenas que el tamano totalde la fila encajan mejor en memoria y caben en cache de los motoresde almacenamientoComo los ındices se ordenan por valor los accesos de rango requierenmenos E/SSe evitan bloqueos porque si no accedemos a la fila, no hace faltabloquearla



Optimizacion


Usar ındices para ordenacion

MySQL ordena los resultados usando dos metodos: escaneando unındice en orden (rapido) o mediante ordenacion de archivos (lento)

El escaneado del ındice solo se puede hacer si cubre el where y elorder by (las condiciones y columnas forman un prefijo del ındice)

Ejemplos en los que no lo cubre:

Se ordena de forma descendente (el ındice ordena de formaascendente)Se usa en el order by una columna que no esta en el ındice



Optimizacion


Tablas de cache y resumen

Crear tablas de resumen o de cache independientes de los datos departida

Tablas de resumen: Resultados obtenidos con GROUP BY (datosplegados)Tablas de cache: Datos que se recuperan frecuentemente del esquema

Funciona si podemos tolerar datos ligeramente desactualizados

Debemos decidir si se actualizan las tablas en tiempo real o de formaperiodica

La reconstruccion debe hacerse usando tablas sombreadas parapoder seguir usando las tablas resumen antiguas

Cuando tenemos lista la nueva tabla resumen, cambiamos el nombre



Optimizacion


Tablas de contadores

Se aconseja que las tablas de contadores sean independientes

Resulta en tablas rapidas y pequenas

Un contador es esencialmente un semaforo que crea problemas deconcurrencia

CREATE TABLE hit_counter (cnt int unsigned not null);

UPDATE hit_counter SET cnt=cnt+1;

Se recomienda paralelizar mediante contadores parciales:

CREATE TABLE hit_counter (slot tinyint unsigned not null

primary key, cnt int unsigned not null);

UPDATE hit_counter SET cnt=cnt+1 WHERE slot=RAND()*100;

SELECT SUM(cnt) FROM hit_counter;



Optimizacion


Desnormalizacion

Las actualizaciones normalizadas son mas rapidas que las nonormalizadas

En los datos normalizados no hay redundancia por lo que hay menosdatos que modificar

No tener redundancia implica un menor uso de DISTINCT oGROUP BY

Las tablas normalizadas son mas pequenas por lo que encajan mejoren memoria

Sin embargo, en un esquema normalizado las recuperacionesimplican combinaciones que son costosas



Optimizacion


Contenidos






Optimizacion


Introduccion

El hardware y el software sobre los que se ejecuta SGBD determinanla eficiencia de MySQL (tamano de disco, memoria disponible,recursos de CPU, red . . . )

Se necesitan directrices para resolver cuellos de botella del hardwarey del sistema operativo

Prestaremos atencion a los siguientes aspectos

Seleccion de CPUEquilibrar recursos de memoria y discoElegir discos (RAID, NAS)Configuracion de red



Optimizacion


Introduccion

Cuellos de botella comunes:

Saturacion de CPU. Comun cuando MySQL trabaja con datos quecaben en memoria o pueden ser leıdos de disco tan rapido como seanecesario. Ejemplos: ops. criptograficas intensivas, combinaciones sinındicesSaturacion E/S. Se trabaja con mas datos de los que caben enmemoria. Se vacıa cache para traer mas datos, y al rato los datosvaciados se tienen que volver a cargar

Posibles errores de interpretacion:

Escasez de memoria se puede interpretar como falta de capacidadE/SBus de memoria saturado se puede interpretar como problema de laCPU



Optimizacion


Seleccion de la CPU

¿CPU rapida o muchas CPUs no tan rapidas?

MySQL aprovecha mal el paralelismo ya que asigna una operacion auna CPU. Problemas de escala con muchas CPU

En funcion del tipos de rendimiento deseable:Baja latencia

Tiempo de respuesta rapido para cada consulta.Mejor CPUs rapidas porque cada peticion solo aprovecha una CPU.

Alto rendimiento:

Muchas peticiones simultaneas.Mejor muchas CPUs, pero como MySQL escala mal no funciona el“cuantas mas mejor”.Al final: meter mas CPUs hasta que deje de compensar y llegados aese punto: intentar que sean lo mas rapidas posible.



Optimizacion


Seleccion de la CPU

¿Cuando compensan muchas CPUs?

MySQL puede aprovechar CPUs “secundarias” para tareas en segundoplano (ops. de red, limpieza de buferes InnoDB)Esas tareas son “menores” en comparacion con la ejecucion depeticiones de los usuariosMuchas CPUs compensan realmente si:

Muchas conexiones que acceden a tablas diferentes (no compiten porbloqueos)Rendimiento total del servidor mas importante que el tiempo derespuesta de una peticion particular



Optimizacion


Equilibrar recursos memoria / disco

Disponer de mucha memoria evita E/S del discoEs necesario encontrar un equilibrio entre el tamano de memoria ydisco teniendo en cuenta rendimiento y costeEjemplo: Lecturas aleatorias o secuenciales

Discos actuales: 200 operaciones E/S por segundo, 200 MB/segundode forma secuencialMemoria actual: 1.300 millones de operaciones E/S por segundo,10.000 MB/segundo de forma secuencialAcceso aleatorio: 200 filas/segundo de disco, 100.000 filas/segundode memoriaAcceso secuencial: 2 millones de filas/segundo de disco, 10 millonesde filas/segundo de memoria

Resultado: Lecturas aleatorias o secuencialesAccesos aleatorios: 500 veces mas rapidos en memoria que en discoAccesos secuenciales: 5 veces mas rapidos en memoria que en discoSe ahorra mucho mas trabajo almacenando lecturas aleatorias encacheAnadir memoria es la solucion para solucionar problemas de E/SaleatoriaEnxenarıa Informatica Miguel R. Luaces ([email protected]) - Juan Ramon Lopez Rodrıguez


Optimizacion



Cache de las BDs (ej. grupo de buferes InnoDB) funciona mejor quecache de SO (generalista)

Mas conocimiento sobre los datos que necesitaLogica para fines especialesNo necesita llamadas al sistema

Aspectos a tener en cuenta al considerar el tamano de la cacheConjunto de trabajo

Datos que la aplicacion necesita en la cache en memoriaIncluye datos e ındices

Unidad de cache

Unidad de datos mas pequena con la que puede trabajar el motor dealmacenamientoInnoDB: 16KBFila 100 Bytes puede necesitar cargar 32 KB en cache (datos e ındice)



Optimizacion



Perdida de cache: datos no en cache, hay que ir a buscarlos a discoForma facil de medirla: por el uso CPU (90 % tiempo CPU, 10 %E/S -> proporcion perdida cache buena)Buscar proporcion de perdida aceptable

No se arregla simplemente anadiendo mas memoria (ej., deficienciaspor tamano de unidad de cache)Ejemplo:

Sistema con 10 GB de memoria con 10 % perdidaSi fuese lineal: 11 % mas de memoria (11,1 GB) nos darıa 0 % deperdidaEn realidad, bajar a 1 % podrıa requerir 500 GB de memoria

La escalibilidad la determina el eslabon mas debilEjemplo:

sistema con 16 GB memoria, 20 GB datos y mucho disco libre quefunciona bienAlgunos componentes pueden estar a mas del 50 % de su capacidadmaxima (ej. 80 % de numero maximo de operaciones de E/S)Aumentar a 40 GB datos (doble) no se puede soportar aumentandosimplemente la memoria: la velocidad de transferencia del discofunciona a tope!!



Optimizacion


Seleccion de discos

Factores a tener en cuenta:Capacidad de almacenamiento

No suele ser un problema (tamano actual de los discos mas quesuficiente)Practica estandar: combinar discos pequenos y RAIDVentajoso tener mas capacidad de la necesaria: aumenta la localidadde los datos

Velocidad de transferencia: no suele ser un factor que limite lasaplicaciones onlineTiempo de acceso: es el factor determinante para agilizar busquedasaleatoriasTamano fısico: discos mas pequenos son mas rapidos y ocupanmenos (fısicamente)El aprovechamiento depende del motor. InnoDB escala bien entre 10y 20 discos



Optimizacion


Seleccion de discos

Seleccion de RAID



Optimizacion


Seleccion de discos

Multiples volumenes ¿Donde colocamos los archivos?

Archivos de datos e ındiceArchivos de registros transaccionalesArchivos de registros binariosArchivos de registro general (registros de errores, registro depeticiones, registro de consultas lentas, . . . )Archivos y tablas temporales

Por defecto, todos los archivos en un unico directorio

InnoDB:

datos e ındices en un unico conjunto de archivosSolo los archivos de definicion de tablas van aparte, en el directoriode cada base de datos



Optimizacion


Seleccion de discos

Multiples volumenes

Usar multiples volumenes puede ayudarnos a gestionar E/S pesadaRegla clasica: registros transaccionales y archivos de datos envolumenes diferentes

E/S secuencial de tx. no interfiere con E/S aleatoria de datos

En realidad, no es tal ventaja

Escrituras en registro son pequenasCaches RAID agrupan escrituras: se convierten en muchas menosescrituras por segundoNo interfieren con E/S de datos

Ventaja real:

En caso de fallo, mucho mas seguro tenerlos separadosSi se pierden los datos: se pueden recuperar usando el registroRecuperacion point-in-time



Optimizacion


Seleccion de discos

Dedicar discos a registros transaccionales depende del coste, no delrendimiento

Ejemplo:4 discos duros: 2 para datos, 2 para registros transaccionales

1/2 del disco perdido para datos1 disco para un trabajo trivial (la cache del disco hace todo el trabajo)

10 discos duros: 2 para datos, 2 para registros transaccionales

Proporcionalmente menos caro

Configuracion tıpica:

SO, swap y registros binarios en RAID 1

Resto: un unico volumen en RAID 5 o RAID 10



Optimizacion


Configuracion de red

El mayor problema es la latencia

En una aplicacion tıpica hay muchas transferencias pequenas y sesuman los retrasos de cada transmision

La causa principal es la perdida de paquetes, 1 % de perdida producedegradacion significativa

Optimizaciones:Pocas conexiones, peticiones o resultados grandes: aumentar eltamano del buffer TCP

Aumenta el numero de paquetes que se pueden mandar “de unatacada”Modificable en origen y destino

Solo conexiones locales: acortar timeout de cierre de conexion (pordefecto, un minuto)Otras: Eliminar latencia resolucion DNS: skip name resolve



Optimizacion


Contenidos






Optimizacion


Introduccion

No existe el archivo de configuracion optimo.Cada servidor necesita una configuracion diferente, dependiendo de:

hardwaretamano datos,tipos de consultasRequisitos del sistema (tiempo de respuesta, duracion tx,consistencia, . . . )

La configuracion de MySQL predeterminada esta pensada para noutilizar muchos recursos.

No da por hecho maquina dedicada.Reserva recursos suficientes para iniciar MySQL y ejecutar consultassobre pocos datos

Para definir configuracion a medida:Partir de alguno de los ficheros de configuracion de ejemplo.No esperar muchas mejoras con cada cambioInicialmente, cambios que duplican o triplican rendimientoDespues, mejoras incrementales



Optimizacion


Introduccion

La configuracion permanente MySQL se almacena fichero my.cnf

Se configura mediante la asignacion de valores a variables

Es posible ejecutar multiples instancias desde una sola configuracioncon secciones independientes.

Ambitos de las variables:

Global (se aplican al servidor y a cada conexion)Sesion (se aplican a una conexion especıfica)Especıficas para un objeto

Valores demasiado altos generan problemas (i.e. quedarnos sinmemoria)



Optimizacion


Introduccion

El proceso debe ser el siguiente:Preparar y realizar mediciones de prueba antes de empezar a ajustarservidor

Pruebas que representen carga de trabajo realIncluir consultas complejas

Definir un sistema de supervision para medir si cambio mejora oempeora rendimientoCambiar una o dos variables, un poco, cada vez, y hacer prueba demedicionAjustar hasta que todo funciona “bastante bien”No insistir a menos que creamos que podemos obtener mejorasignificativa (el esfuerzo no compensa)

Los “acantilados” son tıpicos: incrementamos variable un poco ymejora rendimiento; la incrementamos un poco mas, y elrendimiento cae en picado



Optimizacion


Introduccion

No comenzar a ajustar configuracion sin un esquema y consultasestables

Todos los ındices creadosSi modificamos esquema despues de ajustar configuracion: volver aempezar

Describiremos estos aspectos

Ajuste de uso de memoriaAjustes de cachesAjustes E/SConcurrencia



Optimizacion


Ajuste de uso de memoria

Comenzar con el lımite superior de memoria disponible para MySQL

Restar la memoria que necesita SO para ejecutarse bien

Restar la memoria necesaria para cada conexion (buffer ordenacion,tablas temporales)

Usar el resto memoria para las caches de MySQL



Optimizacion



Lımite superior de memoria

Inicial: memoria fısica del servidorKernel Linux limita tamano maximo memoria para un proceso (engeneral, parametros especıficos del SO como el tamano de pilas . . . )Librerıas (glibc) tambien pueden fijar sus propios lımites

Memoria para el SO

Necesario reservar memoria para que el SO haga su trabajoMejor indicador de asignacion correcta: poco intercambio dememoria virtualNormalmente: 1-2 GB (incluso en maquinas con mucha memoriafısica)Asignar siempre algo de memoria adicional (para tareas periodicasque consuman mucha memoria, copias de seguridad . . . )No tener en cuenta memoria para caches (esa la tratamos aparte)



Optimizacion



Necesidades de memoria por conexion

Cada conexion, pequena cantidad de memoria para mantenerseabiertaTambien, pequena cantidad para ejecutar una consulta dadaNecesitamos memoria suficiente para momentos de picos de cargaDifıcil de predecir. No es necesario suponer peor caso. Ejemplo:

Configurar para 100 conexiones simultaneasFijamos tamano maximo buffer ordenacion (uno por conexion) en 256MBPeor caso: pico de carga supondrıa 25 GB (Muy poco probable)

Buena solucion: observar servidor con carga de trabajo real ycomprobar cuanta memoria utiliza



Optimizacion



Toda la memoria que no se use: dedicada a caches

MySQL necesita mas memoria para caches que para el resto deelementos

Cache del SO trabaja para MySQL. . . pero MySQL necesita mucha memoria para sı mismo

Caches mas importantes:

Cache de claves MyISAMGrupo de buferes InnoDBCache de subprocesos

Existen otras caches, pero no requieren mucha memoria

Mas facil ajustar servidor que usa un unico motor de almacenamiento

Mezcla de motores: difıcil encontrar equilibrio



Optimizacion


Cache de claves MyISAM

Para almacenar ındices (no datos, MyISAM lo delega en el sistemaoperativo)

Si solo usamos MyISAM: dedicar mucha memoria a esta cache

Si se usa tambien InnoDB: ajustar al 25-30 % de la cantidad dememoria reservada para las caches

Una predeterminada, pero se pueden crear mas

key_buffer_1.key_buffer_size=1G

key_buffer_2.key_buffer_size=1G

Para asignar ındices a un buffer:

CACHE INDEX t1, t2 in key_buffer_1;

LOAD INDEX INTO CACHE t1,t2;



Optimizacion



Supervisar rendimiento buffer:% buffer en uso

100-

((key_blocks_unused*key_cache_block_size)*100/key_buffer_size)

% de aciertos:100-((key_reads*100)/key_read_requests)

Fallos por segundo:key_reads/uptime

El % aciertos es el menos significativo porque depende mucho de laaplicacionEl numero de fallos por segundo es el mas significativoEl % buffer en uso permite conocer si hemos reservado demasiadoespacioAunque no se usen tablas MyISAM hay que reservar espacio a lacache porque MySQL las usa para ciertas operaciones



Optimizacion



El tamano de bloque de la cache de claves MyISAM es configurablea partir de MySQL 5.1

Debe ser el mismo tamano que el bloque del SO para ahorrar lecturas

Ejemplo: bloque MyISAM 1 KB, SO 4 KB

MyISAM solicita bloque de claves de 1KB del discoSO recupera 4KB del disco, guarda en cache y entrega bloque de1KB a MyISAMSO libera cache al cargar nuevos datosMyISAM modifica bloque de 1KB y pide al SO que escriba en discoSO vuelve a leer mismos 4KB, modifica bloque 1 KB y graba endisco 4KBSi bloque MyISAM fuese de 4KB: ahorramos la lectura del pasoanterior



Optimizacion


Conjunto de buferes InnoDB

Si usamos tablas InnoDB el conjunto de buferes necesitara masmemoria que cualquier otra opcion

Almacenan ındices, datos de filas, buffer de inserciones, bloqueos,otras estructuras internas

Habitual: reservar 80 % de la memoria fısica de la maquina

Cuando el % de paginas sucias excede el umbral establecido unproceso automatico inicia el volcado a disco

Valor predeterminado del % de paginas sucias es el 90 %

Si subimos el umbral tolera mejor picos de actualizaciones

Si bajamos umbral: tarda menos en cerrarse (se acumulan menospaginas que grabar)

Si el tamano demasiado grande se ralentiza el arranque y la paradadel servidor



Optimizacion


Cache de subprocesos

Pool de procesos libres preparada para conexiones nuevas

Entra conexion: se le asigna proceso de la cacheConexion se cierra: proceso vuelve a estar disponible en la cacheSi no hay sitio: el proceso se destruye

Numero maximo de subprocesos en cache: thread_cache_size

Monitorizacion:

Intentar mantener threads_created entre 1-10 por segundoRevisar threads_connected para configurar el tamano de la cachede forma que sea capaz de contener la fluctuacion tıpica de la cargade trabajo



Optimizacion


Cache de tablas MyISAM

Guarda objetos que representan tablas

Necesita poca memoria, ayuda a conservar recursos

Dos partes:Cache de definicion de tablas (table_definition_cache)

Contenido del archivo .frm analizado sintacticamenteA poder ser, fijar tamano para que quepan todas las definiciones denuestras tablas

Cache de tablas abiertas (table_open_cache)

Descriptores de archivos (datos, ındices)

Si un proceso necesita acceso a una tabla puede obtener descriptordesde la cache

Si la variable opened_tables demasiado grande, o estaincrementando: aumentar cache

Aumentar numero de archivos que pueden permanecer abiertos:open_files_limit



Optimizacion


Ajuste E/S: MyISAM

Cada escritura en cache de claves (ındices), por defecto, se grabainmediatamente a disco

Es posible retrasar escrituras para realizarlas por lotes (variabledelay_key_write)

OFF: bloques se graban inmediatamente a disco (en cuando tablaquede desbloqueada)ON: se retrasan escrituras hasta cierre de tabla (si es una tablamarcada con DELAY KEY WRITE)ALL: todas las tablas tienen escritura retardada

Problemas:

Si servidor se detiene y los bloques no se han volcado, ındice quedadanadoSi se retrasan muchas escrituras, las tablas tardan mas en cerrarseDemasiados bloques sucios en cache: no dejan espacio para nuevos:consultas pueden retrasarse



Optimizacion


Ajuste E/S de InnoDB: Registro de transacciones

Para ahorrar E/S aleatorias en paginas de datos se grabasecuencialmente las ops. en el registro (de transacciones

Transacciones persistentes aun sin haber volcado datos a disco

Proceso de vaciado en segundo plano convierte registro de tx en opsde volcado de datos secuenciales mas eficientes

Tamano del archivo de log: vital para rendimiento de la escritura

Dividido en varios archivos. Registro circular unico.

Tamano total: suma del tamano de los archivos

Predeterminado: dos archivos de 5 MB (10 MB totales)

Lımite superior: 4 GB

Tamano tıpico para alto rendimiento: 256 MB



Optimizacion


Ajuste E/S de InnoDB: Registro de transacciones

Tamano ideal registro, valorar:

Carga actualizaciones rutinarias de datosTiempo de recuperacion requerido en caso de caıda del sistema

Si registro demasiado pequeno: InnoDB realizara mas vaciados

Si registro demasiado grande: mucho trabajo para InnoDB cuando setenga que recuperar

Escaneo del registroExaminar archivos de datosAplicar cambios a los archivos de datos

Supervision del rendimiento:

Anotar valor maximo de variable innodb_os_log_written aintervalos de 10-100 segundosUsarlo para determinar tamano del registro y del buffer del registroMaximo 100 KB/s : buffer de registros de 1 MB lleno en 10 segArchivos de registro de 256 MB: 2.560 segundos de entradas en elregistro



Optimizacion


Ajuste E/S de InnoDB: Buffer del registro de transacciones

Se guarda registro de los cambios en un buffer en memoria

El buffer se vuelca a disco (a los archivos del registro detransacciones):

Cuando buffer de registros se llenaCuando se confirma una transaccionUna vez por segundo

Tamano buffer: por defecto, 1 MB

Rango recomendado: 1-8 MB

Al volcar buffer a archivos de log: se vuelcan estos a almacenamientoduradero

Podemos perder como maximo 1 segundo de transacciones



Optimizacion


Ajuste E/S de InnoDB: Buffer de doble escritura

Para evitar danos con escritura de disco parcial de datos de tablas

Buffer de doble escritura: estructura en cache de tablas InnoDB

Tamano suficiente para contener bloque contiguo de 100 paginas dedisco

Cuando se vuelca grupo de paginas a disco:

Se vuelcan primero a buffer dobleDespues, se vuelcan a disco

Si error en InnoDB, cuando se recupere puede detectar escriturasparciales en disco o en doble buffer



Optimizacion


Concurrencia

InnoDB antes de MySQL 5.1 responde mal a situaciones de altaconcurrencia

Unica solucion: limitar concurrencia(innodb_thread_concurrency)

Formula util (en la practica, puede ser mejor usar valor maspequeno):

concurrencia = num CPUs * num discos * 2

Antes, InnoDB tenıa muchos semaforos MUTEX

Ahora la concurrencia es mucho mejor en InnoDB, pero la mejora dela cache de threads quedo la rama abandonada de MySQL 6.0 y seha recuperado en MariaDB



Optimizacion


Bases de Datos III

Diseno Fısico - MySQL

Enxenarıa Informatica

Curso 2013/2014

Miguel R. LuacesLaboratorio de Bases de Datos

Universidade da Coruna


DesenoFisico MySQL

Documents

Transcript of DesenoFisico MySQL