Anar al contingut

Optimisació de consultes

De L'Enciclopèdia, la wikipedia en valencià

Quan parlem de optimisació de consultes nos referim a millorar els temps de resposta en un sistema de gestió de bases de senyes relacional, puix l'optimisació és el procés de modificar un sistema per a millorar la seua eficiència o també l'us dels recursos disponibles.

En bases de senyes relacionals el llenguage de consultes SQL és el més utilisat pel comú dels programadorés i desenrolladorés per a obtindre informació des de la base de senyes. La complexitat que poden alcançar algunes consultes pot ser tal, que el disseny d'una consulta pot prendre un temps considerable, obtenint no sempre una resposta òptima.

Els optimizadores basats en cost assignen un cost (que intenta estimar el cost de la consulta en térmens d'operacions d'entrada-eixida requerides, requeriments de CPU i atres factors) a cada u d'eixos plans, i elegix el que té menor cost. El conjunt de plans d'eixecució es forma examinant els possibles camins d'accés (per mig d'índexs o seqüencials), algoritmes de JOIN (sort-merge join, hash join, bucles anidados). El optimizador no pot ser accedit directament pels usuaris, sino que, una volta enviades les consultes al servidor, passen primer per l'analisador i recent llavors apleguen al optimizador.

Implementació

[editar | editar còdic]

La majoria dels optimizadores presenten els plans d'eixecució com un arbre de nodos del pla. Un nodo del pla encapsula una operació simple en l'eixecució de la consulta. Els resultats intermijos fluïxen des dels fulls de l'arbre cap a la raïl. Els fills d'un nodo representen a les operacions les eixides de les quals són l'entrada del nodo pare. Per eixemple, un nodo JOIN tindrà dos fills, que representen als dos operants de el JOIN. Els fulls de l'arbre representen operacions que produïxen resultats per mig de busca en el disc, per eixemple, realisant una busca indexada o una busca seqüencial.

L'eficiència d'un pla d'eixecució és en gran part determinada per l'orde en el qual s'opera en les taules. Per eixemple, en fer JOIN d'una taula chicoteta en unes atres molt majors, prendrà més temps si primer s'operen les taules grans i després la menuda. La majoria dels optimizadores determinen l'orde de JOIN per mig d'un algoritme de programació dinàmica impulsat pel proyecte “System R database project” d'IBM, que funciona en les següents etapes:

  1. Es computen totes les formes d'accedir a cada relació de la consulta; estes formes poden ser:
    1. Busca seqüencial.
    2. Busca indexada, si existira un índex sobre una relació que poder ser utilisat per a respondre a un predicat de la consulta.
      Per a cada relació, el optimizador guarda la forma més eficient d'accedir a ella, aixina com també la forma més eficient d'accedir-la de manera d'obtindre els resultats en un orde determinat.
  2. Es consideren les combinacions de cada parell de relacions per a les quals existixca una condició de JOIN. Per a cada parell, es consideren els algoritmes de JOIN disponibles implementats pel DBMS. Este preservarà la forma més eficient de fer JOIN de cada parell de relacions.
  3. Tots els plans de consultes de tres relacions són computats, unint cada pla de dos relacions produïts per l'etapa prèvia, en les relacions que queden en la consulta.

L'algoritme seguix la pista de l'orde dels resultats que produïx un pla d'eixecució. Un pla es considera millor que un atre només si produïx el resultat en el mateix orde. Açò és aixina per dos raons:

  1. Un orde particular pot evitar operacions d'ordenament posteriors.
  2. Determinat orde pot accelerar un JOIN subsecuente perque agrupa les senyes en determinada forma.

Una tupla d'una relació o d'una taula correspon a una fila d'aquella taula. Les tuplas estan comunament desordenades posat que matemàticament una relació es definix com un conjunt i no com una llista. No existixen tuplas duplicades en una relació o taula donat el fet de que una relació és un conjunt i els conjunts per definició no permeten elements duplicats.

Un corolari important en este punt és que la clau primària sempre existix donada la condició d'unicitat de les tuplas, per lo tant, com a mínim la combinació de tots els atributs d'una taula pot servir per a la conformació de la clau primària, no obstant usualment no és necessari incloure tots els atributs, comunament algunes combinacions mínimes són suficients.


Referències

[editar | editar còdic]