Download Optimización en Sistemas de Bases de Datos

Document related concepts

Optimización de consultas wikipedia , lookup

Denormalización (base de datos) wikipedia , lookup

Join wikipedia , lookup

SQL wikipedia , lookup

Base de datos wikipedia , lookup

Transcript
Ensayo: 5
Tema: Optimización en Sistemas de Bases de Datos.
Facilitador: Lenin Herrera
Nombre: Yuderca Méndez Méndez
Matricula: 15-SISP-1-006
Materia: BD
Optimización en Sistemas de Bases de Datos.
La optimización del acceso a los datos es vital para el tiempo de carga de la página, debido a
que suele ser el factor que más afecta al tiempo que tiene que esperar el navegador para recibir el
HTML.
Este tipo de optimización es probablemente la más compleja de todas, en primer lugar
porque depende de dos factores variables en el tiempo: por un lado, de cómo y de qué tipo son las
consultas que se van a realizar y, por otro, de la carga de trabajo que tenga que soportar el servidor o
servidores.
En segundo lugar por la gran cantidad de conocimientos que hay que tener para saber
reescribir consultas, reescribir el código que ejecuta las consultas, crear índices, vistas materializadas,
particiones horizontales y verticales, réplicas, tablas de apoyo, saber elegir los tipos de datos a usar,
saber optimizar el esquema sin perder la lógica del modelo de negocio, saber ajustar los parámetros
de configuración del SGBD, conocer y saber usar sistemas de caché externos. Este tiempo de espera
es muy importante, ya que el resto de recursos de la página (imágenes, scripts y hojas de estilo), no
se empiezan a bajar hasta que el navegador no lee el HTML desde el que se hace referencia a estos
recursos. . Las primeras permiten no terminar con datos corruptos e inservibles, y al elegir un
NoSQL, se supone que las operaciones JOIN no se van a necesitar nunca.
Mostrar filas aleatorias:
Suele ser bastante común mostrar resultados aleatorios de una relación para dar sensación
de frescura en los contenidos. El problema es que esto se suele implementar de formas bastante
ineficientes, como por ejemplo ordenar por un valor aleatorio, lo que suele provocar que se lean
todas las filas de la tabla. En MySQL, si tenemos identificadores autonuméricos, lo mejor es cruzar
con identificadores aleatorios.
Cachear las consultas más frecuentes:
Activar la caché de base de datos del SGBD a veces puede empeorar el rendimiento. Esto
depende del volumen de datos al que se acceda más frecuentemente. Si el volumen de datos es alto y
se actualiza frecuentemente, estaremos siempre escribiendo en la caché en lugar de leer de ella.
Por ejemplo, supongamos que generamos un número aleatorio entre 1 y 100 y la consulta se
cachea si dicho número es menor que 10, de esta forma se guardará la consulta en caché con una
probabilidad del 10% en cada petición, así si la consulta tiene más peticiones, será más probable que
se guarde en caché.
Optimizar la paginación:
La paginación suele ser una tarea costosa cuando tenemos que mostrar varios números de
página, porque para eso se tiene que calcular el número de filas en la relación, lo que puede requerir
una lectura completa de la misma, dependiendo del SGBD. Siempre será más eficiente mostrar
enlaces de anterior y siguiente, recuperando todas las filas a mostrar y una más, de manera que
se muestra el enlace de siguiente página, si nos llega esta fila adicional desde la BD.
Optimización de consultas:
Para finalizar, algunos breves consejos para optimizar consultas:
Cambiar los OR por IN, cuando tenemos más de un valor para comparar.
Minimizar el coste de los JOIN: La concatenación natural o JOIN es la operación más
costosa de las bases de datos relaciones, ya que requiere realizar una multiplicación cartesiana y una
selección de valores. Algunas técnicas a usar para minimizar su efecto consisten en:
1. Reordenarlos para concatenar primero las relaciones con menos filas para reducir el
número de cruces.
2. Crear sub-consultas en donde se filtren o limiten el número de filas de las relaciones
grandes antes de realizar los siguientes JOINs.
3. A veces, dividir una consulta en varias, es mejor que hacerlo todo con una sola
consulta, de forma que podemos obtener en una primera consulta unos pocos
identificadores que podemos pasar con un IN a la siguiente consulta, en lugar de
realizar un JOIN.
4. Cambiar los JOIN por EXISTS si no se va a mostrar ningún dato de la relación con la
que se realiza el cruce.
Referencia
http://www.humanlevel.com/articulos/desarrollo-web/optimizacion-de-base-de-datos.html