¿La mejor manera de probar el rendimiento de un almacén de datos?

Question

Tengo un almacén de datos basado en PostgreSQL.

Hasta ahora, he estado tratando de ejecutar consultas en una base de datos que contiene solo una fracción de mi base de datos real. Una vez que he escrito las consultas de una manera que las haga eficientes para esta pequeña base de datos de prueba, ejecuto las consultas en la verdadera.

El problema es que una vez que ejecuto las consultas en la base de datos real, la base de datos real se ejecuta fuera de la memoria y comienza a escribir cosas como índices y tablas temperaturas en el disco. Esto significa que podría ser que diferentes consultas serían óptimas para la base de datos de prueba y la base de datos real. ¿Significa esto que realmente tengo que ejecutar consultas que tardan varios minutos en completarse para saber, qué consulta es la óptima?

Answer 1

Aprender a interpretar el EXPLAIN salida, luego verifique que el EXPLAIN La salida muestra que el plan de consulta elegido en su gran base de datos es similar a lo que esperaría, antes de ejecutar la consulta.

Answer 2

Tres preguntas:

1) ¿Qué tan complejas son las consultas? La generación de índices y tablas TEMP sugiere que el servidor debe generar estas cosas debido a operaciones complejas en columnas no indexadas. ¿Qué tan probable es esto? Por lo que informa, parece que la respuesta probable es "compleja"

2) ¿Qué tan grandes son los conjuntos de devoluciones? ¿El resultado final es 100 filas o 1 millón? Por lo que informa, la respuesta podría ser cualquier cosa. Sospecho que esta pregunta no es tan importante, pero al menos es importante saberlo.

3) Repetir la pregunta 1 de una manera diferente, incluso si los conjuntos devueltos son pequeños, ¿hay enormes resultados intermedios que deben compilarse en el camino hacia el pequeño resultado? Nuevamente, sospecho que la respuesta aquí es que se están generando resultados intermedios complejos grandes.

Esto sugeriría que al menos algunas cosas deben indexarse, y tal vez los datos deben estructurarse en el camino para estar más cerca de lo que está tratando de consultar.

Una última pregunta, ¿es este un problema generalizado para la mayoría de sus consultas más importantes, o solo para una o dos?

Editar en respuesta al comentario: Hago consultas de almacén de datos todo el día, y algunas toman 10 minutos más o menos. Algunos toman horas, y los empujé a un trabajo de fondo y los interrumpe en etapas para evitar que empantane todo. Esa es la naturaleza del manejo de conjuntos de datos muy grandes.

Mis preguntas en la respuesta original tienen como objetivo determinar si sus consultas de problemas alguna vez finalizar. Es posible escribir involuntariamente una consulta que produce tantos datos intermedios que puede alejarse, regresar 2 días después, y todavía está funcionando. Así que reafirmaría mis tres preguntas originales, de hecho, son la única forma de responder a su pregunta por completo.

Resumen: Sí, algunas consultas tardan mucho más, es la naturaleza de la bestia. Lo mejor que puede esperar es el rendimiento lineal a la cantidad de datos que se leen, y si hay 100 millones de filas para procesar, eso tomará minutos en lugar de segundos. Pero mucho más importante, si una consulta se ejecuta en 4 segundos en 1 millón de filas, pero en 100 millones de filas toma >> 400 segundos (como una hora), esas preguntas originales que hice lo ayudarán a descubrir por qué, con el objetivo de optimizar Esas consultas.