En los artículos anteriores hemos podido ver la gran diferencia que hay de trabajar con documentos XML pequeños o medianos a trabajar con documentos grandes. Vamos a seguir profundizando y a ver cómo con ciertos documentos nos interesa separar aún más los procesos.

Selección documentos

Para hacer la comparativa, vamos a escoger dos documentos de muy distinto tamaño y para ello vamos a seguir usando planes cacheados. Pero en este caso, como nos interesa ver en forma práctica las diferencias entre uno y otro, cogeremos uno pequeño y otro muy grande. Los documentos los vamos a filtrar al pasarlos a las variables:

A continuación, extraemos datos de dichos documentos usando la misma consulta en ambos casos:

Comparativa Ejecuciones

Para que nos hagamos una idea, el primer plan tiene un tamaño en memoria de size_in_bytes = 24.576 que al pasarlo a formato XML y usar la función DataLength(@PlanXml) nos responde un tamaño de 4.538. Por lo tanto, no es un documento XML excesivamente pequeño, más bien mediano. Buscando el más grande, el tamaño de la variable XML es 18.723.372, una diferencia muy considerable y muy apropiada para ver las diferencias.

Ejecutamos para los dos documentos XML.

El primero tarda tan solo 85 ms en venir de memoria en formato XML y 147 ms en devolver los datos. Es decir, a pesar de su tamaño, no merece la pena optimar nada. Por esto es tan importante distinguir el trabajo entre unos documentos y otros.

El segundo tarda algo más de 7 s en venir de memoria como XML y casi 29 min en devolver los datos. Ni que decir tiene que en este caso sí merece la pena buscar más optimaciones. Podríamos decir que es un caso muy extremo, pero estos casos se dan y hay que saber cómo manejarlos.

El plan de ambas consultas es idéntico con la diferencia que uno trabaja con 2 planes internos –StmtSimple o StmtCond– y el otro con 1.627. El problema fundamental es que en el segundo plan, alguno de los operadores tienen que trabajar con más de 700 millones de filas –sí, un documento XML con millones de nodos–, ya lo habíamos visto, pero apreciamos que la diferencia es exponencial y por eso después de cierto límite es casi imposible trabajar con el documento.

También el número de lecturas que nos dan las estadísticas nos indica que la diferencia es exponencial agravada por el hecho de que tiene que usar el disco.

Estimaciones optimador de consultas

En este momento hay que partir una lanza para la forma en que trabaja SQL Server. Acabamos de ver que tanto para documentos, variables o campos XML pequeños o medianos, el proceso es muy rápido y muy optimado. Las premisas sobre las que trabaja el optimador de consultas al crear un plan son válidas en la gran mayoría de los casos. Tiene que suponer lo que hay dentro del documento XML, esto es obligatorio en documentos nuevos, y lo hace bastante bien visto el análisis que hemos hecho. Incluso si seguimos las recomendaciones para trabajar con XML, podemos hacerlo con documentos grandes en minutos. Recordemos que estamos hablando de datos que no son relacionales. Por lo tanto, es admirable el trabajo hecho.

Último desglose

La pregunta que nos podemos hacer es ¿por qué hay tantas lecturas para tan solo 1.627 planes internos? La respuesta está en que el nodo QueryPlan no está igual en StmtSimple que en StmtCond por lo que hay que buscar estos nodos continuamente. Un truco que nos da Michael Rys es buscar por adelantado los punteros a estos nodos. Además, como sólo nos interesa el primer subplan que pueda haber, sólo necesitamos uno por cada StmtCond. La consulta es algo más compleja, pero si analizamos el plan de ejecución actual o las estadísticas de E/S veríamos la gran eficiencia que tiene. Este sería un ejemplo, en este caso obteniendo el plan de una tabla temporal:

Como extraemos datos de varios nodos, nos interesa procesar cada uno por separado y de esta manera acelerar bastante la consulta. Es lo máximo que podemos «desglosar» el trabajo con nuestro documento XML grande para obtener los datos de la manera más rápida.

CONCLUSIÓN

En este artículo hemos analizado la diferencia entre los documentos XML muy grandes y el resto, y cómo dicha diferencia no es lineal sino más bien exponencial, por lo que, de trabajar de una forma optimada al máximo a trabajar de una válida para documentos pequeños y medianos, es lo mismo que lograr obtener los datos a simplemente no poder trabajar.
Hemos dicho que era la última optimación, pero ¿qué pasa con los índices XML? Lo veremos en el último artículo de la serie.

Más Información

Desde Danysoft y si rellenas este formulario, te ayudaremos a facilitarte la información que necesitas.

0 comentarios

Dejar un comentario

¿Quieres unirte a la conversación?
Siéntete libre de contribuir!

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Artículos Relacionados

Materiales amigos Danysoft

Recopilatorio de las grabaciones, artículos, guías y libros puestos a disposición de la comunidad por Danysoft

22/07/2019

Seguir leyendo  

FotoWare Saas

Fotoware Saas en un sistema de gestión de Activos Digitales (Sistema DAM) que te permite trabajar con tus recursos digitales de forma organizada y rápida.

26/06/2019

Seguir leyendo  

Curso Modernización de aplicaciones Delphi

No te pierdas este curso que incluye los temas más destacados en cuanto a su utilidad a la hora de modernizar las aplicaciones desarrolladas en Delphi.

29/05/2019

Seguir leyendo  

La Guía de Delphi !AHORA GRATIS!

Danysoft te ofrece la oportunidad de tener el libro "La Guía de Delphi" totalmente GRATIS, ¡No te quedes sin el tuyo!

11/04/2019

Seguir leyendo