Bases de Datos III. Curso 2013/2014

Transcripción

1 Bases de Datos III Diseño Físico - MySQL Curso 2013/2014 Miguel R. Luaces Laboratorio de Bases de Datos Universidade da Coruña

2 Contenidos 1 Introducción a MySQL 2 Replicación 3 Copia de seguridad y recuperación 4 Medición de rendimiento y perfilado Medición del rendimiento Perfilado de aplicaciones 5 Optimización Optimización de esquemas e índices Optimización de hw. y sw. Optimización del servidor

3 Introducción a MySQL Contenidos 1 Introducción a MySQL 2 Replicación 3 Copia de seguridad y recuperación 4 Medición de rendimiento y perfilado Medición del rendimiento Perfilado de aplicaciones 5 Optimización Optimización de esquemas e índices Optimización de hw. y sw. Optimización del servidor

4 Introducción a MySQL MySQL Community Server Versión actual: Documentación: 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

5 Introducción a MySQL MariaDB An enhanced, drop-in replacement for MySQL Versión actual: Documentación: Funciona sobre todas las plataformas: Mac OS X, Windows, GNU/Linux Mejoras sobre MySQL 5.5: Más motores de almacenamiento (ej.: No-SQL) Optimizaciones Extensiones (ej.: virtual columns) Completamente Open Source

6 Introducción a MySQL Arquitectura de MySQL Clientes Conexión / Control de subprocesos Caché de consultas Analizador sintáctico optimizador API del motor de almacenamiento ( Iniciar transacción, recuperar registro con clave x ) Motores de almacenamiento

7 Introducción a MySQL Arquitectura de MySQL Cada consulta es atendida por un thread del pool servidor La caché consultas almacena sentencias select junto con su resultado Si la consulta no está en caché, tras el análisis sintáctico, se realiza la optimización del plan de ejecución Reescritura de la consulta Determinación del orden de acceso a las tablas Selección de los índices a utilizar Inclusión de las características específicas de los motores de almacenamiento

8 Introducción a MySQL Arquitectura de MySQL Característica única: separación de tareas de servidor (conexiones, procesamiento de consultas, optimización) de tareas de almacenamiento y recuperación de datos Se puede elegir el motor de almacenamiento a nivel de tabla Se pueden cargar motores de almacenamiento en tiempo de ejecución Describiremos brevemente los siguientes aspectos de MySQL: Control de concurrencia Gestión de transacciones Motores de almacenamiento Criterios de selección

9 Introducción a MySQL Control de concurrencia Los bloqueos permiten evitar que un cliente lea un fragmento de datos mientras otro lo está cambiando Hay dos tipos de bloqueos: compartidos (lectura) y exclusivos (escritura) Los SGBD permiten distintas granularidades a los bloqueos (tabla, página 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 poĺıtica y granularidad. El servidor no es consciente de los bloqueos.

10 Introducción a MySQL Control de concurrencia 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ás frecuentes que las modificaciones Es eficiente en el caso de modificaciones simultáneas en varias filas InnoDB realiza bloqueos a nivel de fila Permite la máxima 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ón de transacciones El servidor de MySQL puede bloquear tablas independiente del motor para garantizar corrección de sentencias DDL como ALTER TABLE

11 Introducción a MySQL Gestión de transacciones MySQL incluye motores transaccionales (InnoDB) y no transaccionales (MyISAM, Memory) El estándar SQL define cuatro niveles de aislamiento: Read uncommited Read commited Repeatable read Serializable Las figuras de las siguientes diapositivas se extrajeron de aquí:

12 Introducción a MySQL Gestión de transacciones Read uncommited No hay bloqueos, por lo que una transacción lee datos sin confirmar de otra transacción Permite lecturas sucias porque la segunda transacción podría ser cancelada

13 Introducción a MySQL Gestión de transacciones Read commited Los bloqueos de escritura se mantienen hasta el fin de la transacción Los de lectura se liberan al finalizar la lectura Una transacción sólo lee datos de transacciones confirmadas Permite lecturas no-repetibles porque los datos podrían cambiar después de leidos

14 Introducción a MySQL Gestión de transacciones Repeatable read Todos los bloqueos se mantienen durante toda la transacción Cualquier fila que lea una transacción será igual en sucesivas lecturas Como no hay bloqueo de rangos, permite lecturas fantasma Es la predeterminada en InnoDB

15 Introducción a MySQL Gestión de transacciones Serializable Aislamiento completo de las transacciones usando bloqueos de rango. InnoDB permite el nivel de aislamiento serializable mediante Multiversion Concurrency Control (MVCC) Mantiene instantáneas de los datos tal y como existían en un determinado momento Diferentes transacciones ven simultáneamente datos distintos en las mismas tablas Evita la necesidad de bloquear filas en modo lectura

16 Introducción a MySQL Gestión de transacciones Interbloqueos (Deadlocks) El funcionamiento de los bloqueos es específico 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áximo La solución consiste en reanudar alguna de las transacciones InnoDB detecta dependencias circulares y reanuda la transacción con los bloqueos de fila menos exclusivos

17 Introducción a MySQL Gestión de transacciones 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ágina de disco El almacenamiento en disco se realiza mediante un registro de transacciones usando escritura secuencial (y por tanto, rápida) Los datos en disco se escriben cuando la página 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ón Por ejemplo, los cambios en tablas MyISAM no se pueden deshacer con un rollback MySQL no informa del error de ninguna manera

18 Introducción a MySQL Motores de almacenamiento: MyISAM Motor predeterminado para las tablas hasta MySQL 5.1 No soporta transacciones ni claves foráneas, y sólo permite bloqueos a nivel de tabla El tamaño máximo de una tabla es 256 TB Cada tabla se almacena en un fichero del sistema operativo Variantes: Tablas con filas de tamaño fijo (estáticas) y tamaño variable (dinámicas) Tablas comprimidas y de sólo lectura El espacio usado en disco es mínimo Óptimo para soportes de sólo lectura y/o lentos Se construyen con la utilidad myisampack

19 Introducción a MySQL Motores de almacenamiento: InnoDB Motor predeterminado para las tablas desde MySQL 5.5 Soporta transacciones, claves foráneasy bloqueos a nivel de fila El tamaño máximo de una tabla es 64 TB Las tablas se almacenan en archivos de datos administrados por el motor y que pueden utilizar particiones raw Índices agrupados (clustered indexes) Se crea un índice para la clave principal de la tabla que se almacena en las mismas páginas que las filas Las búsquedas por clave principal son rápidas porque ahorran un acceso a disco Los índices secundarios (todos los demás) siempre incluyen los atributos de la clave principal para usar el índice agrupado en las búsquedas 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

20 Introducción 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 foráneas. Los bloqueos son a nivel de tabla El tamaño máximo de una tabla depende de la memoria del servidor Permite un acceso muy rápido a los datos (un orden de magnitud más rápido que el motor MyISAM) El espacio ocupado por una tabla sólo se devuelve al borrar o recrear la tabla Ejemplos de posibles usos: Tablas de búsqueda rápida (i.e. códigos postales) Guardar en caché datos agregados periódicamente Resultados intermedios de procesos MySQL lo usa para procesar consultas que necesitan tablas temporales

21 Introducción a MySQL Motores de almacenamiento: otros Motor Merge Combinación de varias tablas MyISAM en una única tabla virtual Permite la partición de información en diferentes bloques Posibles usos: gestión de archivos de log, superar la limitación de tamaño de archivo del SO Motor Blackhole No almacena datos. Todas las inserciones se descartan Mantiene un registro de operaciones realizadas Posibles usos: auditoría, algunas configuraciones de replicación 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

22 Introducción a MySQL Motores de almacenamiento: selección Dado que podemos elegir el motor de almacenamiento para cada tabla, necesitamos conocer cómo se va a utilizar cada tabla, cómo funciona la aplicación, y su evolución potencial En función del uso de transacciones: Si la aplicación requiere transacciones, la única opción es InnoDB Si no requieren transacciones y las consultas son SELECT e INSERT, MyISAM es buena opción En función de la concurrencia en las operaciones: Depende de la carga de trabajo esperada Si sólo hay inserciones y lecturas: MyISAM Si queremos una mezcla de operaciones concurrentes sin interferencia, necesitamos un motor con bloqueo a nivel de fila (InnoDB)

23 Introducción a MySQL Motores de almacenamiento: selección En función 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últiples motores complica el proceso de copia de seguridad En función de la necesidad de operaciones especiales: Sólo InnoDB incluye índices agrupados y optimizaciones basadas en ellos InnoDB sólo permite búsquedas de texto completo desde la versión 5.6.4

24 Introducción a MySQL Motores de almacenamiento: cambios Métodos 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 específicas del motor de almacenamiento se pierden Todos los métodos son lentos pues implican la copia de los datos El método basado en ALTER TABLE implica un bloqueo de escritura en la tabla

25 Introducción a MySQL Motores de almacenamiento: ejemplos Registro de llamadas de central telefónica 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ón de datos ralentiza las inserciones Alternativas: Realizar la recopilación en horas de poca carga Replicar la base de datos en un segundo servidor esclavo en el que se harán las consultas Particionar el registro de llamadas por mes, semana o día, y crear una tabla de tipo Merge para las consultas Servicio de cotizaciones Si es una herramienta de consumo interno con un número limitado de usuarios, MyISAM Si es un servicio web con mucho tráfico, miles de usuarios y alimentación de cotizaciones en tiempo real, InnoDB Una consulta no debe esperar Miles de usuarios intentando leer mientras simultáneamente se actualizan filas requiere bloqueos a nivel de fila

26 Introducción a MySQL Motores de almacenamiento: ejemplos Boletines de anuncios y foros de discusión 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 monoĺıticas con mucha actividad pesada de lectura y escritura La carga suele ser mediana o pequeña, MyISAM no es imprescindible InnoDB no es capa de ejecutar rápidamente 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ólo lectura

27 Replicación Contenidos 1 Introducción a MySQL 2 Replicación 3 Copia de seguridad y recuperación 4 Medición de rendimiento y perfilado Medición del rendimiento Perfilado de aplicaciones 5 Optimización Optimización de esquemas e índices Optimización de hw. y sw. Optimización del servidor

28 Replicación Definición de replicación Consiste en configurar uno o varios servidores como esclavos - o réplicas - de otro servidor Problema a resolver: mantener los datos de los servidores sincronizados Base para construir aplicaciones extensas y de alto rendimiento Admite diferentes topologías 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ólo algunas tablas

29 Replicación Problemas resueltos por la replicación Distribución de datos No exige un ancho de banda intensivo y funciona con una conexión intermitente Útil para mantener una copia de los datos en una ubicación geográficamente distante Balanceo de carga Permite distribuir peticiones de datos entre varios servidores Alta disponibilidad y failover Los esclavos ayudan a reducir el tiempo de caída del servidor principal Prueba de actualizaciones de MySQL Configuramos un servidor esclavo con la nueva versión 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

30 Replicación Funcionamiento de la replicación 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ón (relay log) El esclavo repite todos los eventos del registro de repetición sobre sus propios datos

31 Replicación Funcionamiento de la replicación El registro binario de mysql: Registra todas las operaciones del servidor que modifican datos (o podrían modificarlos, por ejemplo, un DELETE con filtro) con independencia de los motores de almacenamiento Está 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ó el evento en el servidor de origen Tipo de evento (por ejemplo, Query) Detalles del evento

32 Replicación Funcionamiento de la replicación El registro binario de mysql permite tres tipos de replicación: Basada en sentencias (statement-based replication) Se registra la instrucción 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ón de cualquier instrucción El registro aumenta de tamaño No es fácil auditar los cambios realizados Mixta (mixed-format replication) MySQL decide en función de la instrucción que se ejecuta si se usa replicación basada en sentencias o en filas Se usa la replicación basada en sentencias a no ser que la instrucción no sea segura Ver la descripción en el manual

33 Replicación Funcionamiento de la replicación El proceso para configurar la replicación es el siguiente: Configurar cuentas de replicación en cada servidor El thread E/S del esclavo hace una conexión 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ón Inidicar al esclavo como conectarse al maestro y desde qué punto del registro binario hay que replicar Opcionalmente, activar el registro binario y configurar su actualización

34 Replicación Funcionamiento de la replicación Es posible replicar sólo 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ón

35 Replicación Topologías de replicación Las restricciones en la replicación son las siguientes: Cada esclavo sólo puede tener un maestro Un maestro puede tener muchos esclavos Un esclavo puede actuar también como maestro Estas restricciones permiten diferentes topologías con diferentes aplicaciones Un maestro, múltiples esclavos Maestro-maestro en modo activo-activo Maestro-maestro en modo activo-pasivo Anillo Maestro, maestro de distribución, esclavos Árbol o pirámide

36 Replicación Topologías de replicación Un maestro, múltiples esclavos

37 Replicación Topologías de replicación Un maestro, múltiples esclavos La topología más sencilla y más común Todas las escrituras se realizan en el maestro, las lecturas se pueden realizar en cualquier servidor El número de esclavos está 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ón Utilizar un esclavo para copia de seguridad, para pruebas o para desarrollo

38 Replicación Topologías de replicación Maestro-maestro en modo activo-activo Cada maestro es a su vez esclavo del otro Cualquier servidor se puede utilizar para cualquier operación Posible uso: oficinas separadas geográficamente, donde cada oficina necesita su copia local de los datos Problemas: cambios conflictivos Actualización simultánea de la misma fila en ambos servidores Inserciones simultáneas con columnas AUTO INCREMENT Y si la replicación se detiene por un tiempo? Cómo reenganchamos después? Sólo se recomienda si tenemos datos bien particionados y buen reparto de privilegios

39 Replicación Topologías de replicación Maestro-maestro en modo activo-pasivo Uno de los servidores es un servidor pasivo de sólo lectura Permite intercambiar los papeles de forma muy sencilla: las configuraciones son simétricas Mantenimiento, optimización 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

40 Replicación Topologías de replicación Anillo

41 Replicación Topologías de replicación Anillo Tres o más maestros Cada servidor es un esclavo del servidor que está antes en el anillo, y maestro del servidor que está después Configuración simétrica, failover fácil. Es una configuración frágil: Depende enormemente de que todos los nodos funcionen correctamente Difícil que estén todos sincronizados a la vez: detener algún nodo es complicado Si eliminamos un nodo sin tener cuidado, sus eventos pueden propagarse de forma infinita por el anillo. El único nodo que filtra un evento es el que lo ha generado!

42 Replicación Topologías de replicación Maestro, maestro de distribución, esclavos

43 Replicación Topologías de replicación Maestro, maestro de distribución, esclavos Similar a la topología maestro-esclavos, pero no sobrecarga al maestro principal El maestro principal sólo tiene un esclavo que a su vez actúa como maestro de distribución El maestro de distribución usa el motor BlackHole que graba en el registro binario pero no mantiene tablas ni datos

44 Replicación Topologías de replicación Árbol o pirámide

45 Replicación Topologías de replicación Árbol o pirámide Si hay muchos esclavos, puede ser mas rentable un diseño en pirámide Esto alivia la carga del maestro y la redistribuye por los diferentes esclavos Desventaja: fallos en niveles intermedios afectan a un gran número de servidores Además, cuantos más niveles intermedios, más difícil y complicado es manejar los fallos

46 Replicación Problemas en la replicación La replicación 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ón sólo escala las lecturas, no las escrituras La distribución de la carga debe ser realizada por otro software La complejidad de la replicación se ve claramente en la longitud de la sección del manual

47 Copia de seguridad y recuperación Contenidos 1 Introducción a MySQL 2 Replicación 3 Copia de seguridad y recuperación 4 Medición de rendimiento y perfilado Medición del rendimiento Perfilado de aplicaciones 5 Optimización Optimización de esquemas e índices Optimización de hw. y sw. Optimización del servidor

48 Copia de seguridad y recuperación Introducción Recuperación no es restauración 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 él. Incluye todos los pasos para lograr que un servidor vuelva a ser completamente funcional y operativo: Restaurar copia de seguridad Reiniciar servidor Cambiar configuración Calentar las cachés del servidor Utilidades de las copias de seguridad Recuperación ante desastres. Un error importante corrompe los datos o el servidor Recuperación ante cambios no deseados. La gente cambia de idea, y ocurre más a menudo que los desastres Auditorías. Necesidad de recuperar datos o esquema en algún momento del pasado (ej. temas judiciales) Pruebas. La manera más fácil de cargar un servidor de pruebas con datos es usando una copia de seguridad

49 Copia de seguridad y recuperación Introducción El mejor sistema de copias de seguridad no es suficiente. Un buen plan de recuperación es fundamental El procedimiento de recuperación es complejo. Es fácil cometer errores Las copias de seguridad son rutinarias y no se realizan bajo situaciones de presión extrema. La recuperación se hace en medio de una situación de crisis Una persona puede planear, diseñar e implementar las copias de seguridad, pero podría no estar disponible cuando se produzca el desastre. Es necesario formar a personal cualificado para que se encargue de la recuperación Alternativas que no son copias de seguridad La replicación no es una copia de seguridad Usar discos en RAID Cómo nos recuperamos en estos casos de un DROP DATABASE?

50 Copia de seguridad y recuperación 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ódigo: disparadores y procedimientos almacenados (están en la BD mysql) Configuración del servidor y de la replicación Ficheros seleccionados del SO (trabajos cron, configuraciones de usuario y de grupo, scripts administrativos, reglas sud0, etc) Qué 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 trabajo de hoy? Necesitamos retroceder a un instante de tiempo predeterminado? Cuanto más nos permitamos perder, más fácil es hacer la copia Las copias de seguridad en MySQL son mucho más complicadas de lo que parece

51 Copia de seguridad y recuperación Tipos de copia de seguridad Copias calientes, templadas o frías? Calientes: sin detener el servidor ni bloquear las tablas Templadas: sin detener el servidor pero bloqueando las tablas Frías: deteniendo el servidor Copias lógicas o sin procesar? Copia lógica: en un formato que MySQL puede interpretar (SQL, CSV) Copia sin procesar: los archivos de mysql tal y como están almacenados en disco

52 Copia de seguridad y recuperación Tipos de copia de seguridad Inconvenientes de copias calientes Búferes sucios en el grupo de buffers de InnoDB (u otras cachés) Datos modificados mientras se está haciendo la copia Inconvenientes de copias frias Desconectar servidor es costoso, aun si se minimiza el tiempo de copia de seguridad Las páginas sucias en grupo de buffers InnoDB requieren tiempo para volcarse a disco Reiniciar también requiere tiempo: abrir tablas, calentar cachés, etc. Inconvenientes de copias templadas Tiempo de espera indeterminado debido al proceso de adquirir bloqueos

53 Copia de seguridad y recuperación Tipos de copia de seguridad Ventajas de las copias lógicas Archivos que se pueden manipular e inspeccionar con editores de textos Fáciles de restaurar Se pueden restaurar en una máquina diferente Independientes del motor de almacenamiento Se pueden retocar para exportar a otros SGBD Desventajas de las copias lógicas El servidor debe hacer el trabajo de generarlas Pueden llegar a ocupar mucho más que los datos en algunos casos La reconstrucción implica volver a ejecutar todas las sentencias y regenerar todos los índices.

54 Copia de seguridad y recuperación Tipos de copia de seguridad Ventajas de las copias sin procesar No hay trabajo adicional: se copian los archivos tal cual La restauración puede ser sencilĺısima: para MyISAM, simplemente copiar los archivos en su sitio; InnoDB, en cambio, obliga a detener el servidor La restauración es más rápida: no hay que ejecutar sentencias, ni reconstruir índices Desventajas de las copias sin procesar Suelen ocupar mucho más espacio que las copias lógicas (por ejemplo, el espacio de tabla InnoDB incluye mucho espacio sin utilizar) No siempre se pueden mover a través de las plataformas, SO y versiones de SQL (mayúsculas/minúsculas, representación punto flotante)

55 Copia de seguridad y recuperación Procedimiento de copia lógica Copia Realizar un volcado SQL con mysqldump o CSV con SELECT * INTO OUTFILE Restauración 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án abrirlos)

56 Copia de seguridad y recuperación Procedimiento de copia lógica Hay que asegurar que los datos son consistentes en un punto de tiempo determinado (por ejemplo, en una BD de comercio electrónico debe haber una factura por cada pago). Es complicado en copias calientes En motores transaccionales: realizar la copia en una transacción En motores no transaccionales, bloquear todas las tablas que se deben copiar juntas Esto no nos protege de una aplicación mal diseñada (por ejemplo, si el pago y la factura se registran en dos transacciones distintas)

57 Copia de seguridad y recuperación 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écnicas de gestión de ficheros del SO (por ejemplo, LVM) Restauración: MyISAM: bloquear las tablas y copiar los archivos de datos InnoDB: parar el servidor y sustituir los archivos

58 Copia de seguridad y recuperación 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ón: Restaurar la copia completa y ejecutar todos los registro binarios Restauración a un punto concreto del tiempo Localizar el punto de tiempo en los registros binarios y ejecutar hasta esa posición Eliminar el resultado de una instrucción Localizar la instrucción y ejecutar el registro binario hasta esa posición y desde después de esa posición

59 Medición de rendimiento y perfilado Contenidos 1 Introducción a MySQL 2 Replicación 3 Copia de seguridad y recuperación 4 Medición de rendimiento y perfilado Medición del rendimiento Perfilado de aplicaciones 5 Optimización Optimización de esquemas e índices Optimización de hw. y sw. Optimización del servidor

60 Medición de rendimiento y perfilado Medición del rendimiento y perfilado El objetivo de la optimización es aumentar el rendimiento de MySQL Los elementos a optimizar son muchos. Ej: esquemas, índices, consultas, configuración del servidor, hardware, software, aplicaciones Necesitamos dos prácticas básicas: Medición del rendimiento. Responde a Cómo se ejecuta? Permiten evaluar el desempeño del SGBD Permiten determinar la capacidad máxima del sistema Permiten discriminar los cambios que importan de los que no Muestran cómo se ejecuta la aplicación con datos diferentes Perfilado. Responde a Por qué se ejecuta así? Indica cuanto contribuye cada elemento de un sistema al coste de producir el resultado Lugares donde se pierde más tiempo Lugares donde se consumen más recursos

61 Medición de rendimiento y perfilado Medición del rendimiento Contenidos 1 Introducción a MySQL 2 Replicación 3 Copia de seguridad y recuperación 4 Medición de rendimiento y perfilado Medición del rendimiento Perfilado de aplicaciones 5 Optimización Optimización de esquemas e índices Optimización de hw. y sw. Optimización del servidor

62 Medición de rendimiento y perfilado Medición del rendimiento Objetivos de las medidas Las medidas de rendimiento permiten realizar las siguientes tareas: Medir rendimiento actual de nuestra aplicación 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ón a entornos cambiantes Picos esporádicos, configuraciones diferentes de servidores Probar configuraciones diferentes de hw., sw. y so. RAID5 o RAID10? núcleo 2.4 o 2.6 de Linux? escala bien con doble de memoria?

63 Medición de rendimiento y perfilado Medición del rendimiento Estrategias para medir Existen dos estrategias en la medida de rendimiento: Aplicación como un todo La preocupación última es el rendimiento de toda la aplicación 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ón. Es más difícil si sólo probamos una parte de ella Aislar mysql (SGBD, en general) Es difícil aislar puntos de referencia y de configuración de la aplicación Acercamiento paulatino: empezar por mysql Interesan medidas de rendimiento cortas, con tiempo de ciclo más corto Fácil aislar consultas típicas y repetirlas muchas veces

64 Medición de rendimiento y perfilado Medición del rendimiento Ejemplos de medidas de rendimiento Transacciones por unidad de tiempo (clásica) Se ajusta bien a aplicaciones interactivas de múltiples usuarios, OLTP Unidad típica: transacciones por segundo Tiempo de respuesta (latencia) Mide tiempo total requerido por una tarea (ej: milésimas, minutos) La ejecución repetida permite derivar tiempos de respuesta mínimo, máximo o medio Los tiempos mínimos y máximos no son muy útiles porque no son repetibles, cuanto más tiempo se ejecute la medida, más extremos serán, y varían mucho entre diferentes ejecuciones En general es mejor agregar utilizando percentiles (ej: el 95 % de las respuestas se responden en menos de 5 ms)

65 Medición de rendimiento y perfilado Medición del rendimiento Ejemplos de medidas de rendimiento Concurrencia Medimos el rendimiento de la aplicación bajo diferentes niveles de concurrencia Un ejemplo de medida: número 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ólo es un resultado, también es una propiedad que debemos configurar en nuestras pruebas Escalabilidad Útil en sistemas que tienen que mantener un rendimiento estable bajo 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ño de la base datos El número de conexiones concurrentes El hw. disponible

66 Medición de rendimiento y perfilado Medición del rendimiento Errores comunes en las medidas Algunos errores comunes en la definición de medidas de rendimiento: Usar un subconjunto no representativo de los datos Utilizar datos sintéticos distribuidos uniformemente Definir un escenario con un solo usuario Medir en un solo servidor el rendimiento de una aplicación distribuida Fallo en imitar el comportamiento del usuario: clics en vínculos uno tras otro sin parar, en una aplicación web Ejecutar consultas idénticas en un bucle, olvidando posibles pérdidas en caché No detectar los errores en el proceso de medida (ej: que una operación lenta se agilice mucho puede ser debido a un error de sintaxis en SQL) Olvidar tener en cuenta latencia del servidor después de reinicio

67 Medición de rendimiento y perfilado Medición del rendimiento Planificación de medidas de rendimiento Proceso de planificación 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 estándar o una prueba de diseño 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ón de los parámetros Almacenamiento de los resultados

68 Medición de rendimiento y perfilado Medición del rendimiento Planificación de medidas de rendimiento Proceso de planificación 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ánea de los datos, usando el servidor en caliente) Debemos tener cuidado con la carga externa y con las tareas periódicas Cambiar la menor cantidad de parámetros posible en cada prueba (los independientes) Es recomendable automatizar las ejecuciones de las pruebas (scripts, makefiles) El número de repeticiones depende del grado de certeza que se quiera alcanzar. Comúnmente: Ejecutar varias veces y eliminar los resultados discrepantes Ejecutar hasta que los resultados no varíen demasiado (reducir la varianza) Utilizar técnicas estadísticas Analizar los resultados Los resultados agregados permiten dar una idea general de la medida Los resultados detallados permiten detectar picos ocultos por la agregación

69 Medición de rendimiento y perfilado Medición del rendimiento Herramientas para medidas de rendimiento Herramientas específicas 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úmero de conexiones concurrentes Permite una instrucción SQL en ĺınea de comandos o un archivo con instrucciones SQL MySQL Benchmark suite Incluido desde la version 5.0 con mysql Mide lo rápido que ejecuta el servidor las consultas Muchas pruebas predefinidas, que permiten comparar diferentes motores de almacenamiento y configuraciones Mejorable (un sólo usuario, el conjunto de datos es pequeño, y usa un solo proceso (no multiples CPU)

70 Medición de rendimiento y perfilado Medición del rendimiento Herramientas para medidas de rendimiento Herramientas específicas 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ón OLTP Desarrollo parado Super Smack Pruebas de comparación + Prueba de estrés + Herramienta de generación de carga para MySQL y PostgreSQL Múltiples usuarios, carga datos de prueba (aleatorios) Lenguaje neutro (smack) para definir clientes, tablas, consultas, etc. Desarrollo parado

71 Medición de rendimiento y perfilado Medición del rendimiento Herramientas para medidas de rendimiento Herramientas de pila completa Ab Incluida con el servidor HTTP Apache Calcula el número de solicitudes que puede servir por segundo Sólo prueba una URL todo lo rápido que pueda httpload Utiliza un archivo de entrada con muchas URLs de las que elige aleatoriamente Prueba lo más rápido que pueda, o según una velocidad establecida (-rate) También simula usuarios concurrentes (-parallel) JMeter Aplicación Java para medir el rendimiento de otros programas Simula usuarios reales (tiempo de escalada configurable) Interfaz gráfica que permite reproducir prueba fuera de ĺınea

72 Medición de rendimiento y perfilado Perfilado de aplicaciones Contenidos 1 Introducción a MySQL 2 Replicación 3 Copia de seguridad y recuperación 4 Medición de rendimiento y perfilado Medición del rendimiento Perfilado de aplicaciones 5 Optimización Optimización de esquemas e índices Optimización de hw. y sw. Optimización del servidor

73 Medición de rendimiento y perfilado Perfilado de aplicaciones Objetivos del perfilado El perfilado de un sistema nos indica cuanto contribuye cada elemento al coste total de producción de un resultado Permite entender por qué 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ón Procesamiento de resultados en memoria Llamadas a recursos externos Algoritmos poco óptimos Si nos limitamos a medir tiempo de respuesta del servidor web No tenemos estadísticas del sistema que permitan determinar qué esfuerzo permite una mayor mejora El cuello de botella puede estar en otra parte.

74 Medición de rendimiento y perfilado Perfilado de aplicaciones Proceso de perfilado Es necesario incluir código de perfilado en las aplicaciones que tome mediciones de: Tiempo total de ejecución de la página Tiempo de ejecución de las consultas Tiempo de llamadas a recursos externos (servicios web) Es una sobrecarga al sistema, por lo que es necesario aplicar tácticas como Sólo realizar el perfilado en un porcentaje pequeño de las peticiones Guardar los datos en memoria y hacerlos persistentes en bloque

75 Medición de rendimiento y perfilado Perfilado de aplicaciones 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ón y desconexión Sin tiempos de ejecución: de poco interés para el perfilado El registro de consultas lentas Registra las consultas ejecutadas que sobrepasan un determinado tiempo Se puede configurar para registrar también las consultas que no utilizan índices Guarda tiempos de ejecución: permite perfilado Es difícil de utilizar: Una consulta es lenta porque tarda más de lo esperado, no porque tarda más que un umbral de tiempo Hay consultas que no tienen que usar el índice de ningún modo

76 Medición de rendimiento y perfilado Perfilado de aplicaciones Perfilado en MySQL Desde la versión , MySQL permite realizar perfilado de los recursos usados en una sesión 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ón La estrategia de análisis de resultados puede ser: Comprobar qué consultas tienen más impacto Comprobar el plan de ejecución de esas consultas con EXPLAIN Realizar los ajustes necesarios Repetir el análisis

77 Optimización Optimización de esquemas e índices Contenidos 1 Introducción a MySQL 2 Replicación 3 Copia de seguridad y recuperación 4 Medición de rendimiento y perfilado Medición del rendimiento Perfilado de aplicaciones 5 Optimización Optimización de esquemas e índices Optimización de hw. y sw. Optimización del servidor

78 Optimización Optimización de esquemas e índices Optimización de esquemas e índices Optimizar esquema mal diseñado o mal indizado mejora del rendimiento en órdenes de magnitud Sin embargo, hay que tener cuidado con los efectos secundarios Un nuevo índice INSERT y UPDATE más lentas Las tablas de resumen y los contadores agilizan consultas, pero el mantenimiento es más costoso Los cambios requieren conocer todo el sistema y cada elemento afectado Describiremos estas técnicas: Elección de tipos de datos óptimos y selección de clave primaria Distintos tipos de índices: B+, Hash y agrupados Estrategias de indexado Índices para ordenación Tablas de cache y de resumen Tablas de contadores Desnormalización

79 Optimización Optimización de esquemas e índices Elección de tipos de datos óptimos Elegir adecuadamente el tamaño es importante Usar el tipo de datos más pequeño posible Menos espacio en disco, memoria y CPU Cuanto más 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 vacía,... Proceso: Paso 1: Determinar tipo de datos: numérico, cadena, temporal Paso 2: Elegir tipo específico

80 Optimización Optimización de esquemas e índices Elección de tipos de datos óptimos DATETIME vs. TIMESTAMP Datetime: Entero empaquetado (YYYMMDDHHMMSS) de 8 bytes. Mayor rango de valores ( , con precisión de 1 segundo). Timestamp: Entero de 4 bytes. Número 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ás adelante (fragmentación, reasignación de espacio) Vale la pena cuando la longitud máxima de columna es mucho mayor que la media y hay pocas actualizaciones, o cuando el cjto. caracteres complejo, codificación variable (UTF-8).

81 Optimización Optimización de esquemas e índices Elección de tipos de datos óptimos 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ño fijo a la memoria Tabla temporal para ordenación: reservaría espacio para el máximo tamaño posible (motor Memory necesita filas de tamaño fijo) Mejor reservar el tamaño justo BLOB y TEXT Guardan grandes cantidades de datos (binarios y de cadena) Cada motor, diferente gestión Evitar usarlos en el ORDER BY ya que el motor Memory no permite campos TEXT ni BLOB, así que habría que usar myisam para la tabla temporal de ordenación) Truco (longitud lo bastante corta para que la tabla no sobrepase tmp table size) ORDER BY SUBSTRING(columna text, longitud)

82 Optimización Optimización de esquemas e índices Elección de tipos de datos óptimos ENUM en lugar de cadenas Ahorro de espacio Es solución sólo para listas fijas de cadenas. Ampliarla: ALTER TABLE Además: sobrecarga de conversión de valores (por ejemplo, al concatenar o al comparar) Usar sólo si la lista de cadenas no va a cambiar en el futuro

83 Optimización Optimización de esquemas e índices Selección 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áneas si no hay coincidencia exacta Conversiones de tipo impĺıcitas pueden provocar errores difíciles de detectar Elegir tamaño mas pequeño necesario dejando espacio para crecimiento futuro Por ejemplo: un entero (4 bytes) para códigos de provincias implica mucho espacio en claves externas Las cadenas de caracteres son una mala elección porque ocupan mucho espacio y son más lentas que los enteros Las cadenas de caracteres aleatorias (estilo UUID) implican: ralentización de los INSERT ya que el valor se inserta en una posición aleatoria del índice que puede crear fragmentación de páginas mal rendimiento de las caches ya que se elimina la localidad ralentización de los SELECT porque filas adyacentes en el resultado quedan dispersas en disco y memoria si las filas se almacenan ordenadas por clave

84 Optimización Optimización de esquemas e índices Revisión de los esquemas generados automáticamente Proceso tradicional: Modelado conceptual, lógico y físico Proceso de mapeado objeto-relacional: anotación de clases y creación de esquemas Proceso model-driven engineering: modelado conceptual y creación automática de esquemas Posibles problemas Uso reiterado de tipos VARCHAR sin ĺımite Tipos de datos en columnas de combinación 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

85 Optimización Optimización de esquemas e índices Índices Más 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 sólo busca eficientemente el prefijo en la parte más 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

86 Optimización Optimización de esquemas e índices Árbol B y B+ Admitido por todos los motores (menos Archive) Cada motor lo implementa a su modo. Por ejemplo, MyISAM usa compresión mientras que InnoDB no usa compresión Idea general: todos los valores se almacenan en orden y se accede mediante un árbol en el que cada hoja está a la misma distancia de la raíz y las páginas de hojas contienen punteros a los registros de la tabla. Agiliza acceso a los datos. Se realiza un acceso al nodo raíz y e va descendiendo por las ramas escogiendo punteros adecuados hasta llegar al valor correcto.

87 Optimización Optimización de esquemas e índices Árbol B y B+

88 Optimización Optimización de esquemas e índices Árbol B y B+ Tipos de consulta que pueden usar índice de un árbol B Coincidencia con valor completo. apellidos = Allen and nombre = Cuba and fnac = Coincidencia parcial con prefijo de columna apellidos like A % Coincidencia parcial con prefijo más a la izquierda apellidos = Allen and nombre like C % Coincidencia con rango de valores apellidos >= Allen % and apellidos <= Barrimore % Cláusulas ORDER BY por los campos del índice

89 Optimización Optimización de esquemas e índices Árbol B y B+ Limitaciones. No son útiles en: Búsquedas que no empiezan en la parte más izquierda de las columnas indizadas. Ejemplos: nombre = Cuba and fnac = apellidos like %Z No permiten saltar columnas del índice. Ejemplo: apellidos = Allen and fnac = No se optimiza el acceso a columnas a la derecha de la primera condición de rango. Por ejemplo: apellidos = Allen AND nombre >= J AND fnac =

90 Optimización Optimización de esquemas e índices Índices Hash Sólo soportado por el motor Memory (el indice por defecto) Para cada fila se crea un código hash con las columnas indizadas El índice es una tabla hash con apuntadores de fila (muy compactos) Las colisiones de la función hash se almacenan con una lista enlazada Útil sólo para búsquedas 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ólo se almacena un punto al registro Sólo permite comparaciones de igualdad (=, IN) pero no consultas de rangos (>100) Las colisiones de la función hash ralentizan el acceso y el mantenimiento Es posible simular índice hash con una columna extra, un árbol B+ y triggers

91 Optimización Optimización de esquemas e índices Índices agrupados Las filas de las tablas se guardan en las páginas 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 más 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 impĺıcito con la clave primaria, con un índice único sin valores NULL, o con una clave interna oculta Inconvenientes: Sólo ahorra E/S si los datos no caben en memoria La velocidad de inserción depende del orden de inserción (lo mejor, en el orden de la clave primaria) La actualización es costosa debido a la reubicación de páginas Páginas más sujetas a fragmentación al insertar filas nuevas Pueden ser más lentas para escaneos completos

92 Optimización Optimización de esquemas e índices Otros índices Índices espaciales (árbol R) Sólo en motor MyISAM Sólo para los tipos de datos y operaciones de geometría espacial (GEOMETRY) El soporte espacial de MySQL no es muy completo Índices de texto completo Sólo en el motor MyISAM Permite búsquedas de palabras clave en textos y cálculo de relevancias Soporta conceptos de recuperación de información (stopwords, lematización, búsqueda booleana)

93 Optimización Optimización de esquemas e índices Estrategias de indexado: aislar columnas Aislar la columna en las consultas para que no forme parte de una expresión 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);

94 Optimización Optimización de esquemas e índices 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ño idóneo que mantiene el índice altamente selectivo Selectividad = Valores diferentes indexados / Valores totales Bastante largo para proporcionar buena selectividad Bastante corto como para ahorrar espacio

95 Optimización Optimización de esquemas e índices Estrategias de indexado: Construir índices sobre prefijos Distribución de los valores diferentes

96 Optimización Optimización de esquemas e índices Estrategias de indexado: Construir índices sobre prefijos Calculo de las selectividades