Condividi tramite

Cache integrata di Azure Cosmos DB - Panoramica

  • Articolo

SI APPLICA A: NoSQL

La cache integrata di Azure Cosmos DB è una cache in memoria che consente di garantire costi gestibili e bassa latenza man mano che aumenta il volume delle richieste. La cache integrata è facile da configurare e non è necessario dedicare tempo alla scrittura di codice personalizzato per invalidare la cache o alla gestione dell'infrastruttura back-end. La cache integrata usa il gateway dedicato all'interno dell'account Azure Cosmos DB. Quando si effettua il provisioning del gateway dedicato, è possibile scegliere il numero di nodi e le dimensioni del nodo in base al numero di core e alla memoria necessari per il carico di lavoro. Ogni nodo del gateway dedicato ha una cache integrata separata dalle altre.

Una cache integrata viene configurata automaticamente all'interno del gateway dedicato. La cache integrata ha due parti:

  • Una cache degli elementi per le letture di punti
  • Una cache della query per le query

La cache integrata è una cache di lettura/scrittura con un criterio di rimozione LRU (Least Recently Used). La cache degli elementi e le cache della query condividono la stessa capacità all'interno della cache integrata e i criteri di rimozione LRU si applicano a entrambi. I dati vengono rimossi dalla cache rigorosamente in base al momento in cui sono stati usati meno di recente, indipendentemente dal fatto che si tratti di una query o di lettura di punti. I dati memorizzati nella cache all'interno di ogni nodo dipendono dai dati scritti o letti di recente da quel nodo specifico. Se un elemento o una query viene memorizzato nella cache in un nodo, non viene necessariamente memorizzato nella cache negli altri.

Nota

Si desidera lasciare un feedback sulla cache integrata? Saremo lieti di riceverlo. È possibile condividere i feedback direttamente con il team di progettazione di Azure Cosmos DB: cosmoscachefeedback@microsoft.com

Carichi di lavoro che traggono vantaggio dalla cache integrata

L'obiettivo principale della cache integrata è ridurre i costi per i carichi di lavoro con un numero elevato di operazioni di lettura. La bassa latenza, sebbene utile, non è il vantaggio principale della cache integrata perché Azure Cosmos DB è già veloce senza memorizzazione nella cache.

Le letture dei punti e le query rivolte alle cache integrata hanno un addebito di UR pari a 0. I riscontri nella cache hanno un costo per operazione molto inferiore rispetto alle letture dal database back-end.

I carichi di lavoro che soddisfano le caratteristiche seguenti devono valutare se la cache integrata contribuisce a ridurre i costi:

  • Carichi di lavoro con intensa attività di lettura
  • Molte letture di punti ripetute su elementi di grandi dimensioni
  • Molte query di UR elevate ripetute
  • Chiave di partizione ad accesso frequente per le letture

Il fattore più importante nel risparmio previsto è il grado di ripetizione delle letture. Se il carico di lavoro esegue costantemente le stesse letture di punti o query entro un breve periodo di tempo, è un ottimo candidato per la cache integrata. Quando si usa la cache integrata per letture ripetute, si usano le UR solo per la prima lettura. Le letture successive instradate attraverso lo stesso nodo del gateway dedicato (all'interno della finestra MaxIntegratedCacheStaleness e se i dati non sono stati rimossi) non usano la velocità effettiva.

Alcuni carichi di lavoro non devono considerare la cache integrata, tra cui:

  • Carichi di lavoro con intensa attività di scrittura
  • Letture di punti o query ripetute raramente
  • Carichi di lavoro che leggono il feed di modifiche

Cache degli elementi

La cache degli elementi viene usata per le letture di punti (ricerche chiave/valore in base all'ID elemento e alla chiave di partizione).

Popolamento della cache degli elementi

  • Le nuove scritture, gli aggiornamenti e le eliminazioni vengono popolate automaticamente nella cache degli elementi del nodo in cui viene instradata la richiesta
  • Gli elementi delle richieste di lettura di punti in cui l'elemento non è già presente nella cache (mancato riscontro nella cache) del nodo in cui viene indirizzata la richiesta vengono aggiunti alla cache degli elementi
  • Le richieste di lettura di più elementi, ad esempio ReadMany, popolano la cache della query come set anziché la cache degli elementi come singoli elementi
  • Le richieste che fanno parte di un batch transazionale o in modalità bulk non popolano la cache degli elementi

Invalidazione e rimozione della cache degli elementi

Poiché ogni nodo ha una cache indipendente, è possibile che gli elementi vengano invalidati o rimossi dalla cache di un nodo e non dagli altri. Gli elementi nella cache di un determinato nodo vengono invalidati e rimossi in base ai criteri seguenti:

  • Aggiornamento o eliminazione di elementi
  • Utilizzato meno di recente (LRU)
  • Tempo di conservazione dei dati della cache (in altre parole, MaxIntegratedCacheStaleness)

Cache della query

La cache della query viene usata per memorizzare nella cache le query. La cache della query trasforma una query in una ricerca chiave/valore in cui la chiave è il testo della query e il valore sono i risultati della query. La cache integrata non ha un motore di query, ma archivia solo la ricerca chiave/valore per ogni query. I risultati delle query vengono archiviati come set e la cache non tiene traccia dei singoli elementi. Un determinato elemento può essere archiviato nella cache della query più volte, se compare nel set di risultati di più query. Gli aggiornamenti agli elementi sottostanti non si riflettono nei risultati della query, a meno che non venga raggiunta l’obsolescenza massima della cache integrata per la query e la query non venga servita dal database back-end.

Popolamento della cache della query

  • Se la cache non ha un risultato per la query (mancato riscontro nella cache) nel nodo in cui è stata instradata, la query viene inviata al back-end. Dopo l'esecuzione della query, la cache archivierà i risultati della query
  • Le query con la stessa forma ma con parametri o opzioni di richiesta diverse che influiscono sui risultati (es. max conteggio elementi) vengono archiviate come coppia chiave/valore
  • Le richieste di lettura di più elementi, ad esempio ReadMany, popolano la cache della query. I risultati di ReadMany vengono archiviati come set mentre le richieste con input diversi vengono archiviate come coppia chiave/valore

Rimozione della cache della query

La rimozione della cache della query si basa sul nodo in cui è stata instradata la richiesta. È possibile che le query vengano rimosse o aggiornate in un nodo e non in altri.

  • Utilizzato meno di recente (LRU)
  • Tempo di conservazione dei dati della cache (in altre parole, MaxIntegratedCacheStaleness)

Utilizzo della cache della query

Non è necessario codice speciale quando si lavora con la cache della query, anche se le query hanno più pagine di risultati. Le procedure consigliate e il codice per la paginazione delle query sono gli stessi sia che la query sia rivolta alla cache integrata, sia che venga eseguita nel motore di query back-end.

La cache della query memorizza automaticamente nella cache i token di continuazione delle query, dove applicabile. Se si dispone di una query con più pagine di risultati, tutte le pagine archiviate nella cache integrata hanno un addebito di UR pari a 0. Se le pagine successive dei risultati delle query richiedono l'esecuzione back-end, avranno un token di continuazione della pagina precedente in modo da evitare la duplicazione del lavoro precedente.

Importante

Le istanze della cache integrata all'interno dei diversi nodi gateway dedicati hanno cache indipendenti l'una dall'altra. Se i dati vengono memorizzati nella cache all'interno di un nodo, non vengono necessariamente memorizzati nella cache negli altri. Non è garantito che più pagine della stessa query vengano instradate allo stesso nodo del gateway dedicato.

Coerenza della cache integrata

La cache integrata supporta le richieste di lettura solo con la coerenza di sessione o finale. Se una lettura ha prefisso coerente, decadimento ristretto o coerenza assoluta, ignora la cache integrata e viene servita dal back-end.

Il modo più semplice per configurare la coerenza di sessione o finale per tutte le letture consiste nell'impostarla a livello di account. Tuttavia, se si desidera che alcune letture abbiano una coerenza specifica, è possibile configurare la coerenza anche a livello di richiesta.

Nota

Le richieste di scrittura con altre coerenza popolano ancora la cache, ma per leggere dalla cache la richiesta deve avere una coerenza di sessione o finale.

Coerenza di sessione

La coerenza di sessione è il livello di coerenza più usato sia per account a singola area che per quelli Azure Cosmos DB distribuiti a livello globale. Con la coerenza di sessione, le sessioni client singole possono leggere le proprie scritture. Le letture con coerenza di sessione che non hanno un token di sessione corrispondente comportano addebiti per UR. Ciò include la prima richiesta di un determinato elemento o query all'avvio o al riavvio dell'applicazione client, a meno che non si passi in modo esplicito un token di sessione valido. I client esterni alla sessione che eseguono scritture vedranno la coerenza finale quando useranno la cache integrata.

MaxIntegratedCacheStaleness

MaxIntegratedCacheStaleness è il massimo decadimento accettabile per le letture di punti e le query memorizzate nella cache, indipendentemente dalla coerenza selezionata. MaxIntegratedCacheStaleness è configurabile a livello di richiesta. Se, ad esempio, si imposta un MaxIntegratedCacheStaleness di 2 ore, la richiesta restituirà i dati memorizzati nella cache solo se i dati hanno meno di 2 ore. Per aumentare la probabilità di letture ripetute che usano la cache integrata, è necessario impostare il valore MaxIntegratedCacheStaleness massimo consentito dai requisiti aziendali.

L'oggetto MaxIntegratedCacheStaleness, se configurato in una richiesta che finisce per popolare la cache, non influisce sulla durata della memorizzazione nella cache della richiesta. MaxIntegratedCacheStaleness applica la coerenza quando si tenta di leggere i dati memorizzati nella cache. Non esiste un'impostazione di conservazione TTL o cache globale, pertanto i dati vengono rimossi dalla cache solo se la cache integrata è piena o viene eseguita una nuova lettura con una durata inferiore MaxIntegratedCacheStaleness a quella della voce memorizzata nella cache corrente.

Si tratta di un miglioramento rispetto al funzionamento della maggior parte delle cache e consente le altre personalizzazioni seguenti:

  • È possibile impostare requisiti di decadimento diversi per ogni lettura di punti o query
  • Client diversi, anche se eseguono la stessa lettura di punti o query, possono configurare valori MaxIntegratedCacheStaleness diversi
  • Se si vuole modificare la coerenza di lettura per i dati memorizzati nella cache, la modifica di MaxIntegratedCacheStaleness ha un effetto immediato sulla coerenza di lettura

Nota

Il valore minimo MaxIntegratedCacheStaleness è 0 e il valore massimo è 10 anni. Quando non è configurato in modo esplicito, il valore MaxIntegratedCacheStaleness predefinito è 5 minuti.

Per comprendere meglio il parametro MaxIntegratedCacheStaleness, considerare l'esempio seguente:

Ora Richiedi Risposta
t = 0 sec Eseguire query A con MaxIntegratedCacheStaleness = 30 secondi Restituire i risultati dal database back-end (normali addebiti UR) e popolare la cache
t = 0 sec Eseguire query B con MaxIntegratedCacheStaleness = 60 secondi Restituire i risultati dal database back-end (normali addebiti UR) e popolare la cache
t = 20 sec Eseguire query A con MaxIntegratedCacheStaleness = 30 secondi Restituire i risultati dalla cache integrata (addebito di 0 UR)
t = 20 sec Eseguire query B con MaxIntegratedCacheStaleness = 60 secondi Restituire i risultati dalla cache integrata (addebito di 0 UR)
t = 40 sec Eseguire query A con MaxIntegratedCacheStaleness = 30 secondi Restituire i risultati dal database back-end (normali addebiti UR) e aggiornare la cache
t = 40 sec Eseguire query B con MaxIntegratedCacheStaleness = 60 secondi Restituire i risultati dalla cache integrata (addebito di 0 UR)
t = 50 sec Eseguire query B con MaxIntegratedCacheStaleness = 20 secondi Restituire i risultati dal database back-end (normali addebiti UR) e aggiornare la cache

Informazioni su come configurare MaxIntegratedCacheStaleness.

Ignorare la cache integrata

La cache integrata ha una capacità di archiviazione limitata, determinata dallo SKU del gateway dedicato di cui è stato effettuato il provisioning. Per impostazione predefinita, tutte le richieste provenienti dai client configurati con la stringa di connessione del gateway dedicato passano attraverso la cache integrata e occupano spazio nella cache. È possibile controllare quali elementi e query vengono memorizzati nella cache con l'opzione Ignora la richiesta di cache integrata. Questa opzione di richiesta è utile per le operazioni di scrittura di elementi o le richieste di lettura che non devono essere ripetute di frequente. Ignorare la cache integrata per gli elementi con accesso poco frequente consente di risparmiare spazio nella cache per gli elementi con più ripetizioni, aumentando il potenziale di risparmio delle UR e riducendo le eliminazioni. Le richieste che ignorano la cache vengono comunque instradate tramite il gateway dedicato. Queste richieste vengono gestite dal back-end e dalle UR di costo.

Informazioni su come ignorare la cache integrata.

Metrica

È utile monitorare alcune metriche chiave DedicatedGateway e IntegratedCache per la cache integrata. Per informazioni su queste metriche, vedere Metriche supportate per Microsoft.DocumentDB/DatabaseAccounts.

Tutte le metriche esistenti sono disponibili, per impostazione predefinita, nelle Metriche del portale di Azure (non nelle Metriche classiche):

Screenshot del portale di Azure che mostra la posizione delle metriche della cache integrata.

Le metriche sono una media, un massimo o una somma di tutti i nodi del gateway dedicato. Ad esempio, se si effettua il provisioning di un cluster gateway dedicato con cinque nodi, le metriche riflettono il valore aggregato in tutti e cinque i nodi. Non è possibile determinare i valori delle metriche per ogni singolo nodo.

Risoluzione dei problemi comuni

Gli esempi seguenti illustrano come eseguire il debug di alcuni scenari comuni:

Non è possibile stabilire se l'applicazione usa il gateway dedicato

Vedere DedicatedGatewayRequests. Questa metrica include tutte le richieste che usano il gateway dedicato, indipendentemente dal fatto che abbiano raggiunto la cache integrata. Se l'applicazione usa il gateway standard o la modalità diretta con la stringa di connessione originale, non verrà visualizzato un messaggio di errore, ma DedicatedGatewayRequests sarà zero. Se l'applicazione usa la modalità diretta con la stringa di connessione gateway dedicata, è comunque possibile che vengano visualizzati alcuni DedicatedGatewayRequests.

Non è possibile stabilire se le richieste stanno raggiungendo la cache integrata

Controllare IntegratedCacheItemHitRate e IntegratedCacheQueryHitRate. Se entrambi questi valori sono zero, le richieste non raggiungono la cache integrata. Verificare di usare la stringa di connessione del gateway dedicato, di connettersi con la modalità gateway e di utilizzare della coerenza di sessione o finale.

Si vuole capire se il gateway dedicato è troppo piccolo

Controllare IntegratedCacheItemHitRate e IntegratedCacheQueryHitRate. Valori elevati (ad esempio, superiori a 0,7-0,8) indicano che il gateway dedicato è sufficientemente grande.

Se IntegratedCacheItemHitRate o IntegratedCacheQueryHitRate è basso, esaminare IntegratedCacheEvictedEntriesSize. Se IntegratedCacheEvictedEntriesSize è alto, può significare che sarebbe utile un gateway dedicato di dimensioni maggiori. È possibile sperimentare aumentando le dimensioni del gateway dedicato e confrontando i nuovi valori IntegratedCacheItemHitRate e IntegratedCacheQueryHitRate. Se un gateway dedicato di dimensioni maggiori non migliora IntegratedCacheItemHitRate o IntegratedCacheQueryHitRate, è possibile che le letture non si ripetano abbastanza perché la cache integrata sia efficace.

Si vuole capire se il gateway dedicato è troppo grande

È più difficile misurare se un gateway dedicato è troppo grande che misurare se un gateway dedicato è troppo piccolo. In generale, è consigliabile iniziare da piccole dimensioni del gateway dedicato e aumentarle lentamente fino a quando non si interrompe il miglioramento di IntegratedCacheItemHitRate e IntegratedCacheQueryHitRate. In alcuni casi, solo una delle due metriche di riscontro nella cache sarà importante, non entrambe. Ad esempio, se il carico di lavoro è principalmente una query, anziché le letture di punti, IntegratedCacheQueryHitRate è molto più importante di IntegratedCacheItemHitRate.

Se la maggior parte dei dati viene rimossa dalla cache a causa del superamento di MaxIntegratedCacheStaleness, anziché LRU, la cache potrebbe essere maggiore del necessario. Se IntegratedCacheItemExpirationCount e IntegratedCacheQueryExpirationCount combinati sono quasi grandi come IntegratedCacheEvictedEntriesSize, è possibile sperimentare una dimensione del gateway dedicato inferiore e confrontare le prestazioni.

Si vuole capire se è necessario aggiungere altri nodi del gateway dedicato

In alcuni casi, se la latenza è inaspettatamente elevata, potrebbero essere necessari più nodi del gateway dedicato anziché nodi più grandi. Controllare DedicatedGatewayCPUUsage e DedicatedGatewayMemoryUsage per determinare se l'aggiunta di più nodi del gateway dedicato riduce la latenza. È consigliabile tenere presente che, poiché tutte le istanze della cache integrata sono indipendenti l'una dall'altra, l'aggiunta di altri nodi del gateway dedicato non ridurrà IntegratedCacheEvictedEntriesSize. L'aggiunta di altri nodi migliorerà tuttavia il volume di richieste che il cluster gateway dedicato può gestire.

Passaggi successivi