Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Cuarto Semestre
Docente: Liliana Corona Granados
1.
Cuando intentamos hacer ms rpida una aplicacin de bases de datos, hay que
empezar con la aplicacin en s y asegurarse de que las tablas estn normalizadas
de forma adecuada, y las columnas estn indexadas, esto es siempre un buen
comienzo. Pero si ya se ha hecho todo lo anterior y las cosas siguen siendo lentas.
Entonces los pasos previos a la instalacin de MySQL (al igual que otro software
cuya instalacin sea crtica) se deben tomar ciertas consideraciones para preparar
en un disco duro la instalacin de MySQL.
Comprobar hardware mnimo necesario
Decidir la distribucin. MySQL est disponible para numerosas plataformas,
hay que decidir cul es la que nos interesa, en base a la caracterstica del
sistema, fiabilidad, buena integracin etc.
Decidir el formato de distribucin. Hay dos posibilidades:
Memoria en el disco
Del lado del servidor, el nico y ms importante factor en determinar cmo de bien
rendir MySQL, es la memoria. MySQL es capaz de ejecutar varios subprocesos a la
vez. Esto significa que cada vez que se realiza una conexin, MySQL crea un
subproceso. Cada subproceso consume memoria. El almacenamiento en cach de
los resultados tambin consume memoria. Se puede pensar entonces, que entre
ms memoria tengamos en el servidor, ser lo mejor. Sin embargo no es suficiente
con tener mucha memoria disponible, es necesario indicarle a MySQL como
queremos que use la memoria.
En la administracin del disco duro los datos estn organizados por bloques que
pueden ser manejados por tamaos fijos o variables, el acceso a cierto bloque de
datos en un disco duro variara de acuerdo a la suma del tiempo que tarda en brazo
del cabezal a la pista correcta del plato, esperar la rotacin del eje hasta el sector
que deber ser ledo y en transferir los datos desde el inicio del sector hasta el
extremo del sector.
El proceso de lectura y escritura dentro del disco duro ocurre cuando el brazo del
cabezal se desplaza al sector indicado para leer o escribir los datos que se procesan
dentro de MySQL.
El SGBD puede leer una seccin continua de datos desde el disco duro, por medio
de peticiones de operaciones de exploracin al sistema operativo, para organizar los
datos en el disco duro en un orden secuencial, al optimizar MySQL mediante
comando optimize table, las tablas de sus grupos de registros y de los ndices son
agrupadas en forma de bloqueLas configuraciones por defecto de MySQL son bastante conservadoras para el
hardware de hoy en da, sin embargo, si se tiene un servidor MySQL dedicado con
varios cientos de mega bytes de RAM, se debe ser capaz de darle a MySQL una
porcin bastante grande de ella para trabajar. Por defecto, slo usar una pequea
porcin de lo que haya disponible; esto se debe a que no hay ninguna forma de
saber si est corriendo en un servidor dedicado donde ser usado de forma
continua o si est corriendo en un esforzado porttil donde slo se usa para
almacenar una pequea aplicacin.
Mucha de la informacin presentada a continuacin se centrar en el uso de la
memoria y se asume que se est usando el tipo de tabla por defecto de MySQL,
MyISAM. Actualmente existen otros tipos de tablas transaccionales ms avanzadas,
tales como InnoDB o Gemini.
MySQL usa la memoria para una variedad de bfferes internos y cachs que
influyen en el nmero de veces que se ha de acceder a archivos que residen en el
disco. Cuanto ms a menudo tenga que esperar a que responda un disco, ms lento
ser. An los discos duros ms modernos siguen siendo un orden de magnitud ms
lenta que la memoria RAM, y dado la reciente baja en los precios de la memoria, es
muy factible que se pueda aadir ms memoria al servidor y as acelerar los
procesos. Actualizar a discos duros ms rpidos debera ser la ltima opcin.
Los bfferes y cachs de MySQL son de dos tipos: globales, y por hilo.
Globales: tal y como sugiere el nombre, estas reas de memoria son reservadas
una vez y son compartidas a travs de todos los hilos de MySQL. Dos de los ms
importantes son el bffer de claves y la cach de tablas. Debido a que son bfferes
compartidos, el objetivo es que sean lo ms grandes posibles.
Por hilo: estos bfferes reservan memoria individualmente a medida que necesitan
realizar operaciones particulares, tales como ordenar o agrupar datos. A propsito,
la mayora de los bfferes MySQL se reservan en esta forma.
A continuacin se examina primero que funcin tienen cada uno de los bfferes y
como configurar e inspeccionar sus valores, posteriormente se mostrar como
examinar contadores de rendimiento de MySQL y juzgar si los cambios que se
realizan tienen implicaciones o no.
Uso de memoria
El bffer de claves es donde MySQL cachea los bloques de ndices para tablas
MyISAM. Cada vez que una bsqueda usa un ndice, MySQL mirar antes de nada a
ver si el ndice relevante est o no en memoria. El parmetro key_buffer en el
archivo my.cnf determina que tan grande puede ser este bffer. Una vez que el
bffer este lleno, MySQL har sitio para nuevos datos reemplazando datos antiguos
que no hayan sido usados recientemente.
El tamao del bffer de claves aparece como key_buffer_size en la salida de SHOW
VARIABLES. Con un bffer de claves 384 Mega Bytes, se vera algo como:
key_buffer_size 402649088
Base de datos
Hablando especficamente de las tablas que integrarn la base de datos, en MySQL,
debe respetarse un tamao mximo, el cual vara dependiendo del sistema
operativo donde se encuentre instalado el MySQL.
Al conocer estos datos el administrador y planeador de la base de datos conocers
el mximo crecimiento al que puede llegar una base de datos.
El tamao de las tablas variar dependiendo del tamao de los tipos de datos, los
cuales pueden ser comnmente: numricos, caracteres y fechas.
Existen valores null, este se considera como valor no existente y se puede aplicar a
todos los tipos de columnas; existen tambin smbolos utilizados para la definicin
de los diferentes tipos de datos en Mis
Las tablas MyISAM estn compuestas de tres archivos en disco:
El archivo de datos nombredetabla.MYD, el archivo ndice nombredetabla.MYI, y
finalmente, el archivo de definicin de la tabla llamado nombredetabla.FRM. Para
poder usar una nica tabla, MySQL necesita de hecho abrir los tres archivos. El
archivo .FRM se cerrar despus de que lea el esquema, pero los dems
permanecern abiertos, MySQL no los cerrar hasta que lo necesite. Esto evita una
sobrecarga asociada con la apertura y cierre de los archivos si la tabla se usa
frecuentemente. Los archivos normalmente no se suelen cerrar hasta que ocurre
uno de los siguientes eventos:
Bfferes de registro
Siempre que MySQL ha de escanear una tabla, el hilo que realiza el escaneo
reservar un bffer de registro para cada tabla que ha de escanear. Esto sucede
tpicamente cuando MySQL decide que es ms eficiente escanear la tabla que usar
un ndice para una bsqueda. Tambin ocurre cuando simplemente no hay un ndice
que se pueda usar.
Al incrementar el valor de record_buffer en el archivo my.cnf, se permite que
MySQL lea las tablas en trozos ms grandes. Es probable que esto reduzca el
nmero de bsquedas en el disco y haga que el escaneo sea significativamente ms
rpido en un servidor muy atareado.
Sin embargo, se tiene que ser muy cuidadoso con el bffer de registro si se tienen
muchos clientes que realizan bsquedas completas sobre tablas. Debido a que el
bffer de registro se reserva por cada hilo, se puede acabar en una situacin donde
clientes individuales hagan que se reserven bfferes de registro al mismo tiempo.
Si el resto de la memoria est limitada es probable que se empiece a hacer uso de
la memoria de intercambio y se ver dramticamente reducido el rendimiento. En la
versin 3.23.41 se introdujo un parmetro relacionado denominado
record_rnd_buffer.
Al igual que record_buffer, se usa para escanear un gran nmero de filas. El
record_rnd_buffer se usa para bsquedas que resultan en una ordenacin
intermedia del archivo adems de algunas lecturas de registro no secuenciales.
Afortunadamente, si no se fija el valor de record_rnd_buffer se establecer por
defecto el valor de record_buffer.
Bffer de ordenacin
Tal y como implica su nombre, el bffer de ordenacin se usa para responder a
bsquedas que involucren el ordenamiento de los datos -aquellas con una sentencia
ORDER BY en ellas. Adems, el bffer de ordenacin se usa para las bsquedas que
involucren agrupar datos -aquellas con una sentencia GROUP BY. Al igual que los
dems bfferes que se han visto, el bffer de ordenacin es relativamente pequeo
por defecto. Al ajustar la entrada de sort_buffer en el archivo my.cnf:
set-variable= sort_buffer= 8M
Puedes reducir dramticamente la cantidad de tiempo que se usa para ordenar
grandes grupos de resultados. El bffer de ordenacin aparece como sort_buffer en
la salida de SHOW VARIABLES, por ejemplo:
sort_buffer 8388600
Bfferes de registro
Antes de discutir cmo medir o juzgar los efectos de cualquier cambio que se
realice, se debe considerar brevemente un acercamiento a la afinacin del
rendimiento. Hay unas cuantas cosas que se deben tener en mente cuando se
empiezan hacer y probar cambios:
1. Slo cambiar un parmetro cada vez. Puede que los cambios no resulten siempre
en el comportamiento esperado. Si se cambian demasiados parmetros a la vez,
se corre el riesgo de asignar un cambio en el comportamiento al parmetro
equivocado.
2. No hacer cambios en sistemas en produccin. Si es del todo posible, se debe
tener un servidor de pruebas disponible que sea parecido en naturaleza al
servidor de bases de datos de produccin. Hacer cambios en la configuracin de
MySQL seguramente requerir que se pare y reinicie el servidor, lo que har que
los usuarios experimenten interrupciones en el servicio.
3. Usar datos reales. El tipo de datos que se estn usando afecta a cmo responde
MySQL a las bsquedas. Idealmente, se debera usar una copia de las bases de
datos de produccin. Si no es posible hacer esto; entonces se debera intentar
construir un subconjunto representativo de datos.
4. Realizar pruebas realistas. Es fcil asumir que se sabe que pruebas aplicar
simplemente porque se sabe cules son las reas problemticas. Sin embargo,
algunos cambios de la configuracin aceleran partes lentas de una aplicacin al
mismo tiempo que ralentizan cosas que antes eran bastante rpidas.
5. Ser sistemtico y registrar descubrimientos. Es importante que se mantenga la
pista de los cambios que se realizan y como afectan al rendimiento. Despus de
varias horas (o incluso das) de pruebas, es ms que probable que no se recuerde
exactamente qu es lo que se ha cambiado y si los cambios fueron positivos o
negativos.
Observando los nmeros de rendimiento de la base de datos
Con los pocos puntos de partida en mente y un concepto de cmo hacer pruebas,
ahora se debe considerar cmo monitorizar el progreso. Afortunadamente, MySQL
tiene ms de 50 contadores internos (o variables de estado), que mantienen la
pista de cuntas veces ocurren varios tipos de eventos.
Dado que el espacio en este artculo sirve para comentar solamente algunas de las
variables de estado de MySQL, en el manual de MySQL se describen todas y cada
una de ellas en mayor detalle. Para ver estos nmeros, se puede usar la sentencia
SHOW STATUS. En este caso se mencionan nicamente las variables relacionadas
con el bffer de claves:
SHOW STATUS LIKE 'Key%'
Key_read_requests 3844786889
key_reads 16525182
Key_write_requests 303516563
Key_writes 152315649
Estas cuatro variables dicen mucho sobre el rendimiento del bffer de claves de
MySQL. Cada vez que MySQL sea capaz de leer una clave (o ndice) del bffer de
claves (en vez de ir a disco), incrementar automticamente el valor de
key_read_requests. Si MySQL ha de leer la clave del disco porque no estaba ya en
la cach, incrementar key_reads. La misma lgica se aplica para las escrituras de
disco. Sabiendo esto, podemos calcular la eficiencia (o hit rate) para el bffer de
claves.
Usando una formula Como:
100 - ((Key_reads / Key_read_requests) * 100)
Podemos obtener un porcentaje que representa cmo a menudo es capaz MySQL de
leer las claves directamente de la cach en vez de irse a disco. Cuanto ms cerca
est el valor de 100, mucho mejor. Usando los nmeros de arriba, se tiene un hit
rate de cerca del 99.57 por ciento. Generalmente, suele ser una buena idea
mantener este porcentaje por encima del 90 por ciento. A fin de cuentas, de lo que
se trata, es de tener una mejora medible del rendimiento de MySQL.
2. Especfica cules son las diferencias entre un disco preparado y un disco que
no sea preparado para instalarlos.
La diferencia es de que debe determinarse si la plataforma donde se desea hacer la
instalacin esta soportada, aqu debemos notar que no todos los sistemas
soportados son igualmente adecuados para ejecutar MySQL. En algunas
plataformas el funcionamiento ser mucho ms robusto y eficiente que otras.
Debe elegirse la distribucin que se instalara, hay varias versiones de MySQL
disponibles y la mayora lo estn en varios formatos de distribucin. Se puede elegir
entre distribuciones pre armadas que contienen programas binarios (pre compilado)
o bien cdigo fuente. La eleccin siempre se debe considerar a travs del manual
de instalacin y debemos verificar que sistema operativo tenemos en nuestro
ordenador.
Conclusiones:
Al estar investigando, hubo un cambio en la visin para poder instalar el sistema
gestor de base de datos MySQL, ya que anteriormente no tomaba en consideracin
como preparar un disco duro en la instalacin.
Manuales.guebs.com/mysql-5.0/installing.html
Instalar MySQL
www.jorgesanchez.net/bd/adb1.pdf
Apndice: Instalacin de MySQL