¿Es factible mejorar el rendimiento del servidor SQL con el almacenamiento en caché?

Question

Cuál es la solución más común y fácil de implementar para mejorar la velocidad de la base de datos SQL Server 2008R2 & .Net 3.5 aplicación.

Tenemos una aplicación con los siguientes atributos:
- número pequeño de clientes simultáneos (~ 200 en MOST).
- operaciones matemáticas complejas en el lado del servidor SQL
- estamos imitando algo que el oráculo de row-level security (Por lo tanto usando de TVF y StoredProcs en lugar de tablas que consultan directamente) -El principal problema es que los usuarios realizan gran cantidad de actualizaciones/inserciones/eliminaciones/cálculos, y se asustan porque necesitan esperar a que las páginas se recarguen mientras se realizan esas acciones.

Las preguntas que necesito una aclaración sobre son los siguientes:

1. Lo que es más rápido: devolver conjunto de datos entero de SQL Server y la realización de funciones matemáticas en # lateral C, o la realización de funciones de cálculo en el lado de SQL (por lo tanto, no volver columnas extra). ¿O solo depende del hardware?
2. El almacenamiento en caché mejora el rendimiento (por ejemplo, si agregamos caché redis). ¿O las soluciones de almacenamiento en caché solo son factibles para una gran cantidad de clientes?
3. ¿Es una mala práctica precalcular algunos de los datos y almacenarlos en alguna parte de la base de datos (por lo tanto, cuando el usuario lo solicite, ya se calculará). O esto es lo que el almacenamiento en caché supone hacer? Si esto no es una mala práctica, ¿cómo se configura el servidor SQL para hacer cálculos cuando hay recursos disponibles?
4. ¿Cómo el almacenamiento en caché puede mejorar el rendimiento si todavía necesita ir a la base de datos y ver si se actualizaron los registros?

sugerencias y comentarios generales también son bienvenidos.

Answer 1

Vamos a separar la respuesta en dos partes, el rendimiento de la ejecución de la consulta y el almacenamiento en caché para mejorar ese rendimiento. Creo que debería comenzar con la carga de direcciones en su servidor SQL e intentar optimizar el proceso que se ejecuta al máximo, esto debería resolver la mayor parte de la necesidad de implementar cualquier almacenamiento en caché.

Según su pregunta, parece que tiene un sistema que se utiliza para el procesamiento transaccional y también para agregaciones/cálculos, esto a menudo generará conflictos cuando estas dos tareas se bloqueen mutuamente. Una consulta larga que realiza operaciones matemáticas puede bloquear/mantener un objeto requerido por la UI. La optimización de estos sistemas para trabajar lado a lado y mejorar la eficiencia de la consulta es la clave para tener un mayor rendimiento.

Para empezar, utilizaré sus preguntas. ¿Qué es más rápido? depende de la agregación real que está realizando, si está tratando con un conjunto de operaciones, es decir SUM/AVG de una columna, guárdelo en SQL, por otro lado, si tiene un cursor en el procedimiento, muévalo a DO#. ¡Los cursores matarán tu rendimiento! Ha preguntado si es una mala práctica agregar datos a un lado y luego consultar ese repositorio, esta es la mejor práctica :). Al final, tendrá una base de datos que abastecerá a los clientes transaccionales y de alto ritmo, y otra base de datos que almacenará la información agregada; esto estará disponible rápida y fácilmente para sus otras necesidades. Llevarlo al siguiente paso dará como resultado que tenga un almacén de datos, por lo que este es definitivamente el lugar al que desea dirigirse cuando tiene mucha información y cálculos.

Por último, el almacenamiento en caché, esto es complicado y realmente depende de la naturaleza específica de sus necesidades, yo diría que tome el enfoque anterior, dedique el tiempo a mejorar los procesos y espero que el resultado final haga que el almacenamiento en caché sea redundante.

Uno de sus mejores amigos para la tarea es el Analizador de SQL, ejecute un rastreo en stmt: completado para ver cuál es la duración más alta/io/cpu y selecciónelo primero.

¡Buena suerte!