Condividi tramite

Criteri di memorizzazione nella cache (cache ad accesso frequente e sporadico)

  • Articolo

Azure Esplora dati usa un sistema di cache dei dati multilivello per garantire prestazioni elevate delle query. I dati vengono archiviati in una risorsa di archiviazione affidabile, ad esempio Archiviazione BLOB di Azure, ma alcune parti vengono memorizzate nella cache nei nodi di elaborazione, nell'unità SSD o anche in RAM per un accesso più rapido.

Intelligence in tempo reale usa un sistema di cache dei dati multilivello per garantire prestazioni di query veloci. I dati vengono archiviati in una risorsa di archiviazione affidabile, ad esempio OneLake, ma alcune parti vengono memorizzate nella cache nei nodi di elaborazione, nelle unità SSD o anche in RAM per un accesso più rapido.

I criteri di memorizzazione nella cache consentono di scegliere quali dati devono essere memorizzati nella cache. È possibile distinguere tra cache dei dati ad accesso frequente e cache dei dati ad accesso sporadico impostando un criterio di memorizzazione nella cache sui dati ad accesso frequente. I dati ad accesso frequente vengono mantenuti nell'archiviazione SSD locale per prestazioni di query più veloci, mentre i dati ad accesso sporadico vengono archiviati in un archivio affidabile, che è più economico ma più lento per l'accesso.

La cache usa il 95% del disco SSD locale per i dati ad accesso frequente. Se lo spazio non è sufficiente, i dati più recenti vengono mantenuti preferibilmente nella cache. Il 5% rimanente viene usato per i dati non classificati come ad accesso frequente. Questa progettazione garantisce che le query che caricano molti dati ad accesso sporadico non rimuoveranno i dati ad accesso frequente dalla cache.

Le migliori prestazioni delle query vengono ottenute quando tutti i dati inseriti vengono memorizzati nella cache. Tuttavia, alcuni dati potrebbero non giustificare la spesa di essere mantenuti nella cache ad accesso frequente. Ad esempio, i record di log precedenti a cui si accede raramente potrebbero essere considerati meno cruciali. In questi casi, i team spesso scelgono di ridurre le prestazioni di query rispetto al pagamento per mantenere i dati ad accesso frequente.

Usare i comandi di gestione per modificare i criteri di memorizzazione nella cache a livello di database, tabella o vista materializzata.

Usare i comandi di gestione per modificare i criteri di memorizzazione nella cache a livello di cluster, database, tabella o vista materializzata.

Suggerimento

Il cluster è progettato per query ad hoc con set di risultati intermedi che rientrano nella RAM totale del cluster. Per i processi di grandi dimensioni, ad esempio map-reduce, può essere utile archiviare i risultati intermedi nell'archiviazione permanente. A tale scopo, creare un processo di esportazione continua. Questa funzionalità consente di eseguire query batch a esecuzione prolungata usando servizi come HDInsight o Azure Databricks.

Modalità di applicazione dei criteri di memorizzazione nella cache

Quando i dati vengono inseriti, il sistema tiene traccia della data e dell'ora dell'inserimento e dell'extent creato. Il valore di data e ora di inserimento dell'extent (o valore massimo, se un extent è stato compilato da più extent preesistenti), viene usato per valutare i criteri di memorizzazione nella cache.

Nota

È possibile specificare un valore per la data e l'ora di inserimento usando la proprietà creationTimedi inserimento . In questo caso, assicurarsi che la Lookback proprietà nei criteri di unione Extent effettivi della tabella sia allineata ai valori impostati per creationTime.

Per impostazione predefinita, i criteri effettivi sono null, il che significa che tutti i dati vengono considerati ad accesso frequente. Un null criterio a livello di tabella indica che i criteri verranno ereditati dal database. Un criterio nonnull a livello di tabella esegue l'override di un criterio a livello di database.

Definizione dell'ambito delle query nella cache ad accesso frequente

Quando si eseguono query, è possibile limitare l'ambito solo ai dati di query nella cache ad accesso frequente.

Nota

La definizione dell'ambito dei dati si applica solo alle entità che supportano i criteri di memorizzazione nella cache, ad esempio tabelle e viste materializzate. Viene ignorato per altre entità, ad esempio tabelle esterne e dati nell'archivio righe.

Esistono diverse possibilità di query:

  • Aggiungere una proprietà della richiesta client chiamata query_datascope alla query. Valori possibili: default, alle hotcache.
  • Usare un'istruzione set nel testo della query: set query_datascope='...'. I valori possibili sono uguali a per la proprietà della richiesta client.
  • Aggiungere un datascope=... testo immediatamente dopo un riferimento a una tabella nel corpo della query. I valori possibili sono all e hotcache.

Il default valore indica l'uso delle impostazioni predefinite del cluster, che determinano che la query deve coprire tutti i dati.

Se si verifica una discrepanza tra i diversi metodi, set ha la precedenza sulla proprietà della richiesta client. La specifica di un valore per un riferimento di tabella ha la precedenza su entrambi.

Nella query seguente, ad esempio, tutti i riferimenti a tabelle usano solo i dati della cache ad accesso frequente, ad eccezione del secondo riferimento a "T", con ambito per tutti i dati:

set query_datascope="hotcache";
T | union U | join (T datascope=all | where Timestamp < ago(365d)) on X

Memorizzazione dei criteri di memorizzazione nella cache e criteri di conservazione

I criteri di memorizzazione nella cache sono indipendenti dai criteri di conservazione:

  • I criteri di memorizzazione nella cache definiscono come classificare in ordine di priorità le risorse. Le query per i dati importanti sono più veloci.
  • I criteri di conservazione definiscono l'extent dei dati su cui è possibile eseguire query in una tabella o in un database (in particolare, SoftDeletePeriod).

Configurare questo criterio per ottenere un equilibrio ottimale tra costi e prestazioni, in base al modello di query previsto.

Esempio:

  • SoftDeletePeriod = 56d
  • hot cache policy = 28d

Nell'esempio, gli ultimi 28 giorni di dati saranno presenti nell'unità SSD del cluster e i 28 giorni aggiuntivi di dati verranno archiviati nell'archivio BLOB di Azure. È possibile eseguire query sui 56 giorni completi di dati.

Contenuto correlato