Planear notificaciones
Para usar notificaciones de consulta de forma eficaz, debe tener en cuenta si la aplicación puede beneficiarse del uso de las mismas, si las consultas que usa la aplicación admiten notificaciones, así como la estrategia que la aplicación va a usar para suscribirse y recibir notificaciones.
Las notificaciones de consulta proporcionan una forma cómoda de reducir los ciclos de ida y vuelta a la base de datos si los datos de la consulta se modifican con relativa poca frecuencia, si la aplicación no precisa de una actualización instantánea cuando se modifican los datos y si la consulta cumple los requisitos y las restricciones que se indican en Crear una consulta de notificación. Muchas aplicaciones basadas en Web cumplen estos criterios, lo que permite que se beneficien de las notificaciones de consulta.
No todos los escenarios pueden beneficiarse de las notificaciones de consulta. Las notificaciones de consulta son útiles en situaciones en las que una aplicación lee los datos de una base de datos con frecuencia, pero en las que las actualizaciones de datos son poco frecuentes. Por ejemplo, la información de una aplicación de catálogo en línea se consultará con más frecuencia que las veces que se actualice el catálogo. Sin embargo, en el caso de un carro de la compra en línea, el contenido de un particular puede actualizarse con mucha frecuencia, por lo que las notificaciones de consulta son menos beneficiosas.
Las notificaciones de consulta son más eficaces cuando una aplicación emite consultas que comparten una estructura común y que sólo presentan variaciones en los valores de los parámetros. Por ejemplo:
SELECT ProductNumber, Name FROM Production.Product WHERE ListPrice < 300
SELECT ProductNumber, Name FROM Production.Product WHERE ListPrice < 500
En este caso, las suscripciones de notificaciones de consulta de ambas notificaciones comparten la misma plantilla interna, lo que requiere una menor sobrecarga de SQL Server que dos notificaciones con una estructura de consulta distinta. Tenga en cuenta, no obstante, que se conservan los parámetros de las consultas. Aunque las consultas compartan una misma plantilla, al agregar un elemento con un valor de 350 para ListPrice, se producirá una notificación de la segunda consulta, pero no de la primera.
Cuando las notificaciones de consulta están activas en una tabla, las actualizaciones de la tabla resultan más costosas. El Motor de base de datos realiza un trabajo adicional para comprobar las suscripciones y, si es necesario, generar notificaciones. La reutilización de las plantillas internas ayuda a minimizar la sobrecarga por suscripción. Por lo tanto, sólo debe usar notificaciones de consulta para las aplicaciones que envíen consultas con una estructura similar. Una aplicación que envíe consultas con distintas estructuras no debería usar notificaciones de consulta.
Por ejemplo, una aplicación que muestre los elementos del catálogo comprendidos en un intervalo de precios determinado enviará consultas con la misma estructura. En este caso, el Motor de base de datos podrá reutilizar la plantilla interna para cada consulta, y las notificaciones de consulta serán capaces de mejorar el rendimiento. Sin embargo, una aplicación que permita la creación de informes ad hoc enviará consultas con una estructura variable. En este caso, la aplicación no debería usar notificaciones de consulta.
El Motor de base de datos mantiene una plantilla interna siempre y cuando haya una suscripción registrada, como mínimo, que use dicha plantilla. El Motor de base de datos limita el número de plantillas internas distintas de una tabla específica. Una vez alcanzado este límite, el Motor de base de datos no registra las suscripciones que darían lugar a la creación de una nueva plantilla. En lugar de ello, el Motor de base de datos genera inmediatamente un mensaje de suscripción que indica que la suscripción no se ha podido registrar.
Planear una estrategia eficaz de notificaciones de consulta
Las notificaciones de consultan suelen funcionar muy bien cuando el número total de notificaciones es bajo o moderado, y la aplicación no requiere un tiempo de respuesta a la notificación instantáneo cuando los datos cambian. El escenario de invalidación de caché de nivel web típico se ajusta a este modelo y tiende a ser una aplicación adecuada para usar notificaciones de consulta. Las notificaciones de consulta podrían no ser la mejor opción para las aplicaciones cuando las notificaciones se deben recibir con un tiempo de respuesta inferior al segundo, cuando la infraestructura de red no es rápida y confiable, o cuando el volumen de notificaciones es muy alto.
Cuando use notificaciones de consulta, pruebe y ajuste su aplicación en la escala y en el entorno donde funcionará cuando se implemente. Considere el escenario de caso de uso universal real con la mayor carga esperada y planee ráfagas de actividad alta si hay posibilidad de que se produzcan.
Si va a usar notificaciones de consulta en una situación en la que necesite que las notificaciones de consulta sean confiables y se produzcan en un tiempo inferior a un segundo, las mismas técnicas se aplican a la aplicación de notificaciones de consulta que a la creación de una aplicación OLTP de alto rendimiento.
Asegúrese de que la aplicación no contiene bloqueos durante un tiempo superior a una fracción de segundo. Por ejemplo, no ejecute transacciones de varias instrucciones desde un cliente a través de una red en cuyo rendimiento no pueda confiar.
Identifique y elimine las zonas activas de las tablas de datos de usuario.
Las tablas internas de notificaciones de consulta se suelen examinar secuencialmente en busca de cada actualización con una tabla de usuario relacionada en la que se hayan establecido las notificaciones de consulta. Si el bloqueo de nivel de tabla mantenido en la tabla interna de notificaciones de consulta podría convertirse en un cuello de botella, considere crear particiones en la tabla de usuario que tenga la notificación de consulta en varias tablas independientes para reducir el número de posibles notificaciones que se deben evaluar para cada cambio en los datos.
Si sus solicitudes de notificación tienen una duración útil breve, considere usar un tiempo de espera con el constructor SqlDependency que es significativamente menor que el valor predeterminado de 5 días (por ejemplo, de un minuto). Esto puede reducir en gran medida el número de filas en las tablas internas de notificaciones de consulta. Eso, a su vez, puede reducir el tiempo necesario para procesar esas tablas y reducir la contención del bloqueo en ellas.
Alternativas a las notificaciones de consulta
Si necesita un tiempo de respuesta muy predecible y rápido para las notificaciones de los cambios de los datos en un entorno con tasas de actualización de datos altas y muchas solicitudes de notificación pendientes, considere soluciones alternativas, por ejemplo, las siguientes.
Cree un desencadenador AFTER UPDATE en la tabla que se va a supervisar, cuya acción usa SQL Server Service Broker para enviar un mensaje a la entidad que necesita la notificación. (Esto podría diseñarse de varias maneras, por ejemplo, agregando una columna a la tabla de interés con una indicación de la entidad a la que se deben notificar los cambios o uniendo la tabla principal a una segunda tabla que contenga información sobre la entidad que requiere la notificación).
Use una solución de nivel de aplicación personalizada que no confíe en las notificaciones de consulta. Por ejemplo, configure una notificación para que tenga lugar completamente desde una aplicación de software intermedio que mantenga los datos que se van a supervisar en una colección de objetos de la memoria principal. LA aplicación puede generar una notificación cuando un objeto se modifica de modo que cumple sus criterios para que se produzca la notificación.
Use Windows Server App Fabric Cache, que admite un mecanismo de notificaciones de cambios basado en una memoria caché de objetos en memoria y devuelve las funciones que se registran con los objetos.