¿Debe el ajuste de consultas ser proactivo o reactivo?

Como desarrollador de software y aspirante a DBA, trato de incorporar las mejores prácticas cuando diseño mis bases de datos de SQL Server (el 99% de las veces mi software se encuentra sobre SQL Server). Realizo el mejor diseño posible antes y durante el desarrollo.

Pero, al igual que cualquier otro desarrollador de software, se agregan funcionalidades, errores y solo cambios de requisitos que exigen objetos de base de datos alterados / creados.

Mi pregunta es, ¿debería el ajuste de consultas ser proactivo o reactivo? En otras palabras, unas pocas semanas después de algunas modificaciones pesadas en el código / base de datos, ¿debería reservar un día para verificar el rendimiento de la consulta y ajustarlo en función de eso? Incluso si parece estar funcionando bien ?

¿O debería ser consciente de que un rendimiento inferior al promedio debería ser una comprobación de la base de datos y volver a la pizarra proverbial?

El ajuste de consultas puede llevar mucho tiempo y, dependiendo del diseño inicial de la base de datos, podría ser un beneficio mínimo. Tengo curiosidad por el modus operandi aceptado.

Ambos, pero principalmente proactivos

Es importante realizar pruebas durante el desarrollo con volúmenes realistas y calidad de datos. Es increíblemente común que una consulta se ejecute en un desarrollador de 100 o 1000 filas y luego quede plana con 10 millones de filas de producción.

Le permite tomar notas también sobre "el índice puede ayudar aquí". O "vuelve a visitarme". O "se solucionará con la nueva característica xxx en la próxima versión de DB".

Sin embargo, algunas consultas no resistirán la prueba del tiempo. La distribución de datos cambia o se vuelve exponencial porque el optimizador decide usar un tipo de unión diferente. En este caso, solo puedes reaccionar.

Diciendo que, al menos para SQL Server, las diversas consultas DMV de "índice perdido" y "consulta más larga" pueden indicar áreas problemáticas antes de la llamada telefónica

Editar: para aclarar ...

Proactivo no significa ajustar cada consulta ahora. Significa ajustar lo que necesita (ejecutar con frecuencia) a un tiempo de respuesta razonable. En su mayoría, ignore las consultas semanales de informes del domingo a las 3 a.m.

OK, morderé y tomaré una visión contraria. En primer lugar, diría que nunca debes comenzar haciendo algo que sabes que te llevará a problemas. Si desea llamar a esto aplicando las mejores prácticas, continúe. Esto es lo más lejos que debería ser proactivo.

Después de eso, se desperdicia tiempo (y dinero), así que continúe y entregue su producto. En lugar de tomar una tonelada de consultas de ajuste de tiempo de diseño que pueden o no ser cuellos de botella, use ese tiempo para pruebas adicionales, incluidas las pruebas de carga.

Cuando descubra que algo no está cumpliendo con sus especificaciones de diseño, o si algo cae en el 10% o 20% inferior de la lista de tiempos de respuesta de su perfilador, invierta el tiempo que necesita para modificar lo que sea que sea roto.

En un mundo perfecto, todo se diseñaría perfectamente desde el principio y se desarrollaría utilizando una secuencia de compilación lógica. En el mundo real, existen limitaciones en el presupuesto y el tiempo, y sus datos de prueba pueden no terminar pareciéndose a sus datos de producción. Por esta razón, digo que use el sentido común para evitar problemas de manera proactiva, pero concentre sus recursos limitados ajustando las cosas que resultan ser problemas reales en lugar de gastar tiempo y dinero que probablemente no tenga para buscar problemas imaginarios o potenciales.

Vas a hacer 3 tipos de ajustes, 1 reactivo y 2 proactivo.

Reactivo

De la nada, algunas consultas comienzan a causarle problemas. Podría deberse a un error o función de la aplicación, una tabla que crece más allá de las expectativas, un aumento en el tráfico o el optimizador de consultas se vuelve "creativo". Este podría ser un tipo de asunto en medio de la noche, o podría ser en respuesta a la lentitud del sistema de naturaleza no crítica. De cualquier manera, el carácter definitorio de la afinación reactiva es que ya tiene un problema . No hace falta decir que quieres hacer lo menos posible. Lo que nos lleva a ...

Proactivo

Tipo 1: mantenimiento de rutina

En algún tipo de programación, cada pocos meses o semanas, dependiendo de la frecuencia con la que cambie su esquema y la rapidez con la que crezcan sus datos, debe revisar el resultado de las herramientas de análisis de rendimiento de su base de datos (por ejemplo, informes AWR para Oracle DBA). Está buscando problemas incipientes, es decir, cosas que en su camino requieren un ajuste reactivo, así como fruta baja, elementos que probablemente no causarán problemas pronto pero que pueden mejorar con poco esfuerzo con la esperanza de prevenir mucho -futuros problemas. La cantidad de tiempo que debería dedicar a esto dependerá de la cantidad de tiempo que tenga y en qué otra cosa podría dedicarlo, pero la cantidad óptima nunca es cero. Sin embargo, puede reducir fácilmente la cantidad que necesita gastar haciendo más de ...

Tipo 2: diseño adecuado

La advertencia de Knuth contra la "optimización prematura" es ampliamente conocida y debidamente respetada. Pero debe usarse la definición adecuada de "prematuro". Algunos desarrolladores de aplicaciones, cuando se les permite escribir sus propias consultas, tienden a adoptar la primera consulta a la que acuden que es lógicamente correcta, y no tienen en cuenta el rendimiento, presente o futuro. O pueden probar contra un conjunto de datos de desarrollo que simplemente no es representativo del entorno de producción (consejo: ¡no haga esto! Los desarrolladores siempre deben tener acceso a datos realistas para las pruebas). El punto es que el momento adecuado para ajustar una consulta es cuando se implementa por primera vez, no cuando aparece en una lista de SQL de bajo rendimiento, y definitivamente no cuando causa un problema crítico.

Entonces, ¿qué calificaría como una optimización prematura en terrenos DBA? Al principio de mi lista estaría sacrificando la normalización sin una necesidad demostrada. Seguro que podría mantener una suma en una fila principal en lugar de calcularla en tiempo de ejecución a partir de las filas secundarias, pero ¿realmente necesita hacerlo? Si eres Twitter o Amazon, la desnormalización estratégica y el cálculo previo pueden ser tus mejores amigos. Si está diseñando una pequeña base de datos contable para 5 usuarios, la estructura adecuada para facilitar la integridad de los datos debe ser la máxima prioridad. Otras optimizaciones prematuras son también una cuestión de prioridades. No pierda horas ajustando una consulta que se ejecuta una vez al día y toma 10 segundos, incluso si cree que puede reducirla a 0.1 segundos. Tal vez tenga un informe que se ejecute durante 6 horas diarias, pero explore programarlo como un trabajo por lotes antes de invertir tiempo en ajustarlo. No invierta en una instancia de informes replicada en tiempo real por separado si su carga de producción nunca flota por encima del 10% (suponiendo que pueda administrar la seguridad).

Al realizar pruebas con datos realistas, realizar conjeturas informadas sobre los patrones de crecimiento y tráfico (además de las asignaciones para picos) y aplicar su conocimiento de las peculiaridades del optimizador de su plataforma, puede implementar consultas que se ejecutan (casi) de manera óptima no solo ahora, sino en el futuro , y en condiciones menos que ideales. Cuando aplica las técnicas adecuadas, el rendimiento de la consulta puede predecirse y optimizarse con precisión (en el sentido de que cada componente es tan rápido como debe ser).

(Y mientras lo haces, ¡ aprende estadísticas! )

En un mundo perfecto, todos los ajustes se realizarían de manera proactiva en la fase de diseño y nada sería reactivo, pero el mundo no es perfecto. Encontrará que los datos de prueba a veces no son representativos, se habrán perdido casos de prueba, las cargas serán inesperadamente diferentes y habrá errores que causarán problemas de rendimiento. Estas situaciones pueden requerir un ajuste reactivo, pero eso no significa que se prefiera el ajuste reactivo. El objetivo siempre debe ser atraparlos por adelantado.

Su planificación para la sintonización retroactiva es muy pragmática. Cuando realice las pruebas, debe documentar los tiempos y el rendimiento esperados y, en ocasiones, debe incorporar un análisis que le permita saber cuándo los procesos de producción no cumplen con las especificaciones de diseño. De esta manera, puede identificar de antemano qué código debe ajustarse. Luego puede determinar no solo cuál es el problema, sino también por qué no lo detectó en la fase de diseño / prueba.

Para mí, las pruebas de rendimiento siempre han sido parte del proceso de desarrollo. ¿Desea cambiar esta tabla, modificar este informe, agregar esta función? Como parte de las pruebas, se asegura de que puede comparar el rendimiento individual y general con las líneas de base conocidas y / o con los requisitos (por ejemplo, algunos informes se ejecutan en segundo plano o de otra manera están automatizados, por lo que el rendimiento, o más bien la velocidad, de cada consulta en el el sistema no siempre es la máxima prioridad).

En mi humilde opinión, esto no debería ser un proceso reactivo en absoluto: nunca debe esperar hasta que un cambio cause un problema de rendimiento en la producción para comenzar a reaccionar ante él. Cuando realice el cambio en dev / test, etc., debería probar esos cambios con datos similares en hardware similar con las mismas aplicaciones y patrones de uso similares. No permita que estos cambios se apresuren a la producción y lo sorprendan. Esto casi siempre sucederá cuando no sea conveniente pasar un día sintonizando: el presupuesto para ese tiempo de sintonía con mucha anticipación.