Las consultas distribuidas tienen acceso a datos de varios orígenes de datos heterogéneos.Estos orígenes de datos pueden estar almacenado en el mismo equipo o en equipos diferentes.
El procesamiento de consultas tiene varas etapas a seguir para resolver una consulta SQL. Las características del modelo relacional permiten que cada motor de BD elija su propia representación: Consulta Distribuida
Es preciso tener en cuenta otros factores como son:
- El costo de transmisión de datos en la red.
- Repetición y fragmentación.
- Procesamiento de intersección simple
OBJETIVOS DEL PROCESAMIENTO DE CONSULTAS
Los objetivos del procesamiento de consultas son transformar una consulta escrita en un lenguaje de alto nivel, normalmente SQL, en una estrategia de ejecución correcta y eficiente expresada en un lenguaje de bajo nivel, por ejemplo, el álgebra relacional, y ejecutar dicha estrategia para extraer los datos solicitados.
FASES DEL PROCESAMIENTO DE CONSULTAS
El procesamiento de consultas puede dividirse en cuatro fases principales:
- Descomposición.
- Optimización.
- Generación de código.
- Ejecución.
METODOLOGIA DE PROCESAMIENTO DE CONSULTAS DISTRIBUIDAS
Primeramente se debe de contar con heterogenidad de los datos, para que puedan ser usados para formular consultas. Tenemos los sigueintes ejemplos:
BD CENTRALIZADA
BD DISTRUIBUIDA
Asi como tambien necesitamos contar con:
-Localizacion de los datos para generar reglas heuristicas
-Descomposicion de consultas en paralelo en cada nodo
-Reducir la cantidad de datos a transferir en la red
-Localizacion de los datos para generar reglas heuristicas
-Descomposicion de consultas en paralelo en cada nodo
-Reducir la cantidad de datos a transferir en la red
ESTRATEGIAS DE PROCESAMIENTO DE CONSULTAS DE BASES DE DATOS DISTRIBUIDAS
Contamos con la estategia de Reformulacion de consultas, que nos sirve para encontrar q la informacion que nos va a proveer sea solo la que se le pidio por la fuente
Tambien se cuenta con la estrategia de descomposicion de las fuentes, q consiste en que segun las fuentes q pidan cierto tipo de datos sean las atentidas con mayor velocidad.
OPTIMIZACION DE CONSULTAS DISTRIBUIDAS
Para poder optimizar una consulta necesitamos tener claras las propiedades del algebra relacional para asegurar la reformulacion de la consulta, al optimizar una consulta obtenemos los siguientes beneficios:
- Minimizar costos
- Reducir espacios de comunicaciones
- Seguridad en envios de informacion
CONSULTA NO OPTIMIZADA
MEJORAR EL RENDIMIENTO DE QUERIES EN SQL SERVER
Uso de sintaxis UNION
Debemos tener en cuenta que por defecto un UNION equivale a realizar un SELECT DISTINCT sobre el resultado final de una query. En otras palabras, UNION toma los resultados de dos recordsets, los combina y realiza un SELECT DISTINCT de cara a eliminar las filas duplicadas. Este proceso ocurre incluso si no hay registros duplicados en el recordset final. Si sabemos que hay registros duplicados, y esto representa un problema para la aplicación, entonces haremos uso de UNION para eliminar estas filas duplicadas.
Por otro lado si sabemos que nunca habrá duplicado de filas o si las hay pero no representa un problema para la aplicación entonces deberemos usar UNION ALL en lugar de UNION. La ventaja de UNION ALL es que no realiza el SELECT DISTINCT, lo cual evita uns gran cantidad de trabajo y recursos al servidor SQL.
Mejorar rendimiento de UNION
Otro caso bastante común es el que se explica en el siguiente ejemplo, imaginemos que queremos realizar una query para mezclar dos conjuntos de datos:
SELECT column_name1, column_name2
FROM table_name1
WHERE column_name1 = some_value
UNION
SELECT column_name1, column_name2
FROM table_name1
WHERE column_name2 = some_value
La misma query puede ser reescrita como se explica a continuación para mejorar el rendimiento de la misma:
SELECT DISTINCT column_name1, column_name2
FROM table_name1
WHERE column_name1 = some_value OR column_name2 = some_value
Y puede mejorarse aún más si sabemos que la mezcla de estos dos grupos de datos a paesar de contener duplicados no afectan al funcionamiento de la aplicación eliminando el DISTINCT.
Evaluar el uso de DISTINCT
Un aspecto relativo al rendimiento es la evaluación del uso de la sentencia DISTINCT. Muchos desarrolladores aplican esta sentencia por defecto aunque no se necesite, Sólo debe usarse si sabemos que la query puede devolver duplicados, y además esto puede provocar un mal funcionamiento de la aplicación que hace uso de los datos.
La sentencia DISTINCT genera una gran cantidad de trabajo extra a SQL Server debido a que consume muchos recursos que son necesarios para otras queries que sean lanzadas dentro de la base de datos. Sólo se debe usar si es necesario.
Devolver los datos que se necesitan
Un aspecto que siempre se menciona en todos los libros de SQL es que debemos devolver nada más que los datos que se necesitan, y esto sobre todo referido a las columnas de datos. Debemos evitar el uso de SELECT * ya que esto además de devolver más datos de los que seguramente necesitemos, impide el uso de índices, añadiendo mayor degradación al rendimiento del sistema.
Uso de operadores en el WHERE
Otro aspecto importante de cara a mejorar el rendimiento de las queries, es tener en consideración que operadores dentro de la clausula WHERE tienen mejor rendimiento, a continuación se detalla una lista ordenada de mejor a peor rendimiento:
Además de esto, existen otros criterios que son también importantes a la hora de elaborar la condición de cualquier Query. Estas consideraciones son relativas a que ciertos operadores pueden prestarse a tener mejor rendimiento según se usen, a continuación detallamos estos casos, ordenados de mayor a peor rendimiento:
En el caso de haber varias expresiones dentro del WHERE, no se agiliza el rendimiento por ordenarlos, excepto en algunos casos.
Forzado de INDICES
Es posible que podamos encontrarnos TABLE SCAN en las queries que lanzemos, a pesar de existir INDICES que mejorarían el rendimiento. En estos casos la mejor opción para forzar el uso de un INDICE es realizar los siguiente, como muestra el ejemplo:
SELECT * FROM tblTaskProcesses WHERE nextprocess = 1 AND processid IN (8,32,45)
Esto tarda 3 segundos y al siguiente QUERY tarda menos de un segundo:
SELECT * FROM tblTaskProcesses (INDEX = IX_ProcessID) WHERE nextprocess = 1 AND processid IN (8,32,45)
Concatenación ANDs
Si existe una cláusula WHERE que incluye expresiones conectadas por dos o más operadores AND, SQL Server evaluará desde la izquierda hacia la derecha en el orden que hayan sido escritas. Esto asume que no se hayan usado paréntesis para cambiar el orden de la ejecución. Por esta razón se debe considerar lo siguiente cuando usemos el operador AND:
http://es.slideshare.net/rapaluzji/procesamiento-de-consultas-528026?related=1
http://blogs.msdn.com/b/apinedo/archive/2007/01/24/mejorar-el-rendimiento-de-queries-en-sql-server.aspx
Uso de sintaxis UNION
Debemos tener en cuenta que por defecto un UNION equivale a realizar un SELECT DISTINCT sobre el resultado final de una query. En otras palabras, UNION toma los resultados de dos recordsets, los combina y realiza un SELECT DISTINCT de cara a eliminar las filas duplicadas. Este proceso ocurre incluso si no hay registros duplicados en el recordset final. Si sabemos que hay registros duplicados, y esto representa un problema para la aplicación, entonces haremos uso de UNION para eliminar estas filas duplicadas.
Por otro lado si sabemos que nunca habrá duplicado de filas o si las hay pero no representa un problema para la aplicación entonces deberemos usar UNION ALL en lugar de UNION. La ventaja de UNION ALL es que no realiza el SELECT DISTINCT, lo cual evita uns gran cantidad de trabajo y recursos al servidor SQL.
Mejorar rendimiento de UNION
Otro caso bastante común es el que se explica en el siguiente ejemplo, imaginemos que queremos realizar una query para mezclar dos conjuntos de datos:
SELECT column_name1, column_name2
FROM table_name1
WHERE column_name1 = some_value
UNION
SELECT column_name1, column_name2
FROM table_name1
WHERE column_name2 = some_value
La misma query puede ser reescrita como se explica a continuación para mejorar el rendimiento de la misma:
SELECT DISTINCT column_name1, column_name2
FROM table_name1
WHERE column_name1 = some_value OR column_name2 = some_value
Y puede mejorarse aún más si sabemos que la mezcla de estos dos grupos de datos a paesar de contener duplicados no afectan al funcionamiento de la aplicación eliminando el DISTINCT.
Evaluar el uso de DISTINCT
Un aspecto relativo al rendimiento es la evaluación del uso de la sentencia DISTINCT. Muchos desarrolladores aplican esta sentencia por defecto aunque no se necesite, Sólo debe usarse si sabemos que la query puede devolver duplicados, y además esto puede provocar un mal funcionamiento de la aplicación que hace uso de los datos.
La sentencia DISTINCT genera una gran cantidad de trabajo extra a SQL Server debido a que consume muchos recursos que son necesarios para otras queries que sean lanzadas dentro de la base de datos. Sólo se debe usar si es necesario.
Devolver los datos que se necesitan
Un aspecto que siempre se menciona en todos los libros de SQL es que debemos devolver nada más que los datos que se necesitan, y esto sobre todo referido a las columnas de datos. Debemos evitar el uso de SELECT * ya que esto además de devolver más datos de los que seguramente necesitemos, impide el uso de índices, añadiendo mayor degradación al rendimiento del sistema.
Uso de operadores en el WHERE
Otro aspecto importante de cara a mejorar el rendimiento de las queries, es tener en consideración que operadores dentro de la clausula WHERE tienen mejor rendimiento, a continuación se detalla una lista ordenada de mejor a peor rendimiento:
- =
- >, >=, <, <=
- LIKE
- <>
Además de esto, existen otros criterios que son también importantes a la hora de elaborar la condición de cualquier Query. Estas consideraciones son relativas a que ciertos operadores pueden prestarse a tener mejor rendimiento según se usen, a continuación detallamos estos casos, ordenados de mayor a peor rendimiento:
- Un literal único en lugar de varios usado al lado de un operador
- Un nombre de columna o de parámetro al lado de un operador
- Una expresión multi-operando al lado de un operador
- Un número único exacto al lado de un operador
- Un número único no exacto al lado de un operador (date, time)
- Datos de caracteres, Null
En el caso de haber varias expresiones dentro del WHERE, no se agiliza el rendimiento por ordenarlos, excepto en algunos casos.
Forzado de INDICES
Es posible que podamos encontrarnos TABLE SCAN en las queries que lanzemos, a pesar de existir INDICES que mejorarían el rendimiento. En estos casos la mejor opción para forzar el uso de un INDICE es realizar los siguiente, como muestra el ejemplo:
SELECT * FROM tblTaskProcesses WHERE nextprocess = 1 AND processid IN (8,32,45)
Esto tarda 3 segundos y al siguiente QUERY tarda menos de un segundo:
SELECT * FROM tblTaskProcesses (INDEX = IX_ProcessID) WHERE nextprocess = 1 AND processid IN (8,32,45)
Concatenación ANDs
Si existe una cláusula WHERE que incluye expresiones conectadas por dos o más operadores AND, SQL Server evaluará desde la izquierda hacia la derecha en el orden que hayan sido escritas. Esto asume que no se hayan usado paréntesis para cambiar el orden de la ejecución. Por esta razón se debe considerar lo siguiente cuando usemos el operador AND:
- Localizaremos la expresión menos probable de suceder y la pondremos en primer lugar de la expresión AND. De este modo si una expresión AND es falsa la cláusula finalizará inmediatamente ahorrando tiempo
- Si ambas partes de una expresión AND son iguales o tienen igual peso, y son falsas, pondremos la menos compleja primero. De este modo si es falsa la expresión se realizará menos trabajo para evaluar la expresión.
http://es.slideshare.net/rapaluzji/procesamiento-de-consultas-528026?related=1
http://blogs.msdn.com/b/apinedo/archive/2007/01/24/mejorar-el-rendimiento-de-queries-en-sql-server.aspx
