DesenoFisico MySQL

BD3: Dise
no Fsico - MySQL
Bases de Datos III

Dise
no Fsico - MySQL
Enxenara Informatica
Curso 2013/2014
Miguel R. Luaces
Laboratorio de Bases de Datos
Universidade da Coru
na
Enxe
nara Inform
atica
Miguel R. Luaces (luaces@udc.es) - Juan Ram

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Contenidos
1
2
3
4
Introducci
on a MySQL
Replicaci
on
Copia de seguridad y recuperaci
on
Medici
on de rendimiento y perfilado
Medici
on del rendimiento
Perfilado de aplicaciones
Optimizaci
on
Optimizaci
on de esquemas e ndices
Optimizaci
on de hw. y sw.
Optimizaci
on del servidor
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Introducci
on a MySQL
Contenidos
1
2
3
4
Introducci
on a MySQL
Replicaci
on
on
Medici
Medici
on del rendimiento
Optimizaci
on
Optimizaci
Optimizaci
on de hw. y sw.
Optimizaci
on del servidor
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Introducci
on a MySQL
MySQL Community Server

Versi
on actual: 5.6.17
Documentaci
on: 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)
OLTP
Aplicaciones incrustadas
Data warehouse
Indexado de contenido
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Introducci
on a MySQL
MariaDB
An enhanced, drop-in replacement for MySQL
Versi
on actual: 5.5.36
Documentaci
on: https://kb.askmonty.org/en/
Funciona sobre todas las plataformas: Mac OS X, Windows,
GNU/Linux
Mejoras sobre MySQL 5.5:
M
as motores de almacenamiento (ej.: No-SQL)
Optimizaciones
Extensiones (ej.: virtual columns)
Completamente Open Source
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Introducci
on a MySQL
Arquitectura de MySQL
Clientes
Conexin / Control de subprocesos
Cach de
consultas
Analizador
sintctico
optimizador
API del motor de
almacenamiento
(Iniciar transaccin,
recuperar registro con
clave x)
Motores de almacenamiento
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Introducci
on a MySQL
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 realiza
la optimizaci
on del plan de ejecuci
on
Reescritura de la consulta
Determinaci
on del orden de acceso a las tablas
Selecci
on de los ndices a utilizar
Inclusi
on de las caractersticas especficas de los motores de
almacenamiento
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Introducci
on a MySQL
Caracterstica u
nica: separaci
on de tareas de servidor (conexiones,
procesamiento de consultas, optimizaci
on) de tareas de
almacenamiento y recuperaci
on 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 concurrencia
Gesti
on de transacciones
Motores de almacenamiento
Criterios de selecci
on
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Introducci
on a MySQL
Los bloqueos permiten evitar que un cliente lea un fragmento de
datos 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 que
aumenta la concurrencia
Los bloqueos de tabla minimizan el consumo de memoria por lo que
aumenta el rendimiento
Cada motor de almacenamiento de MySQL define su propia poltica
y granularidad. El servidor no es consciente de los bloqueos.
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Introducci
on a MySQL
MyISAM, Memory y Merge realizan bloqueos a nivel de tabla
Cada motor lo implementa a su modo con optimizaciones para
mejorar el rendimiento
Necesita muy poca memoria
Ideal en el caso de que las lecturas sean mucho m
as frecuentes que
las modificaciones
Es eficiente en el caso de modificaciones simult
aneas en varias filas
InnoDB realiza bloqueos a nivel de fila

Permite la m
axima concurrencia a costa de mayor consumo de
memoria
Ideal en el caso de cambios frecuentes o transacciones largas
Es muy eficiente en el caso de cancelaci
on de transacciones
El servidor de MySQL puede bloquear tablas independiente del motor

para garantizar correcci
on de sentencias DDL como ALTER TABLE
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Introducci
on a MySQL
Gestion de transacciones
MySQL incluye motores transaccionales (InnoDB) y no
transaccionales (MyISAM, Memory)
El estandar SQL define cuatro niveles de aislamiento:
Read uncommited
Read commited
Repeatable read
Serializable
Las figuras de las siguientes diapositivas se extrajeron de aqu:

http://www.byteslounge.com/tutorials/spring-transaction-isolation-tutorial
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Introducci
on a MySQL
Read uncommited
No hay bloqueos, por lo que una transacci
on lee datos sin confirmar
de otra transacci
on
Permite lecturas sucias porque la segunda transacci
on podra ser
cancelada
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Introducci
on a MySQL
Read commited
Los bloqueos de escritura se mantienen hasta el fin de la transacci
on
Los de lectura se liberan al finalizar la lectura
Una transacci
on s
olo lee datos de transacciones confirmadas
Permite lecturas no-repetibles porque los datos podran cambiar
despues de leidos
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Introducci
on a MySQL
Repeatable read
Todos los bloqueos se mantienen durante toda la transacci
on
Cualquier fila que lea una transacci
on ser
a igual en sucesivas lecturas
Como no hay bloqueo de rangos, permite lecturas fantasma
Es la predeterminada en InnoDB
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Introducci
on a MySQL
Serializable
Aislamiento completo de las transacciones usando bloqueos de rango.
InnoDB permite el nivel de aislamiento serializable mediante
Multiversion Concurrency Control (MVCC)
Mantiene instant
aneas de los datos tal y como existan en un
determinado momento
Diferentes transacciones ven simult
aneamente datos distintos en las
mismas tablas
Evita la necesidad de bloquear filas en modo lectura
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Introducci
on a MySQL
Interbloqueos (Deadlocks)
El funcionamiento de los bloqueos es especfico del motor de
almacenamiento
Los interbloqueos son inevitables ya que ocurren por conflictos reales
en las transacciones
Los interbloqueos producen consultas lentas o que sobrepasan tiempo
m
aximo
La soluci
on consiste en reanudar alguna de las transacciones
InnoDB detecta dependencias circulares y reanuda la transacci
on con
los bloqueos de fila menos exclusivos
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Introducci
on a MySQL
Registro de transacciones (Write-ahead logging)
El almacenamiento inmediato de los cambios en los datos es lento
Los cambios realizan en la copia en memoria de la p
agina de disco
El almacenamiento en disco se realiza mediante un registro de
transacciones usando escritura secuencial (y por tanto, r
apida)
Los datos en disco se escriben cuando la p
agina se elimina de
memoria
En 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 las
transacciones
No se pueden combinar de forma fiable motores de almacenamiento
diferentes en una transacci
on
Por ejemplo, los cambios en tablas MyISAM no se pueden deshacer
con un rollback
MySQL no informa del error de ninguna manera
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Introducci
on a MySQL
Motores de almacenamiento: MyISAM

Motor predeterminado para las tablas hasta MySQL 5.1
No soporta transacciones ni claves foraneas, y s
olo permite bloqueos
a nivel de tabla
El tama
no maximo de una tabla es 256 TB
Cada tabla se almacena en un fichero del sistema operativo
Variantes:
Tablas con filas de tama
no fijo (est
aticas) y tama
no variable
(din
amicas)
Tablas comprimidas y de s
olo lectura
El espacio usado en disco es mnimo
Optimo
para soportes de s
olo lectura y/o lentos
Se construyen con la utilidad myisampack
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Introducci
on a MySQL
Motores de almacenamiento: InnoDB

Motor predeterminado para las tablas desde MySQL 5.5
Soporta transacciones, claves foraneasy bloqueos a nivel de fila
El tama
no maximo de una tabla es 64 TB
Las tablas se almacenan en archivos de datos administrados por el
motor y que pueden utilizar particiones raw
Indices agrupados (clustered indexes)
Se crea un ndice para la clave principal de la tabla que se almacena
en las mismas p
aginas que las filas
Las b
usquedas por clave principal son r
apidas porque ahorran un
acceso a disco
Los ndices secundarios (todos los dem
as) siempre incluyen los
atributos de la clave principal para usar el ndice agrupado en las
b
usquedas
Inconvenientes:
Tiene problemas de escalabilidad debido al soporte transaccional
Cambios en la estructura de las tablas implican copiar todos los
datos y recrear los ndices
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Introducci
on a MySQL
Motores de almacenamiento: Memory

Tablas que se guardan en la memoria del servidor y que no permiten
la persistencia
No soportan transacciones ni claves foraneas. Los bloqueos son a
nivel de tabla
El tama
no maximo de una tabla depende de la memoria del servidor
Permite un acceso muy rapido a los datos (un orden de magnitud
mas rapido que el motor MyISAM)
El espacio ocupado por una tabla s
olo se devuelve al borrar o recrear
la tabla
Ejemplos de posibles usos:
Tablas de b
usqueda r
apida (i.e. c
odigos postales)
Guardar en cache datos agregados peri
odicamente
Resultados intermedios de procesos
MySQL lo usa para procesar consultas que necesitan tablas
temporales
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Introducci
on a MySQL
Motores de almacenamiento: otros

Motor Merge
Combinaci
on de varias tablas MyISAM en una u
nica tabla virtual
Permite la partici
on de informaci
on en diferentes bloques
Posibles usos: gesti
on de archivos de log, superar la limitaci
on de
tama
no de archivo del SO
Motor Blackhole
No almacena datos. Todas las inserciones se descartan
Mantiene un registro de operaciones realizadas
Posibles usos: auditora, algunas configuraciones de replicaci
on
Motor CSV
Tablas creadas sobre archivos con valores separados por comas
(comma-separated values)
No admite ndices
Posibles usos: intercambio de datos con aplicaciones externas
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Introducci
on a MySQL
Motores de almacenamiento: seleccion

Dado que podemos elegir el motor de almacenamiento para cada
tabla, necesitamos conocer c
omo se va a utilizar cada tabla, como
funciona la aplicaci
on, y su evoluci
on potencial
En funci
on del uso de transacciones:
Si la aplicaci
on requiere transacciones, la u
nica opci
on es InnoDB
Si no requieren transacciones y las consultas son SELECT e INSERT,
MyISAM es buena opci
on
En funci
on de la concurrencia en las operaciones:
Depende de la carga de trabajo esperada
Si s
olo hay inserciones y lecturas: MyISAM
Si queremos una mezcla de operaciones concurrentes sin
interferencia, necesitamos un motor con bloqueo a nivel de fila
(InnoDB)
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Introducci
on a MySQL
Motores de almacenamiento: seleccion

En funci
on de las copias de seguridad:
Algunos motores (InnoDB) no permiten la copia de seguridad con el
SGBD on-line
Si se puede detener el servidor: cualquier motor.
El uso de m
ultiples motores complica el proceso de copia de
seguridad
En funci
on de la necesidad de operaciones especiales:
S
olo InnoDB incluye ndices agrupados y optimizaciones basadas en
ellos
InnoDB s
olo permite b
usquedas de texto completo desde la versi
on
5.6.4
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Introducci
on a MySQL
Motores de almacenamiento: cambios

Metodos para el cambio de motor de almacenamiento de tablas
Mediante la sentencia ALTER TABLE
Realizando una copia de seguridad, y editando el fichero de volcado
Creando una nueva tabla e insertando los datos mediante una
sentencia INSERT INTO
En todos los casos, las opciones especficas del motor de

almacenamiento se pierden
Todos los metodos son lentos pues implican la copia de los datos
El metodo basado en ALTER TABLE implica un bloqueo de
escritura en la tabla
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Introducci
on a MySQL
Motores de almacenamiento: ejemplos

Registro de llamadas de central telef
onica en tiempo real
La velocidad es el requisito principal. MyISAM impone una
sobrecarga baja y permite miles de inserciones por segundo
Si son necesarios informes de resumen, la recopilaci
on de datos
ralentiza las inserciones
Alternativas:
Realizar la recopilaci
on en horas de poca carga
Replicar la base de datos en un segundo servidor esclavo en el que se
har
an las consultas
Particionar el registro de llamadas por mes, semana o da, y crear una
tabla de tipo Merge para las consultas
Servicio de cotizaciones
Si es una herramienta de consumo interno con un n
umero limitado
de usuarios, MyISAM
Si es un servicio web con mucho tr
afico, miles de usuarios y
alimentaci
on de cotizaciones en tiempo real, InnoDB
Una consulta no debe esperar
Miles de usuarios intentando leer mientras simult
aneamente se
actualizan filas requiere bloqueos a nivel de fila
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Introducci
on a MySQL
Motores de almacenamiento: ejemplos

Boletines de anuncios y foros de discusi
on
Cientos de aplicaciones PHP y Perl que dan soporte a este tipo de
sitios Web
No suelen tener en cuenta la eficiencia de la BD
Ejecutan muchas consultas para cada solicitud que sirven
Muchos usan tablas monolticas con mucha actividad pesada de
lectura y escritura
La carga suele ser mediana o peque
na, MyISAM no es imprescindible
InnoDB no es capa de ejecutar r
apidamente esta consulta sin
optimizaciones por parte del usuario
SELECT COUNT(*) FROM TABLE
Aplicaciones distribuidas en DVD / USB

El motor MyISAM trabaja directamente sobre el sistema de ficheros
Utilizando el formato comprimido se optimiza el acceso a disco,
aunque la BD es de s
olo lectura
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Replicaci
on
Contenidos
1
2
3
4
Introducci
on a MySQL
Replicaci
on
on
Medici
Medici
on del rendimiento
Optimizaci
on
Optimizaci
Optimizaci
on de hw. y sw.
Optimizaci
on del servidor
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Replicaci
on
Definicion de replicacion
Consiste en configurar uno o varios servidores como esclavos - o
replicas - de otro servidor
Problema a resolver: mantener los datos de los servidores
sincronizados
Base para construir aplicaciones extensas y de alto rendimiento
Admite diferentes topologas
Muchos esclavos pueden conectarse a un maestro
Un esclavo puede, a su vez, actuar como maestro
Se puede replicar:
todo el servidor
determinadas bases de datos
s
olo algunas tablas
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Replicaci
on
Problemas resueltos por la replicacion

Distribuci
on de datos
No exige un ancho de banda intensivo y funciona con una conexi
on
intermitente
para mantener una copia de los datos en una ubicaci
Util
on
geogr
aficamente distante
Balanceo de carga
Permite distribuir peticiones de datos entre varios servidores
Alta disponibilidad y failover

Los esclavos ayudan a reducir el tiempo de cada del servidor principal
Prueba de actualizaciones de MySQL

Configuramos un servidor esclavo con la nueva versi
on de MySQL, y
la utilizamos para ver que las aplicaciones siguen funcionando
Copias de seguridad
La carga de la copia se realiza sobre el esclavo, no sobre el servidor
original
Un servidor replicado no es una copia de seguridad
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Replicaci
on
Funcionamiento de la replicacion
El maestro registra todos sus cambios como eventos del registro
binario (binary log)
El esclavo copia los eventos del registro binario a su registro de
repetici
on (relay log)
El esclavo repite todos los eventos del registro de repeticion sobre
sus propios datos
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Replicaci
on
El registro binario de mySQL:
Registra todas las operaciones del servidor que modifican datos (o
podran modificarlos, por ejemplo, un DELETE con filtro) con
independencia de los motores de almacenamiento
Esta formado por una secuencia de eventos, cada de uno de ellos
formado por:
La fecha y hora del evento (un timestamp)
Identificador del servidor de origen (evita bucles infinitos)
Byte de desplazamiento del evento siguiente
Id del thread que ejecut
o el evento en el servidor de origen
Tipo de evento (por ejemplo, Query)
Detalles del evento
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Replicaci
on
El registro binario de mySQL permite tres tipos de replicacion:
Basada en sentencias (statement-based replication)
Se registra la instrucci
on que cambia los datos en el maestro
La utilizada por defecto. Sencilla de implementar y compacta.
Estable desde MySQL 3.23
Hay instrucciones que no se pueden replicar (detalles en el manual)
Basada en filas (row-based replication)

Se registran las filas cambiadas y el cambio realizado
Permite la replicaci
on de cualquier instrucci
on
El registro aumenta de tama
no
No es f
acil auditar los cambios realizados
Mixta (mixed-format replication)

MySQL decide en funci
on de la instrucci
on que se ejecuta si se usa
replicaci
on basada en sentencias o en filas
Se usa la replicaci
on basada en sentencias a no ser que la instrucci
on
no sea segura
Ver la descripci
on en el manual
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Replicaci
on
El proceso para configurar la replicaci
on es el siguiente:
Configurar cuentas de replicaci
on en cada servidor
El thread E/S del esclavo hace una conexi
on TCP/IP al maestro
para leer el registro binario. Por lo tanto, necesita una cuenta de
usuario 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 repetici
on
Inidicar al esclavo como conectarse al maestro y desde que punto del
registro binario hay que replicar
Opcionalmente, activar el registro binario y configurar su
actualizaci
on
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Replicaci
on
Es posible replicar s
olo parte de los eventos de un servidor,
utilizando diferentes tipos de filtros
Filtros sobre el registro binario del maestro
Filtros sobre el registro de repetici
on
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Replicaci
on
Topologas de replicacion
Las restricciones en la replicaci
on son las siguientes:
Cada esclavo s
olo puede tener un maestro
Un maestro puede tener muchos esclavos
Un esclavo puede actuar tambien como maestro
Estas restricciones permiten diferentes topologas con diferentes

aplicaciones
Un maestro, m
ultiples esclavos
Maestro-maestro en modo activo-activo
Maestro-maestro en modo activo-pasivo
Anillo
Maestro, maestro de distribuci
on, esclavos
Arbol
o pir
amide
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Replicaci
on
Un maestro, m
ultiples esclavos
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Replicaci
on
Un maestro, m
ultiples esclavos
La topologa mas sencilla y mas com
un
Todas las escrituras se realizan en el maestro, las lecturas se pueden
realizar en cualquier servidor
El n
umero de esclavos esta limitado por la capacidad de
procesamiento 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 un
desastre
Retrasar un esclavo en el tiempo para facilitar la recuperaci
on
Utilizar un esclavo para copia de seguridad, para pruebas o para
desarrollo
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Replicaci
on
Maestro-maestro en modo activo-activo
Cada maestro es a su vez esclavo del otro

Cualquier servidor se puede utilizar para cualquier operacion
Posible uso: oficinas separadas geograficamente, donde cada oficina
necesita su copia local de los datos
Problemas: cambios conflictivos
Actualizaci
on simult
anea de la misma fila en ambos servidores
Inserciones simult
aneas con columnas AUTO INCREMENT
Y si la replicaci
on se detiene por un tiempo? C
omo reenganchamos
despues?
S
olo se recomienda si tenemos datos bien particionados y buen
reparto de privilegios
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Replicaci
on
Maestro-maestro en modo activo-pasivo
Uno de los servidores es un servidor pasivo de s

olo lectura
Permite intercambiar los papeles de forma muy sencilla: las
configuraciones son simetricas
Mantenimiento, optimizaci
on de tablas, actualizaciones del sistema
operativo no implican inactividad del sistema.
Por ejemplo, ALTER TABLE bloquea toda la tabla, incluyendo
lecturas y escrituras sobre la misma. Para no ralentizar el sistema:
Detenemos los hilos esclavos en el maestro activo
Hacemos el cambio en el maestro pasivo
Cambiamos los papeles de activo y pasivo
Reiniciamos los hilos esclavos en el antiguo maestro activo
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Replicaci
on
Anillo
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Replicaci
on
Anillo
Tres o mas maestros
Cada servidor es un esclavo del servidor que esta antes en el anillo, y
maestro del servidor que esta despues
Configuraci
on simetrica, failover facil.
Es una configuraci
on fragil:
Depende enormemente de que todos los nodos funcionen
correctamente
Difcil que esten todos sincronizados a la vez: detener alg
un nodo es
complicado
Si eliminamos un nodo sin tener cuidado, sus eventos pueden
propagarse de forma infinita por el anillo. El u
nico nodo que filtra un
evento es el que lo ha generado!
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Replicaci
on
on, esclavos
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Replicaci
on
on, esclavos
Similar a la topologa maestro-esclavos, pero no sobrecarga al
maestro principal
El maestro principal s
olo tiene un esclavo que a su vez act
ua como
maestro de distribuci
on
El maestro de distribuci
on usa el motor BlackHole que graba en el
registro binario pero no mantiene tablas ni datos
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Replicaci
on
Arbol
o pir
amide
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Replicaci
on
Arbol
o pir
amide
Si hay muchos esclavos, puede ser mas rentable un dise
no en
piramide
Esto alivia la carga del maestro y la redistribuye por los diferentes
esclavos
Desventaja: fallos en niveles intermedios afectan a un gran n
umero
de servidores
Ademas, cuantos mas niveles intermedios, mas difcil y complicado
es manejar los fallos
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Replicaci
on
Problemas en la replicacion
La replicaci
on implica varias tareas complejas:
Medir el desfase de los esclavos para saber en que estado se
encuentran
Determinar la consistencia de los esclavos con respecto al maestro
Resincronizar un esclavo con el maestro
Intercambiar un esclavo por un maestro
La replicaci
on s
olo escala las lecturas, no las escrituras
La distribuci
on de la carga debe ser realizada por otro software
La complejidad de la replicaci
on se ve claramente en la longitud de
la secci
on del manual
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
on
Contenidos
1
2
3
4
Introducci
on a MySQL
Replicaci
on
on
Medici
Medici
on del rendimiento
Optimizaci
on
Optimizaci
Optimizaci
on de hw. y sw.
Optimizaci
on del servidor
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
on
Introduccion
Recuperaci
on no es restauraci
on
Restaurar: recuperar datos desde una copia de seguridad y cargarlos
en una base de datos
Recuperar: todo el proceso de rescatar un sistema o parte de el.
Incluye todos los pasos para lograr que un servidor vuelva a ser
completamente funcional y operativo:
Restaurar copia de seguridad
Reiniciar servidor
Cambiar configuraci
on
Calentar las cach
es del servidor
Utilidades de las copias de seguridad

Recuperaci
on ante desastres. Un error importante corrompe los datos
o el servidor
Recuperaci
on ante cambios no deseados. La gente cambia de idea, y
ocurre m
as a menudo que los desastres
Auditoras. Necesidad de recuperar datos o esquema en alg
un
momento del pasado (ej. temas judiciales)
Pruebas. La manera m
as f
acil de cargar un servidor de pruebas con
datos es usando una copia de seguridad
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
on
Introduccion
El mejor sistema de copias de seguridad no es suficiente. Un buen
plan de recuperaci
on es fundamental
El procedimiento de recuperaci
on es complejo. Es f
acil cometer
errores
Las copias de seguridad son rutinarias y no se realizan bajo
situaciones de presi
on extrema. La recuperaci
on se hace en medio de
una situaci
on de crisis
Una persona puede planear, dise
nar e implementar las copias de
seguridad, pero podra no estar disponible cuando se produzca el
desastre. Es necesario formar a personal cualificado para que se
encargue de la recuperaci
on
Alternativas que no son copias de seguridad

La replicaci
on no es una copia de seguridad
Usar discos en RAID
C
omo nos recuperamos en estos casos de un DROP DATABASE?
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
on
Estrategia para la copia de seguridad

No olvidar realizar copias de seguridad de recursos no obvios
Registro binario y registro de transacciones de InnoDB
C
odigo: disparadores y procedimientos almacenados (est
an en la BD
mysql)
Configuraci
on del servidor y de la replicaci
on
Ficheros seleccionados del SO (trabajos cron, configuraciones de
usuario y de grupo, scripts administrativos, reglas sud0, etc)
Que podemos permitirnos perder?

La respuesta a esa pregunta gua la estrategia de copia de seguridad
Basta con la copia de la noche anterior y podemos perder el trabajo
de hoy?
Necesitamos retroceder a un instante de tiempo predeterminado?
Cuanto m
as nos permitamos perder, m
as f
acil es hacer la copia
Las copias de seguridad en MySQL son mucho m
as complicadas de
lo que parece
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
on
Tipos de copia de seguridad

Copias calientes, templadas o fras?
Calientes: sin detener el servidor ni bloquear las tablas
Templadas: sin detener el servidor pero bloqueando las tablas
Fras: deteniendo el servidor
Copias l
ogicas o sin procesar?
Copia l
ogica: en un formato que MySQL puede interpretar (SQL,
CSV)
Copia sin procesar: los archivos de mySQL tal y como est
an
almacenados en disco
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
on

Inconvenientes de copias calientes
B
uferes sucios en el grupo de buffers de InnoDB (u otras caches)
Datos modificados mientras se est
a haciendo la copia
Inconvenientes de copias frias

Desconectar servidor es costoso, aun si se minimiza el tiempo de
copia de seguridad
Las p
aginas sucias en grupo de buffers InnoDB requieren tiempo para
volcarse a disco
Reiniciar tambien requiere tiempo: abrir tablas, calentar caches, etc.
Inconvenientes de copias templadas

Tiempo de espera indeterminado debido al proceso de adquirir
bloqueos
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
on

Ventajas de las copias l
ogicas
Archivos que se pueden manipular e inspeccionar con editores de
textos
F
aciles de restaurar
Se pueden restaurar en una m
aquina diferente
Independientes del motor de almacenamiento
Se pueden retocar para exportar a otros SGBD
Desventajas de las copias l

ogicas
El servidor debe hacer el trabajo de generarlas
Pueden llegar a ocupar mucho m
as que los datos en algunos casos
La reconstrucci
on implica volver a ejecutar todas las sentencias y
regenerar todos los ndices.
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
on

Ventajas de las copias sin procesar
No hay trabajo adicional: se copian los archivos tal cual
La restauraci
on puede ser sencillsima: para MyISAM, simplemente
copiar los archivos en su sitio; InnoDB, en cambio, obliga a detener
el servidor
La restauraci
on es m
as r
apida: no hay que ejecutar sentencias, ni
reconstruir ndices
Desventajas de las copias sin procesar

Suelen ocupar mucho m
as espacio que las copias l
ogicas (por
ejemplo, el espacio de tabla InnoDB incluye mucho espacio sin
utilizar)
No siempre se pueden mover a traves de las plataformas, SO y
versiones de SQL (may
usculas/min
usculas, representaci
on punto
flotante)
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
on
Procedimiento de copia logica

Copia
Realizar un volcado SQL con mysqldump o CSV con SELECT *
INTO OUTFILE
Restauraci
on
Ejecutar el script SQL o importar el CSV con LOAD DATA INFILE
INTO TABLE
Problemas:
En el volcado SQL los esquemas y datos almacenados juntos, en el
volcado CSV no hay esquemas
Los archivos pueden ser enormes (y los editores de texto no podr
an
abrirlos)
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
on
Procedimiento de copia logica

Hay que asegurar que los datos son consistentes en un punto de
tiempo determinado (por ejemplo, en una BD de comercio
electr
onico debe haber una factura por cada pago). Es complicado
en copias calientes
En motores transaccionales: realizar la copia en una transacci
on
En motores no transaccionales, bloquear todas las tablas que se
deben copiar juntas
Esto no nos protege de una aplicaci
on mal dise
nada (por ejemplo, si
el pago y la factura se registran en dos transacciones distintas)
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
on
Procedimiento de copia sin procesar

Copia
MyISAM: bloquear las tablas y copiar los archivos de datos
InnoDB:
Bloquear las tablas no es suficiente porque los cambios se reflejan en
el registro de transacciones y no en el espacio de tablas
Alternativa: parar el servidor o usar t
ecnicas de gesti
on de ficheros del
SO (por ejemplo, LVM)
Restauraci
on:
MyISAM: bloquear las tablas y copiar los archivos de datos
InnoDB: parar el servidor y sustituir los archivos
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
on
Procedimiento de copias de seguridad incrementales

Activar el registro binario de mySQL
Copia:
Realizar copias completas con los procedimientos anteriores
Realizar copias incrementales del registro binario
Restauraci
on:
Restaurar la copia completa y ejecutar todos los registro binarios
Restauraci
on a un punto concreto del tiempo
Localizar el punto de tiempo en los registros binarios y ejecutar hasta
esa posici
on
Eliminar el resultado de una instrucci

on
Localizar la instrucci
on y ejecutar el registro binario hasta esa
posici
on y desde despues de esa posici
on
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Medici
Contenidos
1
2
3
4
Introducci
on a MySQL
Replicaci
on
on
Medici
Medici
on del rendimiento
Optimizaci
on
Optimizaci
Optimizaci
on de hw. y sw.
Optimizaci
on del servidor
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Medici
Medicion del rendimiento y perfilado

El objetivo de la optimizaci
on es aumentar el rendimiento de MySQL
Los elementos a optimizar son muchos. Ej: esquemas, ndices,
consultas, configuraci
on del servidor, hardware, software, aplicaciones
Necesitamos dos practicas basicas:
Medici
on del rendimiento. Responde a C
omo se ejecuta?
Permiten evaluar el desempe
no del SGBD
Permiten determinar la capacidad m
axima del sistema
Permiten discriminar los cambios que importan de los que no
Muestran c
omo se ejecuta la aplicaci
on con datos diferentes
Perfilado. Responde a Por que se ejecuta as?

Indica cuanto contribuye cada elemento de un sistema al coste de
producir el resultado
Lugares donde se pierde m
as tiempo
Lugares donde se consumen m
as recursos
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Medici
Medici
on del rendimiento
Contenidos
1
Introducci
on a MySQL
Replicaci
on

on
Medici
Medici
on del rendimiento
Optimizaci
on
Optimizaci
Optimizaci
on de hw. y sw.
Optimizaci
on del servidor
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Medici
Medici
on del rendimiento
Objetivos de las medidas

Las medidas de rendimiento permiten realizar las siguientes tareas:
Medir rendimiento actual de nuestra aplicaci
on
Necesario para poder comparar efecto de cambios
Diagnosticar 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 futura
prevista
Probar la capacidad de adaptaci

on a entornos cambiantes
Picos espor
adicos, configuraciones diferentes de servidores
Probar configuraciones diferentes de hw., sw. y so.

RAID5 o RAID10? n
ucleo 2.4 o 2.6 de Linux? escala bien con
doble de memoria?
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Medici
Medici
on del rendimiento
Estrategias para medir

Existen dos estrategias en la medida de rendimiento:
Aplicaci
on como un todo
La preocupaci
on u
ltima es el rendimiento de toda la aplicaci
on
MySQL no es siempre el cuello de botella. Una prueba de pila
completa pude revelarlo
Los puntos de referencia para medir rendimiento son buenos si
reflejan el comportamiento real de toda la aplicaci
on. Es m
as difcil si
s
olo probamos una parte de ella
Aislar mySQL (SGBD, en general)

Es difcil aislar puntos de referencia y de configuraci
on de la
aplicaci
on
Acercamiento paulatino: empezar por mySQL
Interesan medidas de rendimiento cortas, con tiempo de ciclo m
as
corto
F
acil aislar consultas tpicas y repetirlas muchas veces
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Medici
Medici
on del rendimiento
Ejemplos de medidas de rendimiento

Transacciones por unidad de tiempo (clasica)
Se ajusta bien a aplicaciones interactivas de m
ultiples usuarios, OLTP
Unidad tpica: transacciones por segundo
Tiempo de respuesta (latencia)

Mide tiempo total requerido por una tarea (ej: milesimas, minutos)
La ejecuci
on repetida permite derivar tiempos de respuesta mnimo,
m
aximo o medio
Los tiempos mnimos y m
aximos no son muy u
tiles porque no son
repetibles, cuanto m
as tiempo se ejecute la medida, m
as extremos
ser
an, y varan mucho entre diferentes ejecuciones
En general es mejor agregar utilizando percentiles (ej: el 95 % de las
respuestas se responden en menos de 5 ms)
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Medici
Medici
on del rendimiento
Ejemplos de medidas de rendimiento

Concurrencia
Medimos el rendimiento de la aplicaci
on bajo diferentes niveles de
concurrencia
Un ejemplo de medida: n
umero solicitudes atendidas respecto a las
solicitadas en un segundo
Es importante mediar las consultas que se realizan, no las conexiones
establecidas, ya que los servidores y los clientes actuales incluyen un pool
de conexiones
No s
olo es un resultado, tambien es una propiedad que debemos
configurar en nuestras pruebas
Escalabilidad
en sistemas que tienen que mantener un rendimiento estable bajo
Util
carga de trabajo cambiante
Generalmente se utilizan medidas de tiempo de respuesta probando con
diferentes intensidades de carga
La intensidad de carga se varia cambiando (entre otros):
El tama
no de la base datos
El n
umero de conexiones concurrentes
El hw. disponible
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Medici
Medici
on del rendimiento
Errores comunes en las medidas

Algunos errores comunes en la definici
on 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 vnculos uno
tras otro sin parar, en una aplicaci
on web
Ejecutar consultas identicas en un bucle, olvidando posibles perdidas
en cache
No detectar los errores en el proceso de medida (ej: que una
operaci
on lenta se agilice mucho puede ser debido a un error de
sintaxis en SQL)
Olvidar tener en cuenta latencia del servidor despues de reinicio
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Medici
Medici
on del rendimiento
Planificacion de medidas de rendimiento

Proceso de planificaci
on de una medida de rendimiento
Identificar el objetivo de la medida y definir indicadores para
evaluarlo
Un objetivo mal definido: El nuevo ndice agiliza las consultas
Un objetivo bien definido: El nuevo ndice reduce el tiempo de
respuesta de la consulta en un 10 %
Decidir si usaremos una prueba estandar o una prueba de dise

no
propio
Definir un plan de toma de medidas porque tendremos que repetir la
prueba varias veces y necesitamos reproducirla exactamente
Datos de partida de la prueba
Pasos seguidos para configurar sistema
Plan de calentamiento
Documentaci
on de los par
ametros
Almacenamiento de los resultados
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Medici
Medici
on del rendimiento
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 del
sistema
Debemos asegurar que la prueba es significativa y repetible (ej: usando
una instant
anea de los datos, usando el servidor en caliente)
Debemos tener cuidado con la carga externa y con las tareas peri
odicas
Cambiar la menor cantidad de par
ametros posible en cada prueba (los
independientes)
Es recomendable automatizar las ejecuciones de las pruebas (scripts,
makefiles)
El n
umero de repeticiones depende del grado de certeza que se quiera
alcanzar. Com
unmente:
Ejecutar varias veces y eliminar los resultados discrepantes
Ejecutar hasta que los resultados no varen demasiado (reducir la varianza)
Utilizar t
ecnicas estadsticas
Analizar los resultados

Los resultados agregados permiten dar una idea general de la medida
Los resultados detallados permiten detectar picos ocultos por la
agregaci
on
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Medici
Medici
on del rendimiento
Herramientas para medidas de rendimiento

Herramientas especficas de mySQL
mysqlslap
Incluido desde la version 5.1 con mySQL
Simula carga en el servidor e informa sobre el tiempo
Muy configurable, ej: n
umero de conexiones concurrentes
Permite una instrucci
on SQL en lnea de comandos o un archivo con
instrucciones SQL
MySQL Benchmark suite

Incluido desde la version 5.0 con mySQL
Mide lo r
apido que ejecuta el servidor las consultas
Muchas pruebas predefinidas, que permiten comparar diferentes
motores de almacenamiento y configuraciones
Mejorable (un s
olo usuario, el conjunto de datos es peque
no, y usa
un solo proceso (no multiples CPU)
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Medici
Medici
on del rendimiento

Herramientas especficas de mySQL
sysbench
Tests predefinidos para medir rendimiento de servidor y SGBD
Pruebas de rendimiento de CPU, memoria, threads, etc.
Pruebas de rendimiento de la E/S de archivos: comparar discos
duros, tarjetas RAID, modos RAID, etc.
Pruebas de comparaci
on OLTP
Desarrollo parado
Super Smack
Pruebas de comparaci
on + Prueba de estres + Herramienta de
generaci
on de carga para MySQL y PostgreSQL
M
ultiples usuarios, carga datos de prueba (aleatorios)
Lenguaje neutro (smack) para definir clientes, tablas, consultas, etc.
Desarrollo parado
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Medici
Medici
on del rendimiento

Herramientas de pila completa
Ab
Incluida con el servidor HTTP Apache
Calcula el n
umero de solicitudes que puede servir por segundo
S
olo prueba una URL todo lo r
apido que pueda
httpload
Utiliza un archivo de entrada con muchas URLs de las que elige
aleatoriamente
Prueba lo m
as r
apido que pueda, o seg
un una velocidad establecida
(-rate)
Tambien simula usuarios concurrentes (-parallel)
JMeter
Aplicaci
on Java para medir el rendimiento de otros programas
Simula usuarios reales (tiempo de escalada configurable)
Interfaz gr
afica que permite reproducir prueba fuera de lnea
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Medici
Contenidos
1
Introducci
on a MySQL
Replicaci
on

on
Medici
Medici
on del rendimiento
Optimizaci
on
Optimizaci
Optimizaci
on de hw. y sw.
Optimizaci
on del servidor
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Medici
Objetivos del perfilado

El perfilado de un sistema nos indica cuanto contribuye cada
elemento al coste total de producci
on 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 consultas
perdemos mucha informaci
on
Procesamiento de resultados en memoria
Llamadas a recursos externos
Algoritmos poco o
ptimos
Si nos limitamos a medir tiempo de respuesta del servidor web

No tenemos estadsticas del sistema que permitan determinar qu
e
esfuerzo permite una mayor mejora
El cuello de botella puede estar en otra parte.
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Medici
Proceso de perfilado
Es necesario incluir c
odigo de perfilado en las aplicaciones que tome
mediciones de:
Tiempo total de ejecuci
on de la p
agina
Tiempo de ejecuci
on de las consultas
Tiempo de llamadas a recursos externos (servicios web)
Es una sobrecarga al sistema, por lo que es necesario aplicar tacticas

como
S
olo realizar el perfilado en un porcentaje peque
no de las peticiones
Guardar los datos en memoria y hacerlos persistentes en bloque
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Medici
Perfilado en MySQL
MySQL mantiene dos registros de consultas: el registro general y el
registro de consultas lentas
El registro general
Se guardan todas las consultas que se reciben aunque por error no se
terminen ejecutando
Se guardan los eventos de conexi
on y desconexi
on
Sin tiempos de ejecuci
on: de poco interes para el perfilado
El registro de consultas lentas

Registra las consultas ejecutadas que sobrepasan un determinado
tiempo
Se puede configurar para registrar tambien las consultas que no
utilizan ndices
Guarda tiempos de ejecuci
on: permite perfilado
Es difcil de utilizar:
Una consulta es lenta porque tarda m
as de lo esperado, no porque
tarda m
as que un umbral de tiempo
Hay consultas que no tienen que usar el ndice de ning
un modo
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Medici
Perfilado en MySQL
Desde la versi
on 5.1.28, MySQL permite realizar perfilado de los
recursos usados en una sesi
on
Se activa mediante la variable profiling
Se consulta mediante SHOW PROFILES y SHOW PROFILE [FOR
QUERY n]
Registra multitud de variables para cada uno de los estados de todas
las consultas ejecutadas
Los datos se pueden consultar agregados o a nivel de consulta
individual
Los datos se guardan en memoria mientras dure la sesi
on
La estrategia de analisis de resultados puede ser:

Comprobar que consultas tienen m
as impacto
Comprobar el plan de ejecuci
on de esas consultas con EXPLAIN
Realizar los ajustes necesarios
Repetir el an
alisis
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Optimizaci
on
Optimizaci
Contenidos
1
2
3
4
Introducci
on a MySQL
Replicaci
on
on
Medici
Medici
on del rendimiento
Optimizaci
on
Optimizaci
Optimizaci
on de hw. y sw.
Optimizaci
on del servidor
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Optimizaci
on
Optimizaci
Optimizacion de esquemas e ndices

Optimizar esquema mal dise
nado o mal indizado mejora del
rendimiento en
ordenes de magnitud
Sin embargo, hay que tener cuidado con los efectos secundarios
Un nuevo ndice INSERT y UPDATE m
as lentas
Las tablas de resumen y los contadores agilizan consultas, pero el
mantenimiento es m
as costoso
Los cambios requieren conocer todo el sistema y cada elemento
afectado
Describiremos estas tecnicas:

Elecci
on de tipos de datos o
ptimos y selecci
on de clave primaria
Distintos tipos de ndices: B+, Hash y agrupados
Estrategias de indexado
Indices para ordenaci
on
Tablas de cache y de resumen
Tablas de contadores
Desnormalizaci
on
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Optimizaci
on
Optimizaci
Eleccion de tipos de datos optimos

Elegir adecuadamente el tama
no es importante
Usar el tipo de datos mas peque
no 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 de
32 bits sin signo): INET ATON(), INET NTOA()
Evitar valores NULL. Indicar NOT NULL siempre que sea posible
Complicado optimizar si hay columnas con valores NULL
Columnas NULL usan mas espacio de almacenamiento y requieren
procesamiento especial. (i.e. byte adicional en ndice)
A ser posible, usar cero, valor especial, cadena vaca, . . .
Proceso:
Paso 1: Determinar tipo de datos: numerico, cadena, temporal
Paso 2: Elegir tipo especfico
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Optimizaci
on
Optimizaci

DATETIME vs. TIMESTAMP
Datetime: Entero empaquetado (YYYMMDDHHMMSS) de 8 bytes.
Mayor rango de valores (1001-9999, con precisi
on de 1 segundo).
Timestamp: Entero de 4 bytes. N
umero de segundos desde 0:00 del
1/1/1970 en meridiano Greenwich. Mitad de espacio y utiliza zona
horaria.
CHAR vs. VARCHAR

CHAR
Longitud fija
Vale la pena para valores muy cortos o cuando todos los valores
tienen aprox. la misma longitud.
VARCHAR
Menos espacio por ser longitud variable
1 o 2 bytes adicionales para almacenar longitud (varchar(10): hasta
11 bytes; varchar(1000): hasta 1002 bytes)
Filas ocupan menos, pero pueden crecer m
as adelante
(fragmentaci
on, reasignaci
on de espacio)
Vale la pena cuando la longitud m
axima de columna es mucho mayor
que la media y hay pocas actualizaciones, o cuando el cjto. caracteres
complejo, codificaci
on variable (UTF-8).
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Optimizaci
on
Optimizaci

VARCHAR(5) vs. VARCHAR(200)
Un texto de cuatro caracteres ocupa lo mismo en ambos casos, no
hay diferencia en almacenamiento secundario
MySQL asigna fragmentos de tama
no fijo a la memoria
Tabla temporal para ordenaci
on: reservara espacio para el m
aximo
tama
no posible (motor Memory necesita filas de tama
no fijo)
Mejor reservar el tama
no justo
BLOB y TEXT
Guardan grandes cantidades de datos (binarios y de cadena)
Cada motor, diferente gesti
on
Evitar usarlos en el ORDER BY ya que el motor Memory no permite
campos TEXT ni BLOB, as que habra que usar myISAM para la
tabla temporal de ordenaci
on)
Truco (longitud lo bastante corta para que la tabla no sobrepase
tmp table size) ORDER BY SUBSTRING(columna text, longitud)
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Optimizaci
on
Optimizaci

ENUM en lugar de cadenas
Ahorro de espacio
Es soluci
on s
olo para listas fijas de cadenas. Ampliarla: ALTER
TABLE
Adem
as: sobrecarga de conversi
on de valores (por ejemplo, al
concatenar o al comparar)
Usar s
olo si la lista de cadenas no va a cambiar en el futuro
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Optimizaci
on
Optimizaci
Seleccion de clave primaria

Debe ser el mismo tipo en todas las tablas relacionadas ya que tipos
distintos afectan al rendimiento debido a las conversiones
InnoDB no permite claves for
aneas si no hay coincidencia exacta
Conversiones de tipo implcitas pueden provocar errores difciles de
detectar
Elegir tama
no mas peque
no necesario dejando espacio para
crecimiento futuro
Por ejemplo: un entero (4 bytes) para c
odigos de provincias implica
mucho espacio en claves externas
Las cadenas de caracteres son una mala elecci

on porque ocupan
mucho espacio y son mas lentas que los enteros
Las cadenas de caracteres aleatorias (estilo UUID) implican:
ralentizaci
on de los INSERT ya que el valor se inserta en una posici
on
aleatoria del ndice que puede crear fragmentaci
on de p
aginas
mal rendimiento de las caches ya que se elimina la localidad
ralentizaci
on de los SELECT porque filas adyacentes en el resultado
quedan dispersas en disco y memoria si las filas se almacenan
ordenadas por clave
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Optimizaci
on
Optimizaci
Revision de los esquemas generados automaticamente

Proceso tradicional: Modelado conceptual, l
ogico y fsico
Proceso de mapeado objeto-relacional: anotaci
on de clases y
creaci
on de esquemas
Proceso model-driven engineering: modelado conceptual y creacion
automatica de esquemas
Posibles problemas
Uso reiterado de tipos VARCHAR sin lmite
Tipos de datos en columnas de combinaci
on que no coinciden
El objetivo principal es que cualquier clase puede ser almacenada en
cualquier SGBD, lo que puede provocar:
Tablas con cada propiedad de un objeto en una fila
Versiones de cada propiedad usando timestamps
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Optimizaci
on
Optimizaci
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 recuperan
punteros a las filas en la tabla
Si se define el ndice sobre varias columnas el orden en el que se
indican las columnas es muy importante ya que MySQL solo busca
eficientemente 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 (no
en capa de servidor), por lo que no todos los motores admiten todos
los tipos de ndices
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Optimizaci
on
Optimizaci
Arbol
B y B+
Admitido por todos los motores (menos Archive)
Cada motor lo implementa a su modo. Por ejemplo, MyISAM usa
compresi
on mientras que InnoDB no usa compresion
Idea general: todos los valores se almacenan en orden y se accede
mediante un arbol en el que cada hoja esta a la misma distancia de
la raz y las paginas de hojas contienen punteros a los registros de la
tabla.
Agiliza acceso a los datos. Se realiza un acceso al nodo raz y e va
descendiendo por las ramas escogiendo punteros adecuados hasta
llegar al valor correcto.
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Optimizaci
on
Optimizaci
Arbol
B y B+
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Optimizaci
on
Optimizaci
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 m
as a la izquierda
apellidos = Allen and nombre like C %
Coincidencia con rango de valores
apellidos >= Allen % and apellidos <= Barrimore %
Cl
ausulas ORDER BY por los campos del ndice
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Optimizaci
on
Optimizaci
Arbol
B y B+
Limitaciones. No son u
tiles en:
B
usquedas que no empiezan en la parte m
as izquierda de las
columnas 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 primera
condici
on de rango. Por ejemplo:
apellidos = Allen AND nombre >= J AND fnac = 23-12-1976
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Optimizaci
on
Optimizaci
Indices Hash
S
olo soportado por el motor Memory (el indice por defecto)
Para cada fila se crea un c
odigo hash con las columnas indizadas
El ndice es una tabla hash con apuntadores de fila (muy compactos)
Las colisiones de la funci
on hash se almacenan con una lista enlazada
s
Util
olo para b
usquedas que usan todas las columnas del ndice. No
admiten coincidencia parcial de clave
Problemas
No se pueden usar los ndices para ordenar ya que el ndice ordena
por hash, no por el valor original.
No evita leer las filas ya que en el ndice s
olo se almacena un punto
al registro
S
olo permite comparaciones de igualdad (=, IN) pero no consultas
de rangos (>100)
Las colisiones de la funci
on hash ralentizan el acceso y el
mantenimiento
Es posible simular ndice hash con una columna extra, un arbol B+ y

triggers
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Optimizaci
on
Optimizaci
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 ya
que en vez de punteros a registros almacenan valores de clave
primaria
No todos los motores los admiten
InnoDB lo hace implcito con la clave primaria, con un ndice u
nico
sin valores NULL, o con una clave interna oculta
Inconvenientes:
S
olo ahorra E/S si los datos no caben en memoria
La velocidad de inserci
on depende del orden de inserci
on (lo mejor,
en el orden de la clave primaria)
La actualizaci
on es costosa debido a la reubicaci
on de p
aginas
P
aginas m
as sujetas a fragmentaci
on al insertar filas nuevas
Pueden ser m
as lentas para escaneos completos
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Optimizaci
on
Optimizaci
Otros ndices
Indices espaciales (arbol R)
S
olo en motor MyISAM
S
olo para los tipos de datos y operaciones de geometra espacial
(GEOMETRY)
El soporte espacial de MySQL no es muy completo
Indices de texto completo

S
olo en el motor MyISAM
Permite b
usquedas de palabras clave en textos y c
alculo de
relevancias
Soporta conceptos de recuperaci
on de informaci
on (stopwords,
lematizaci
on, b
usqueda booleana)
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Optimizaci
on
Optimizaci
Estrategias de indexado: aislar columnas

Aislar la columna en las consultas para que no forme parte de una
expresi
on 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);
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Optimizaci
on
Optimizaci
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 tama
no id
oneo que mantiene el ndice
altamente selectivo
Selectividad = Valores diferentes indexados / Valores totales
Bastante largo para proporcionar buena selectividad
Bastante corto como para ahorrar espacio
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Optimizaci
on
Optimizaci

Distribuci
on de los valores diferentes
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Optimizaci
on
Optimizaci

Calculo de las selectividades
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Optimizaci
on
Optimizaci

Distribuci
on con prefijo de 3 caracteres
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Optimizaci
on
Optimizaci

Distribuci
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Optimizaci
on
Optimizaci

Distribuci
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Optimizaci
on
Optimizaci
Estrategias de indexado: Indices de cobertura

Inclur en el ndice todas las columnas necesarios para resolver una
consulta
MySQL puede utilizar ndices para recuperar valores de una columna
sin tener que acceder para nada a la fila
Ventajas:
Como las entradas del ndice son m
as peque
nas que el tama
no total
de la fila encajan mejor en memoria y caben en cache de los motores
de almacenamiento
Como los ndices se ordenan por valor los accesos de rango requieren
menos E/S
Se evitan bloqueos porque si no accedemos a la fila, no hace falta
bloquearla
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Optimizaci
on
Optimizaci
Usar ndices para ordenacion

MySQL ordena los resultados usando dos metodos: escaneando un
ndice en orden (rapido) o mediante ordenaci
on de archivos (lento)
El escaneado del ndice s
olo se puede hacer si cubre el where y el
order 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 forma
ascendente)
Se usa en el order by una columna que no est
a en el ndice
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Optimizaci
on
Optimizaci
Tablas de cache y resumen

Crear tablas de resumen o de cache independientes de los datos de
partida
Tablas de resumen: Resultados obtenidos con GROUP BY (datos
plegados)
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 forma
peri
odica
La reconstrucci
on debe hacerse usando tablas sombreadas para
poder seguir usando las tablas resumen antiguas
Cuando tenemos lista la nueva tabla resumen, cambiamos el nombre
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Optimizaci
on
Optimizaci
Tablas de contadores
Se aconseja que las tablas de contadores sean independientes
Resulta en tablas rapidas y peque
nas
Un contador es esencialmente un semaforo que crea problemas de
concurrencia
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;
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Optimizaci
on
Optimizaci
Desnormalizacion
Las actualizaciones normalizadas son mas rapidas que las no
normalizadas
En los datos normalizados no hay redundancia por lo que hay menos
datos que modificar
No tener redundancia implica un menor uso de DISTINCT o
GROUP BY
Las tablas normalizadas son mas peque
nas por lo que encajan mejor
en memoria
Sin embargo, en un esquema normalizado las recuperaciones
implican combinaciones que son costosas
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Optimizaci
on
Optimizaci
on de hw. y sw.
Contenidos
1
2
3
4
Introducci
on a MySQL
Replicaci
on
on
Medici
Medici
on del rendimiento
Optimizaci
on
Optimizaci
Optimizaci
on de hw. y sw.
Optimizaci
on del servidor
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Optimizaci
on
Optimizaci
on de hw. y sw.
Introduccion
El hardware y el software sobre los que se ejecuta SGBD determinan
la eficiencia de MySQL (tama
no de disco, memoria disponible,
recursos de CPU, red . . . )
Se necesitan directrices para resolver cuellos de botella del hardware
y del sistema operativo
Prestaremos atenci
on a los siguientes aspectos
Selecci
on de CPU
Equilibrar recursos de memoria y disco
Elegir discos (RAID, NAS)
Configuraci
on de red
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Optimizaci
on
Optimizaci
on de hw. y sw.
Introduccion
Cuellos de botella comunes:
Saturaci
on de CPU. Com
un cuando MySQL trabaja con datos que
caben en memoria o pueden ser ledos de disco tan r
apido como sea
necesario. Ejemplos: ops. criptogr
aficas intensivas, combinaciones sin
ndices
Saturaci
on E/S. Se trabaja con m
as datos de los que caben en
memoria. Se vaca cache para traer m
as datos, y al rato los datos
vaciados se tienen que volver a cargar
Posibles errores de interpretaci

on:
Escasez de memoria se puede interpretar como falta de capacidad
E/S
Bus de memoria saturado se puede interpretar como problema de la
CPU
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Optimizaci
on
Optimizaci
on de hw. y sw.
Seleccion de la CPU
CPU rapida o muchas CPUs no tan rapidas?
MySQL aprovecha mal el paralelismo ya que asigna una operacion a
una CPU. Problemas de escala con muchas CPU
En funci
on del tipos de rendimiento deseable:
Baja latencia
Tiempo de respuesta r
apido para cada consulta.
Mejor CPUs r
apidas porque cada petici
on s
olo aprovecha una CPU.
Alto rendimiento:
Muchas peticiones simult
aneas.
Mejor muchas CPUs, pero como MySQL escala mal no funciona el
cuantas m
as mejor.
Al final: meter m
as CPUs hasta que deje de compensar y llegados a
ese punto: intentar que sean lo m
as r
apidas posible.
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Optimizaci
on
Optimizaci
on de hw. y sw.
Seleccion de la CPU
Cuando compensan muchas CPUs?
MySQL puede aprovechar CPUs secundarias para tareas en segundo
plano (ops. de red, limpieza de b
uferes InnoDB)
Esas tareas son menores en comparaci
on con la ejecuci
on de
peticiones de los usuarios
Muchas CPUs compensan realmente si:
Muchas conexiones que acceden a tablas diferentes (no compiten por
bloqueos)
Rendimiento total del servidor m
as importante que el tiempo de
respuesta de una petici
on particular
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Optimizaci
on
Optimizaci
on de hw. y sw.
Equilibrar recursos memoria / disco

Disponer de mucha memoria evita E/S del disco
Es necesario encontrar un equilibrio entre el tama
no de memoria y
disco teniendo en cuenta rendimiento y coste
Ejemplo: Lecturas aleatorias o secuenciales
Discos actuales: 200 operaciones E/S por segundo, 200 MB/segundo
de forma secuencial
Memoria actual: 1.300 millones de operaciones E/S por segundo,
10.000 MB/segundo de forma secuencial
Acceso aleatorio: 200 filas/segundo de disco, 100.000 filas/segundo
de memoria
Acceso secuencial: 2 millones de filas/segundo de disco, 10 millones
de filas/segundo de memoria
Resultado: Lecturas aleatorias o secuenciales

Accesos aleatorios: 500 veces m
as r
apidos en memoria que en disco
Accesos secuenciales: 5 veces m
as r
apidos en memoria que en disco
Se ahorra mucho m
as trabajo almacenando lecturas aleatorias en
cache
A
nadir memoria es la soluci
on para solucionar problemas de E/S
Enxe
nara Inform
aticaaleatoria
on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Optimizaci
on
Optimizaci
on de hw. y sw.

Cache de las BDs (ej. grupo de b
uferes InnoDB) funciona mejor que
cache de SO (generalista)
M
as conocimiento sobre los datos que necesita
L
ogica para fines especiales
No necesita llamadas al sistema
Aspectos a tener en cuenta al considerar el tama

no de la cache
Conjunto de trabajo
Datos que la aplicaci
on necesita en la cach
e en memoria
Incluye datos e ndices
Unidad de cache
Unidad de datos m
as peque
na con la que puede trabajar el motor de
almacenamiento
InnoDB: 16KB
Fila 100 Bytes puede necesitar cargar 32 KB en cach
e (datos e ndice)
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Optimizaci
on
Optimizaci
on de hw. y sw.

Perdida de cache: datos no en cache, hay que ir a buscarlos a disco
Forma facil de medirla: por el uso CPU (90 % tiempo CPU, 10 %
E/S -> proporci
on perdida cache buena)
Buscar proporci
on de perdida aceptable
No se arregla simplemente a
nadiendo m
as memoria (ej., deficiencias
por tama
no de unidad de cache)
Ejemplo:
Sistema con 10 GB de memoria con 10 % p
erdida
Si fuese lineal: 11 % m
as de memoria (11,1 GB) nos dara 0 % de
p
erdida
En realidad, bajar a 1 % podra requerir 500 GB de memoria
La escalibilidad la determina el eslab

on m
as debil
Ejemplo:
sistema con 16 GB memoria, 20 GB datos y mucho disco libre que
funciona bien
Algunos componentes pueden estar a m
as del 50 % de su capacidad
m
axima (ej. 80 % de n
umero m
aximo de operaciones de E/S)
Aumentar a 40 GB datos (doble) no se puede soportar aumentando
simplemente la memoria: la velocidad de transferencia del disco
funciona a tope!!
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Optimizaci
on
Optimizaci
on de hw. y sw.
Seleccion de discos
Factores a tener en cuenta:
Capacidad de almacenamiento
No suele ser un problema (tama
no actual de los discos m
as que
suficiente)
Pr
actica est
andar: combinar discos peque
nos y RAID
Ventajoso tener m
as capacidad de la necesaria: aumenta la localidad
de los datos
Velocidad de transferencia: no suele ser un factor que limite las

aplicaciones online
Tiempo de acceso: es el factor determinante para agilizar b
usquedas
aleatorias
Tama
no fsico: discos m
as peque
nos son m
as r
apidos y ocupan
menos (fsicamente)
El aprovechamiento depende del motor. InnoDB escala bien entre 10
y 20 discos
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Optimizaci
on
Optimizaci
on de hw. y sw.
Seleccion de discos
Selecci
on de RAID
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Optimizaci
on
Optimizaci
on de hw. y sw.
Seleccion de discos
M
ultiples vol
umenes D
onde colocamos los archivos?
Archivos de datos e ndice
Archivos de registros transaccionales
Archivos de registros binarios
Archivos de registro general (registros de errores, registro de
peticiones, registro de consultas lentas, . . . )
Archivos y tablas temporales
Por defecto, todos los archivos en un u

nico directorio
InnoDB:
datos e ndices en un u
nico conjunto de archivos
S
olo los archivos de definici
on de tablas van aparte, en el directorio
de cada base de datos
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Optimizaci
on
Optimizaci
on de hw. y sw.
Seleccion de discos
M
ultiples vol
umenes
Usar m
ultiples vol
umenes puede ayudarnos a gestionar E/S pesada
Regla cl
asica: registros transaccionales y archivos de datos en
vol
umenes diferentes
E/S secuencial de tx. no interfiere con E/S aleatoria de datos
En realidad, no es tal ventaja

Escrituras en registro son peque
nas
Cach
es RAID agrupan escrituras: se convierten en muchas menos
escrituras por segundo
No interfieren con E/S de datos
Ventaja real:
En caso de fallo, mucho m
as seguro tenerlos separados
Si se pierden los datos: se pueden recuperar usando el registro
Recuperaci
on point-in-time
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Optimizaci
on
Optimizaci
on de hw. y sw.
Seleccion de discos
Dedicar discos a registros transaccionales depende del coste, no del
rendimiento
Ejemplo:
4 discos duros: 2 para datos, 2 para registros transaccionales
1/2 del disco perdido para datos
1 disco para un trabajo trivial (la cach
e del disco hace todo el trabajo)
10 discos duros: 2 para datos, 2 para registros transaccionales

Proporcionalmente menos caro
Configuraci
on tpica:
SO, swap y registros binarios en RAID 1
Resto: un u
nico volumen en RAID 5 o RAID 10
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Optimizaci
on
Optimizaci
on de hw. y sw.
Configuracion de red
El mayor problema es la latencia
En una aplicaci
on tpica hay muchas transferencias peque
nas y se
suman los retrasos de cada transmisi
on
La causa principal es la perdida de paquetes, 1 % de perdida produce
degradaci
on significativa
Optimizaciones:
Pocas conexiones, peticiones o resultados grandes: aumentar el
tama
no del buffer TCP
Aumenta el n
umero de paquetes que se pueden mandar de una
tacada
Modificable en origen y destino
S
olo conexiones locales: acortar timeout de cierre de conexi
on (por
defecto, un minuto)
Otras: Eliminar latencia resoluci
on DNS: skip name resolve
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Optimizaci
on
Optimizaci
on del servidor
Contenidos
1
2
3
4
Introducci
on a MySQL
Replicaci
on
on
Medici
Medici
on del rendimiento
Optimizaci
on
Optimizaci
Optimizaci
on de hw. y sw.
Optimizaci
on del servidor
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Optimizaci
on
Optimizaci
on del servidor
Introduccion
No existe el archivo de configuraci
on
optimo.
Cada servidor necesita una configuraci
on diferente, dependiendo de:
hardware
tama
no datos,
tipos de consultas
Requisitos del sistema (tiempo de respuesta, duraci
on tx,
consistencia, . . . )
La configuraci
on de MySQL predeterminada esta pensada para no
utilizar muchos recursos.
No da por hecho m
aquina dedicada.
Reserva recursos suficientes para iniciar MySQL y ejecutar consultas
sobre pocos datos
Para definir configuraci

on a medida:
Partir de alguno de los ficheros de configuraci
on de ejemplo.
No esperar muchas mejoras con cada cambio
Inicialmente, cambios que duplican o triplican rendimiento
Despues, mejoras incrementales
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Optimizaci
on
Optimizaci
on del servidor
Introduccion
La configuraci
on permanente MySQL se almacena fichero my.cnf
Se configura mediante la asignaci
on de valores a variables
Es posible ejecutar m
ultiples instancias desde una sola configuracion
con secciones independientes.
Ambitos
de las variables:
Global (se aplican al servidor y a cada conexi
on)
Sesi
on (se aplican a una conexi
on especfica)
Especficas para un objeto
Valores demasiado altos generan problemas (i.e. quedarnos sin

memoria)
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Optimizaci
on
Optimizaci
on del servidor
Introduccion
El proceso debe ser el siguiente:
Preparar y realizar mediciones de prueba antes de empezar a ajustar
servidor
Pruebas que representen carga de trabajo real
Incluir consultas complejas
Definir un sistema de supervisi

on para medir si cambio mejora o
empeora rendimiento
Cambiar una o dos variables, un poco, cada vez, y hacer prueba de
medici
on
Ajustar hasta que todo funciona bastante bien
No insistir a menos que creamos que podemos obtener mejora
significativa (el esfuerzo no compensa)
Los acantilados son tpicos: incrementamos variable un poco y

mejora rendimiento; la incrementamos un poco mas, y el
rendimiento cae en picado
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Optimizaci
on
Optimizaci
on del servidor
Introduccion
No comenzar a ajustar configuraci
on sin un esquema y consultas
estables
Todos los ndices creados
Si modificamos esquema despues de ajustar configuraci
on: volver a
empezar
Describiremos estos aspectos

Ajuste de uso de memoria
Ajustes de caches
Ajustes E/S
Concurrencia
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Optimizaci
on
Optimizaci
on del servidor

Comenzar con el lmite superior de memoria disponible para MySQL
Restar la memoria que necesita SO para ejecutarse bien
Restar la memoria necesaria para cada conexi
on (buffer ordenacion,
tablas temporales)
Usar el resto memoria para las caches de MySQL
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Optimizaci
on
Optimizaci
on del servidor

Lmite superior de memoria
Inicial: memoria fsica del servidor
Kernel Linux limita tama
no m
aximo memoria para un proceso (en
general, par
ametros especficos del SO como el tama
no de pilas . . . )
Libreras (glibc) tambien pueden fijar sus propios lmites
Memoria para el SO
Necesario reservar memoria para que el SO haga su trabajo
Mejor indicador de asignaci
on correcta: poco intercambio de
memoria virtual
Normalmente: 1-2 GB (incluso en m
aquinas con mucha memoria
fsica)
Asignar siempre algo de memoria adicional (para tareas peri
odicas
que consuman mucha memoria, copias de seguridad . . . )
No tener en cuenta memoria para caches (esa la tratamos aparte)
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Optimizaci
on
Optimizaci
on del servidor

Necesidades de memoria por conexi
on
Cada conexi
on, peque
na cantidad de memoria para mantenerse
abierta
Tambien, peque
na cantidad para ejecutar una consulta dada
Necesitamos memoria suficiente para momentos de picos de carga
Difcil de predecir. No es necesario suponer peor caso. Ejemplo:
Configurar para 100 conexiones simult
aneas
Fijamos tama
no m
aximo buffer ordenaci
on (uno por conexi
on) en 256
MB
Peor caso: pico de carga supondra 25 GB (Muy poco probable)
Buena soluci
on: observar servidor con carga de trabajo real y
comprobar cu
anta memoria utiliza
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Optimizaci
on
Optimizaci
on del servidor

Toda la memoria que no se use: dedicada a caches
MySQL necesita mas memoria para caches que para el resto de
elementos
Cache del SO trabaja para MySQL
. . . pero MySQL necesita mucha memoria para s mismo
Caches mas importantes:

Cache de claves MyISAM
Grupo de b
uferes InnoDB
Cache de subprocesos
Existen otras caches, pero no requieren mucha memoria

Mas facil ajustar servidor que usa un u
nico motor de almacenamiento
Mezcla de motores: difcil encontrar equilibrio
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Optimizaci
on
Optimizaci
on del servidor

Para almacenar ndices (no datos, MyISAM lo delega en el sistema
operativo)
Si s
olo usamos MyISAM: dedicar mucha memoria a esta cache
Si se usa tambien InnoDB: ajustar al 25-30 % de la cantidad de
memoria 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;
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Optimizaci
on
Optimizaci
on del servidor

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 la

aplicaci
on
El n
umero de fallos por segundo es el mas significativo
El % buffer en uso permite conocer si hemos reservado demasiado
espacio
Aunque no se usen tablas MyISAM hay que reservar espacio a la
cache porque MySQL las usa para ciertas operaciones
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Optimizaci
on
Optimizaci
on del servidor

El tama
no de bloque de la cache de claves MyISAM es configurable
a partir de MySQL 5.1
Debe ser el mismo tama
no que el bloque del SO para ahorrar lecturas
Ejemplo: bloque MyISAM 1 KB, SO 4 KB
MyISAM solicita bloque de claves de 1KB del disco
SO recupera 4KB del disco, guarda en cache y entrega bloque de
1KB a MyISAM
SO libera cache al cargar nuevos datos
MyISAM modifica bloque de 1KB y pide al SO que escriba en disco
SO vuelve a leer mismos 4KB, modifica bloque 1 KB y graba en
disco 4KB
Si bloque MyISAM fuese de 4KB: ahorramos la lectura del paso
anterior
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Optimizaci
on
Optimizaci
on del servidor
Conjunto de buferes InnoDB

Si usamos tablas InnoDB el conjunto de b
uferes necesitara mas
memoria que cualquier otra opci
on
Almacenan ndices, datos de filas, buffer de inserciones, bloqueos,
otras estructuras internas
Habitual: reservar 80 % de la memoria fsica de la maquina
Cuando el % de paginas sucias excede el umbral establecido un
proceso 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 menos
paginas que grabar)
Si el tama
no demasiado grande se ralentiza el arranque y la parada
del servidor
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Optimizaci
on
Optimizaci
on del servidor
Cache de subprocesos
Pool de procesos libres preparada para conexiones nuevas
Entra conexi
on: se le asigna proceso de la cache
Conexi
on se cierra: proceso vuelve a estar disponible en la cache
Si no hay sitio: el proceso se destruye
N
umero maximo de subprocesos en cache: thread_cache_size
Monitorizaci
on:
Intentar mantener threads_created entre 1-10 por segundo
Revisar threads_connected para configurar el tama
no de la cache
de forma que sea capaz de contener la fluctuaci
on tpica de la carga
de trabajo
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Optimizaci
on
Optimizaci
on del servidor
Cache de tablas MyISAM

Guarda objetos que representan tablas
Necesita poca memoria, ayuda a conservar recursos
Dos partes:
Cache de definici
on de tablas (table_definition_cache)
Contenido del archivo .frm analizado sint
acticamente
A poder ser, fijar tama
no para que quepan todas las definiciones de
nuestras tablas
Cache de tablas abiertas (table_open_cache)

Descriptores de archivos (datos, ndices)
Si un proceso necesita acceso a una tabla puede obtener descriptor

desde la cache
Si la variable opened_tables demasiado grande, o esta
incrementando: aumentar cache
Aumentar n
umero de archivos que pueden permanecer abiertos:
open_files_limit
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Optimizaci
on
Optimizaci
on del servidor
Ajuste E/S: MyISAM

Cada escritura en cache de claves (ndices), por defecto, se graba
inmediatamente a disco
Es posible retrasar escrituras para realizarlas por lotes (variable
delay_key_write)
OFF: bloques se graban inmediatamente a disco (en cuando tabla
quede desbloqueada)
ON: se retrasan escrituras hasta cierre de tabla (si es una tabla
marcada con DELAY KEY WRITE)
ALL: todas las tablas tienen escritura retardada
Problemas:
Si servidor se detiene y los bloques no se han volcado, ndice queda
da
nado
Si se retrasan muchas escrituras, las tablas tardan m
as en cerrarse
Demasiados bloques sucios en cache: no dejan espacio para nuevos:
consultas pueden retrasarse
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Optimizaci
on
Optimizaci
on del servidor
Ajuste E/S de InnoDB: Registro de transacciones

Para ahorrar E/S aleatorias en paginas de datos se graba
secuencialmente las ops. en el registro (de transacciones
Transacciones persistentes a
un sin haber volcado datos a disco
Proceso de vaciado en segundo plano convierte registro de tx en ops
de volcado de datos secuenciales mas eficientes
Tama
no del archivo de log: vital para rendimiento de la escritura
Dividido en varios archivos. Registro circular u
nico.
Tama
no total: suma del tama
no de los archivos
Predeterminado: dos archivos de 5 MB (10 MB totales)
Lmite superior: 4 GB
Tama
no tpico para alto rendimiento: 256 MB
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Optimizaci
on
Optimizaci
on del servidor
Ajuste E/S de InnoDB: Registro de transacciones

Tama
no ideal registro, valorar:
Carga actualizaciones rutinarias de datos
Tiempo de recuperaci
on requerido en caso de cada del sistema
Si registro demasiado peque

no: InnoDB realizara mas vaciados
Si registro demasiado grande: mucho trabajo para InnoDB cuando se
tenga que recuperar
Escaneo del registro
Examinar archivos de datos
Aplicar cambios a los archivos de datos
Supervisi
on del rendimiento:
Anotar valor m
aximo de variable innodb_os_log_written a
intervalos de 10-100 segundos
Usarlo para determinar tama
no del registro y del buffer del registro
M
aximo 100 KB/s : buffer de registros de 1 MB lleno en 10 seg
Archivos de registro de 256 MB: 2.560 segundos de entradas en el
registro
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Optimizaci
on
Optimizaci
on del servidor
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 de
transacciones):
Cuando buffer de registros se llena
Cuando se confirma una transacci
on
Una vez por segundo
Tama
no buffer: por defecto, 1 MB
Rango recomendado: 1-8 MB
Al volcar buffer a archivos de log: se vuelcan estos a almacenamiento
duradero
Podemos perder como maximo 1 segundo de transacciones
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Optimizaci
on
Optimizaci
on del servidor
Ajuste E/S de InnoDB: Buffer de doble escritura

Para evitar da
nos con escritura de disco parcial de datos de tablas
Buffer de doble escritura: estructura en cache de tablas InnoDB
Tama
no suficiente para contener bloque contiguo de 100 paginas de
disco
Cuando se vuelca grupo de paginas a disco:
Se vuelcan primero a buffer doble
Despues, se vuelcan a disco
Si error en InnoDB, cuando se recupere puede detectar escrituras

parciales en disco o en doble buffer
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Optimizaci
on
Optimizaci
on del servidor
Concurrencia
InnoDB antes de MySQL 5.1 responde mal a situaciones de alta
concurrencia
Unica
soluci
on: limitar concurrencia
(innodb_thread_concurrency)
Formula u
til (en la practica, puede ser mejor usar valor mas
peque
no):
concurrencia = num CPUs * num discos * 2
Antes, InnoDB tena muchos semaforos MUTEX
Ahora la concurrencia es mucho mejor en InnoDB, pero la mejora de
la cache de threads qued
o la rama abandonada de MySQL 6.0 y se
ha recuperado en MariaDB
Enxe
nara Inform
atica

on L
opez Rodrguez
BD3: Dise
no Fsico - MySQL
Optimizaci
on
Optimizaci
on del servidor
Bases de Datos III

Dise
no Fsico - MySQL
Enxenara Informatica
Curso 2013/2014
Miguel R. Luaces
Laboratorio de Bases de Datos
Universidade da Coru
na
Enxe
nara Inform
atica

on L
opez Rodrguez

DesenoFisico MySQL

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

DesenoFisico MySQL

Transféré par

Droits d'auteur :

Formats disponibles

BD3: Dise

Bases de Datos III

Miguel R. Luaces (luaces@udc.es) - Juan Ram

Miguel R. Luaces (luaces@udc.es) - Juan Ram

Miguel R. Luaces (luaces@udc.es) - Juan Ram

MySQL Community Server

Miguel R. Luaces (luaces@udc.es) - Juan Ram

Miguel R. Luaces (luaces@udc.es) - Juan Ram

Conexin / Control de subprocesos

Miguel R. Luaces (luaces@udc.es) - Juan Ram

Miguel R. Luaces (luaces@udc.es) - Juan Ram

Miguel R. Luaces (luaces@udc.es) - Juan Ram

Miguel R. Luaces (luaces@udc.es) - Juan Ram

InnoDB realiza bloqueos a nivel de fila

El servidor de MySQL puede bloquear tablas independiente del motor

Miguel R. Luaces (luaces@udc.es) - Juan Ram

Las figuras de las siguientes diapositivas se extrajeron de aqu:

Miguel R. Luaces (luaces@udc.es) - Juan Ram

Miguel R. Luaces (luaces@udc.es) - Juan Ram

Miguel R. Luaces (luaces@udc.es) - Juan Ram

Miguel R. Luaces (luaces@udc.es) - Juan Ram

Miguel R. Luaces (luaces@udc.es) - Juan Ram

Miguel R. Luaces (luaces@udc.es) - Juan Ram

Uso de varios motores de almacenamiento en transacciones

Miguel R. Luaces (luaces@udc.es) - Juan Ram

Motores de almacenamiento: MyISAM

Miguel R. Luaces (luaces@udc.es) - Juan Ram

Motores de almacenamiento: InnoDB

Miguel R. Luaces (luaces@udc.es) - Juan Ram

Motores de almacenamiento: Memory

Miguel R. Luaces (luaces@udc.es) - Juan Ram

Motores de almacenamiento: otros

Miguel R. Luaces (luaces@udc.es) - Juan Ram

Motores de almacenamiento: seleccion

Miguel R. Luaces (luaces@udc.es) - Juan Ram

Motores de almacenamiento: seleccion

Miguel R. Luaces (luaces@udc.es) - Juan Ram

Motores de almacenamiento: cambios

En todos los casos, las opciones especficas del motor de

Miguel R. Luaces (luaces@udc.es) - Juan Ram

Motores de almacenamiento: ejemplos

Miguel R. Luaces (luaces@udc.es) - Juan Ram

Motores de almacenamiento: ejemplos

Aplicaciones distribuidas en DVD / USB

Miguel R. Luaces (luaces@udc.es) - Juan Ram

Miguel R. Luaces (luaces@udc.es) - Juan Ram

Miguel R. Luaces (luaces@udc.es) - Juan Ram

Problemas resueltos por la replicacion

Alta disponibilidad y failover

Prueba de actualizaciones de MySQL

Miguel R. Luaces (luaces@udc.es) - Juan Ram

Miguel R. Luaces (luaces@udc.es) - Juan Ram

Miguel R. Luaces (luaces@udc.es) - Juan Ram

Basada en filas (row-based replication)

Mixta (mixed-format replication)

Miguel R. Luaces (luaces@udc.es) - Juan Ram

Miguel R. Luaces (luaces@udc.es) - Juan Ram

Miguel R. Luaces (luaces@udc.es) - Juan Ram

Estas restricciones permiten diferentes topologas con diferentes

Miguel R. Luaces (luaces@udc.es) - Juan Ram

Miguel R. Luaces (luaces@udc.es) - Juan Ram

Miguel R. Luaces (luaces@udc.es) - Juan Ram

Cada maestro es a su vez esclavo del otro

Miguel R. Luaces (luaces@udc.es) - Juan Ram