sql-server - rendimiento - trucos sql server

Rendimiento de diferentes enfoques de datos basados ​​en tiempo

Question

Pregunto esto en el contexto del reclamo de PerformanceDBA en esta respuesta a otra pregunta que esta consulta:

SELECT  ProductId,
        Description
    FROM  Product       p,
          ProductStatus ps
    WHERE p.ProductId = ps.ProductId  -- Join
    AND   StatusCode  = 2             -- Request
    AND   DateTime    = (             -- Current Status on the left ...
        SELECT MAX(DateTime)          -- Current Status row for outer Product
            FROM  ProductStatus ps_inner
            WHERE p.ProductId = ps_inner.ProductId
            )

el uso de una tabla ProductStatus que solo tiene una fecha efectiva (inicio) para un estado que cambia con el tiempo, superará esta consulta:

SELECT  ProductId,
        Description
    FROM  Product       p,
          ProductStatus ps
    WHERE p.ProductId = ps.ProductId  -- Join
    AND   StatusCode  = 2             -- Request
    AND   getdate() BETWEEN DateFrom AND Dateto

utilizando una tabla ProductStatus que contiene tanto una fecha de inicio como una de finalización para el estado.

Si bien acepto las otras afirmaciones hechas para que el primer enfoque sea mejor que el segundo, esperaría que el segundo enfoque sea más rápido (basado en mi experiencia con Oracle solamente) porque simplemente filtra los datos en lugar de realizar una subconsulta adicional y comparar con eso.

Me gustaría saber cómo Sybase o SQL Server procesarían estas consultas, y cuál es el rendimiento relativo en algunas pruebas simples.

Answer 1

Tratar de integrar el rendimiento en un diseño de base de datos siempre conduce a la pena más adelante.

Como se debatió en el otro hilo, si conoce la fecha en que un estado entró en vigencia, entonces sabrá la fecha en que expiró el estado anterior. Almacenar ValidFrom y ValidUntil es una herejía; considere el siguiente ejemplo, creado por el programa que se depura:

Status    ValidFrom   ValidUntil
Open     1 Jan 2010  30 Jan 2010
Closed  20 Jan 2010  30 Mar 2010

el modelo permite que un producto tenga 2 estados en el mismo instante, una alegría para los otros programadores que depuran en la misma base de datos, todos sus informes comienzan a tener duplicados.

Diseña tu base de datos correctamente, hasta la forma normal que puedas soportar.

Pruébelo con volúmenes de producción en un cuadro de especificaciones de producción. Si el rendimiento es insuficiente, entonces tendrá una idea general de dónde ajustar.

Answer 2

Por un lado, es bueno que hayas abierto una nueva pregunta. Pero en la mano, al extraer una consulta y preguntar si funciona más rápido, pierde el contexto de la pregunta anterior, la nueva pregunta está demasiado aislada. Como estoy seguro de que sabe, administrar una base de datos, administrar recursos (memoria / caché, disco, ciclos de CPU), administrar el código (bueno o malo) que usa esos recursos, son parte de la imagen completa. El rendimiento es un juego de comercio, nada es gratis.

1. El principal problema que tuve fue la duplicación de la columna EndDate, que se deriva fácilmente. Las columnas duplicadas equivalen a Anomalías de actualización. Smirkingman ha proporcionado el ejemplo clásico: algunas consultas obtendrán un resultado y otras consultas obtendrán el otro. Eso simplemente no es aceptable son las grandes organizaciones; o en bancos (al menos en países desarrollados) donde los datos son auditados y protegidos. Rompiste una regla básica de normalización y hay penalizaciones que pagar.

   • Actualizar Anomailes; dos versiones (ya detalladas). Los auditores pueden no pasar el sistema.

   • Tamaño de la mesa
     En cualquier tabla grande, es un problema, especialmente en series de tiempo o datos temporales, donde el número de columnas es pequeño y el número de filas es enorme. Entonces, algunos dirán que el espacio en el disco es barato. Sí, también lo son las enfermedades de transmisión sexual. Lo que importa es para qué se usa y cuán bien se lo cuida.

     • Espacio del disco
       Puede ser barato en una PC, pero en un servidor de producción no lo es. Básicamente, ha agregado un 62% al tamaño de fila (13 más 8 es igual a 21) y, por lo tanto, el tamaño de la tabla. En el banco que actualmente tengo asignado, cada departamento que posee los datos se carga de la siguiente manera, el almacenamiento basado en SAN es todo lo que hay. Las cifras son por GB por mes (este no es un banco australiano de alta gama):

       $ 1.05 para RAID5 sin relieve
       (Sabemos que es lento, pero es barato, simplemente no coloque información importante, ya que si se rompe, después de que el nuevo disco se caliente o se intercambie en frío, tarda días en volver a sincronizarse).

       $ 2.10 para RAID5 con espejo
       En la SAN, eso es.

       $ 4.40 para RAID1 + 0
       Mínimo para datos de producción, registros de transacciones respaldados y volcados de bases de datos nocturnos.

       $ 9.80 para RAID1 + 0 Replicado
       A un diseño de SAN idéntico en otro sitio a prueba de bombas. Corte de producción en minutos; casi cero pérdida de transacción.

     • Memoria caché
       Ok, Oracle no lo tiene, pero las dbs bancarias graves sí tienen cachés, y están administradas. Dado cualquier tamaño de caché específico, solo el 62% de las filas encajarán en el mismo tamaño de caché.

     • E / S lógica y física
       Lo que significa un 50% más de E / S para leer la tabla; ambos transmitiendo en caché y lecturas de disco.

2. Por lo tanto, si la consulta se desempeña mejor o peor de forma aislada, es un problema académico. En el contexto de lo anterior, la tabla es lenta y un 62% peor, todo el tiempo, en cada acceso. Y afecta a todos los demás usuarios del servidor. A la mayoría de los DBA no les importará (ciertamente no) si la forma de subconsulta tiene la mitad de velocidad, porque su bonificación está ligada a la aceptación de la auditoría, no solo al rendimiento del código.

   • Además, existe la ventaja adicional de no tener que volver a revisar el código y arreglar las transacciones debido a Anomalías de actualización.

   • Y las transacciones tienen menos puntos para actualizar, por lo que son más pequeños; menos bloqueos de bloqueo, etc.

3. De acuerdo, esa discusión en los Comentarios es difícil. En mi respuesta, he detallado y explicado dos subconsultas. Hubo un malentendido: usted estaba hablando de esta subconsulta (en la cláusula WHERE, una subconsulta de tabla ) y yo estaba hablando de la otra subconsulta (en la lista de columnas, una subconsulta escalar ) cuando dije que funciona tan rápido o más rápido. Ahora que eso se ha aclarado, no puedo decir que la primera consulta anterior (subconsulta en la cláusula WHERE, una tabla) funcionará tan rápido como la segunda consulta (con la columna duplicada); el primero tiene que realizar 3 escaneos, mientras que el segundo solo realiza 2 escaneos. (Me atrevo a decir que el segundo escaneará la tabla).

   El punto es que, además del problema de aislamiento, no es una comparación justa, hice el comentario sobre las subconsultas escalares. No recomendaría que una consulta de 3 escaneos sea tan rápida o más rápida que una consulta de 2 escaneos.

   La afirmación que hice sobre la subconsulta de la tabla de 3 escaneos (que cito aquí) debe tomarse en el contexto completo (ya sea esa publicación en toto, o la anterior). No me estoy alejando de eso.

   Esto es SQL ordinario, una subconsulta, que usa el poder del motor SQL, procesamiento de conjunto relacional. Es el método correcto, no hay nada más rápido, y cualquier otro método sería más lento. Cualquier herramienta de informe producirá este código con unos pocos clics, sin tipear.

   Me paso la mitad de mi vida eliminando alternativas ilegales como columnas duplicadas, que se basan en el tema del rendimiento, con los creadores cantando el mantra porque la tabla es lenta, por lo que se han "desnormalizado para el rendimiento". El resultado, predecible antes de comenzar, es una tabla de la mitad del tamaño, que tiene el doble de rendimiento general . The Times Series es la pregunta más común aquí (el enlace se vincula a otra pregunta, que se vincula con otra), pero imagine el problema en una base de datos bancaria: ClosingExposure diaria ClosingExposure y ClosingExposure por Security por Holding por UnitTrust por UnitTrust por Portfolio .

4. Pero déjame responder una pregunta que no se ha preguntado. Este tipo de interacción es normal, no es raro cuando se trabaja con equipos de desarrollo internos; aparece al menos una vez al mes. Un desarrollador de Crash Hot ya ha escrito y probado su código, usando una tabla con una columna duplicada, vuela, y ahora está estancado porque no lo pondré en el DB.

   No, lo probaré dentro del contexto de todo el sistema y:

   • la mitad de las veces, la tabla entra sin la columna EndDate porque no hay gran problema sobre la ejecución de la segunda mitad de la consulta en un segundo.

   • La otra mitad del tiempo, el rendimiento de la [subconsulta de la tabla] no es aceptable, por lo que implemento un indicador booleano (bit) para identificar IsCurrent . Eso es mucho mejor que una columna duplicada, y proporciona velocidades de 2 escaneos.

   • No en un millón de años me conseguirás duplicar una columna; agregando 62% al tamaño de la mesa; ralentizar la tabla en el contexto multiusuario completo en un 62%; y arriesgarse a fallar una auditoría. Y no soy un empleado, no recibo una bonificación.

   Ahora vale la pena probarlo: consulta con una columna duplicada vs consulta con un indicador IsCurrent , en el contexto completo del uso general de los recursos.

5. Smirkingman ha sacado un buen punto. Y lo reafirmaré claramente, para que no se fragmente y luego uno u otro fragmento sea atacado. Por favor, no rompa esto:

   Una base de datos relacional,
   Normalizado por un modelador Relacional con experiencia, a la Quinta Forma Normal verdadera
   (No hay anomalías de actualización, no hay columnas duplicadas),
   con plena conformidad relacional
   (IDEF1X, particularmente relacionado con la minimización de las claves principales de Id , y por lo tanto no paralizando el poder del motor relacional)
   dará como resultado más tablas más pequeñas, una base de datos más pequeña,
   con menos índices,
   requiriendo menos uniones
   (Así es, más tablas pero menos combinaciones),
   y superará a cualquier cosa que rompa cualquiera de esas reglas
   en el mismo hardware y la plataforma de db de la empresa
   (excluye freeware, MS, Oracle, pero no dejes que eso te detenga),
   en el contexto completo del uso de Producción OLTP
   por al menos un orden de magnitud,
   y será mucho más fácil de usar
   y para cambiar
   (nunca necesita "refactorización").

   He hecho esto al menos 80 veces. Dos órdenes de magnitud no son infrecuentes, si lo hago yo mismo, en lugar de proporcionar el marco para que alguien más lo haga.

Ni yo, ni las personas con las que trabajo ni quién me paga, me importa lo que haga una consulta de forma aislada.