Pianificazione delle notifiche
Per ottimizzare l'utilizzo della funzionalità di notifica delle query, è consigliabile verificare se le notifiche possono essere utili per l'applicazione, se le query utilizzate dall'applicazione supportano le notifiche e la strategia che verrà utilizzata dall'applicazione per la sottoscrizione e la ricezione delle notifiche.
La notifica delle query consente di ridurre il numero di round trip al database se i dati della query vengono modificati raramente, se l'applicazione non richiede aggiornamenti immediati nel caso di modifica dei dati e se la query soddisfa i requisiti e le limitazioni descritti in Creazione di una query da notificare. Molte applicazioni soddisfano questi requisiti e possono pertanto sfruttare i vantaggi offerti dalla notifica delle query.
La notifica delle query non risulta utile in tutti gli scenari. Le notifiche sono utili quando un'applicazione deve leggere di frequente i dati del database, che vengono tuttavia aggiornati piuttosto raramente. Ad esempio, un'applicazione per la gestione del catalogo online viene visualizzata più frequentemente rispetto alla frequenza con cui viene aggiornato il catalogo. Nel caso di un carrello acquisti online, è possibile invece che il contenuto venga aggiornato di frequente e pertanto la notifica delle query non risulta particolarmente utile.
Le notifiche delle query sono più efficienti se l'applicazione esegue query con una struttura comune e nelle quali variano solo i valori dei parametri. Ad esempio:
SELECT ProductNumber, Name FROM Production.Product WHERE ListPrice < 300
SELECT ProductNumber, Name FROM Production.Product WHERE ListPrice < 500
In questo caso, il modello interno delle sottoscrizioni di entrambe le notifiche delle query è uguale e pertanto l'overhead richiesto in SQL Server è inferiore rispetto a quello di due notifiche con una struttura di query diversa. Si noti tuttavia che i parametri delle query vengono mantenuti. Benché le query condividano un modello, l'aggiunta di un elemento con un valore ListPrice di 350 determina una notifica per la seconda query, ma non per la prima.
Se la notifica delle query è attiva per una tabella, gli aggiornamenti di tale tabella saranno più costosi. Motore di database deve infatti eseguire operazioni aggiuntive per verificare le sottoscrizioni e, se necessario, per generare le notifiche. Per ridurre al minimo l'overhead per sottoscrizione è possibile riutilizzare i modelli interni. È pertanto consigliabile utilizzare la notifica delle query solo per le applicazioni che eseguono query con strutture simili ed evitare invece di utilizzarla per le applicazioni che eseguono query con strutture diverse.
Ad esempio, un'applicazione che visualizza gli articoli del catalogo compresi in una fascia di prezzo specifica esegue query con la stessa struttura. In questo caso, Motore di database può riutilizzare il modello interno per ogni query e la notifica delle query può migliorare le prestazioni. Un'applicazione che invece consente il reporting ad hoc esegue query con una struttura variabile. In questo caso non è consigliabile utilizzare la notifica delle query nell'applicazione.
Motore di database gestisce un modello interno fino a quando viene utilizzato almeno da una sottoscrizione registrata. Motore di database limita il numero di modelli interni diversi per una tabella specifica. Quando viene raggiunto il limite, Motore di database non registra più le sottoscrizioni che comportano la creazione di un nuovo modello. Motore di database genera immediatamente un messaggio che indica che non è possibile registrare la sottoscrizione.
Pianificazione di una strategia delle notifiche delle query efficiente
Le notifiche delle query generalmente funzionano molto bene quando il numero totale di notifiche è ridotto e l'applicazione non richiede tempi di risposta della notifica immediati quando i dati vengono modificati. Il tipico scenario di mancato invalidamento della cache a livello Web si adatta a questo modello e tende a essere una buona applicazione per l'utilizzo delle notifiche delle query. Le notifiche delle query potrebbero non essere la scelta migliore per le applicazioni quando le notifiche devono essere ricevute con un tempo di risposta a frazione di secondo, quando l'infrastruttura di rete non è né affidabile né veloce o quando il volume di notifiche è molto alto.
In caso di utilizzo di notifiche delle query, testare e ottimizzare l'applicazione su scala e nell'ambiente in cui verrà eseguito quando sarà distribuito. Considerare lo scenario reale dei casi di utilizzo con il carico più pesante previsto e pianificare i picchi di elevata attività che potrebbero verificarsi.
Se si utilizzano le notifiche delle query in una situazione in cui sono necessarie notifiche delle query a frazione di secondo affidabili, si applicano le stesse tecniche che vengono utilizzate per la compilazione di qualsiasi applicazione OLTP a prestazioni elevate.
Verificare che l'applicazione che si utilizza non contenga blocchi per più di una frazione di secondo. Ad esempio, non eseguire transazioni con più istruzioni da un client su una rete con prestazioni inaffidabili.
Identificare ed eliminare le aree critiche nelle tabelle dei dati utente.
Le tabelle interne delle notifiche delle query vengono spesso analizzate in sequenza per ogni aggiornamento di una tabella utente correlata, sulla quale sono state impostate le notifiche delle query. Se il blocco a livello di tabella per la tabella interna delle notifiche delle query diventa un collo di bottiglia, prendere in considerazione, quindi, il partizionamento in numerose tabelle distinte della tabella utente con la notifica delle query, al fine di ridurre il numero di possibili notifiche che devono essere valutate per ogni modifica dei dati.
Se le richieste di notifiche hanno una vita utile breve, prendere in considerazione l'utilizzo di un timeout impostato tramite il SqlDependency Constructor significativamente inferiore al valore predefinito di 5 giorni (ad esempio un minuto). Ciò può ridurre notevolmente il numero di righe nelle tabelle interne delle notifiche delle query e, a sua volta, ridurre il tempo necessario per elaborare tali tabelle e il conflitto dei blocchi.
Alternative alle notifiche delle query
Se è necessario un tempo di risposta veloce e altamente determinabile per le notifiche delle modifiche dei dati in un ambiente con alte percentuali di aggiornamento dei dati e molte richieste di notifica in attesa, prendere in considerazione soluzioni alternative, come una di quelle descritte di seguito.
Creare un trigger AFTER UPDATE nella tabella monitorata, la cui azione utilizza SQL Server Service Broker per inviare un messaggio all'entità che ha bisogno della notifica. Questo potrebbe essere realizzato in molti modi, ad esempio aggiungendo alla tabella desiderata una colonna con un'indicazione dell'entità a cui è necessario inviare la notifica delle modifiche o creando un join tra la tabella primaria e la seconda tabella che contiene le informazioni sull'entità per cui è necessaria la notifica.
Utilizzare una soluzione personalizzata a livello di applicazione che non si basa sulle notifiche delle query. Ad esempio, configurare una notifica affinché venga eseguita completamente da un'applicazione middleware che gestisca i dati monitorati in una raccolta di oggetti della memoria principale. L'applicazione consente di generare una notifica quando un oggetto viene modificato in modo da soddisfare i criteri relativi a una notifica.
Utilizzare Windows Server App Fabric Cache che supporta un meccanismo di notifiche delle modifiche basato su una cache dell'oggetto in memoria e sulle funzioni di callback che si registrano con gli oggetti.