Come scalare le app EF Core a prestazioni estreme?
Webinar registrato
Di Ron Hussain e Zack Khan
EF Core viene sempre più utilizzato in applicazioni server .NET con transazioni elevate (ASP.NET, servizi Web, microservizi e altre app server). Inoltre, queste applicazioni devono affrontare colli di bottiglia della scalabilità dei database che possono eliminare utilizzando la cache distribuita all'interno di EF Core.
- Introduzione alle nuove funzionalità di EF Core (modello, query, salvataggio dei dati)
- In che modo la cache distribuita risolve i colli di bottiglia del database EF Core
- Vari modi di usare la cache distribuita nelle app EF Core
- Dettagli sull'uso dei metodi di estensione EF Core per la memorizzazione nella cache
- Gestione della memorizzazione nella cache di raccolte e relazioni di dati
Entity Framework Core o EF Core è il nuovo motore di mapping relazionale a oggetti multipiattaforma e leggero di Microsoft per .NET che elimina la necessità della maggior parte del codice di accesso ai dati che gli sviluppatori scrivono altrimenti. Simile a .NET Core, EF Core è anche multipiattaforma, il che significa che puoi usarlo su Windows, Linux, Mac e sta diventando molto popolare nella comunità degli sviluppatori.
Come ridimensionare la tua applicazione per ottenere prestazioni estreme e una crescita lineare nella capacità di gestione delle richieste? Quindi, puoi ridimensionare la tua app, utilizzando l'applicazione Entity Framework Core NCache metodi di estensione. Quindi, ne abbiamo messi in fila alcuni che puoi utilizzare. Diversi scenari che dipingerò e poi sulla base di quelli, introdurrò NCache metodi di estensione e funzionalità di memorizzazione nella cache degli oggetti che è possibile utilizzare all'interno di una tipica applicazione Entity Framework Core nel proprio ambiente.
Che cos'è Entity Framework/EF Core?
In primo luogo, parlerei di Entity Framework e Entity Framework Core in generale. Sono abbastanza sicuro che tutti conoscano EF ed EF Core, ma solo per completezza, per creare alcuni dettagli introduttivi.
Entity Framework è un ORM che puoi utilizzare per .NET e con EF Core puoi usarlo anche per .NET e per .NET Core. Entity Framework semplifica la programmazione del database. Puoi lavorare su un modello a oggetti concettuale. Quindi, non è necessario lavorare direttamente con il modello di dati e semplifica la programmazione complessiva dell'accesso ai dati. Non è necessario scrivere da soli il codice persistente. Potrebbe generare molta interazione tra il livello dell'oggetto all'interno dell'applicazione e il modello di dati che hai e l'utilizzo dell'accesso al database generato da Entity Framework Core.
È molto popolare per il tuo .NET e .NET Core applicazioni. Puoi usarlo in qualsiasi tipo di applicazione, potrebbe essere un'applicazione web, potrebbe essere una tipica applicazione server, .NET o .NET Core servizi Web, casi d'uso IOT o qualsiasi altra applicazione server possono utilizzarlo per la sua popolarità e anche per la sua facilità d'uso. È molto facile da configurare e puoi iniziare con esso.
Entity Framework Core è una nuova variante. Questa è la nuova direzione che sta prendendo Microsoft, prima di tutto open source, multipiattaforma. Quindi, puoi eseguire un'applicazione che sta utilizzando .NET Core o conosci .NET. Può funzionare su Windows con .NET e con .NET Core può essere eseguito su Windows così come su ambienti Linux e simili Entità Framework Core segue l'esempio, giusto? Quindi, ti consente di funzionare su Windows e su ambienti Linux se questo è un requisito ed è molto leggero e di natura modulare. Il che essenzialmente significa che non devi passare attraverso tutti i componenti all'interno di Entity Framework che avevi. Con EF Core puoi lavorare con il componente di cui hai bisogno. Puoi ottenere il pacchetto NuGet solo per questo e in base a ciò puoi creare complessità incrementale all'interno della tua applicazione.
Quindi, se hai bisogno, sai, gestisci scenari complessi all'interno della tua applicazione per quella materia. E, per di più, è super veloce grazie a .NET Core c'è anche un focus specifico o un lato delle prestazioni. Quindi, Entity Framework Core è stato progettato secondo le stesse linee guida in cui le prestazioni sono uno dei fattori chiave che potresti raggiungere.
Diagramma architettonico di Entity Framework
Quindi, ecco un diagramma architettonico per Entity Framework Core.
Ho trovato un diagramma Entity Framework che si applica ancora, molte cose si applicano ancora anche all'architettura Entity Framework Core. Questo è da MSDN. Con EF Core hai il provider di dati ADO.NET. Userò SQL Server come esempio di origine dati e quindi avrai il lettore di dati Entity Client che crea alberi di comando, scenario di accesso ai dati e quindi hai servizi di oggetti e sul lato dell'applicazione lavori con Entity Query SQL o LINQ alle Entità. Quindi, ancora una volta lavori con il modello a oggetti e dietro le quinte Entity Framework Core si prende cura di tutti gli altri dettagli.
C'è un comando che esegui per generare la mappatura e il modello in fase di esecuzione, quindi il modello concettuale, EDMX, tutti quei file di mappatura, si sono sbarazzati di quelli all'interno di Entity Framework Core. Quindi, è molto facile da configurare di nuovo. Ancora una volta, è modulare. Quindi, puoi introdurre i pacchetti NuGet e puoi creare un'applicazione Entity Framework Core molto semplice in pochi minuti.
Che cos'è la scalabilità?
Successivamente, parlerò di scalabilità, questo è un altro concetto che volevo evidenziare. Perché è necessaria la memorizzazione nella cache in un'applicazione che utilizza Entity Framework Core? Prima di tutto, c'è un concetto di scalabilità. Questa è un'ottima funzionalità all'interno di un'applicazione, in cui puoi ottenere prestazioni elevate dell'applicazione e anche con carichi di picco, giusto? Quindi, se sei in grado di avere una bassa latenza e la più bassa latenza possibile e mantieni quella bassa latenza con un carico utente basso, diciamo da cinque a dieci utenti e se hai un'architettura dell'applicazione progettata in modo tale da poter gestire lo stesso tipo di bassa latenza con un'enorme quantità di richieste degli utenti caricata, quindi quell'applicazione verrebbe classificata come un'applicazione molto scalabile.
Inoltre, la scalabilità lineare è un ulteriore concetto associato in cui è possibile aggiungere sempre più server e distribuire il carico e distribuendo il carico su più server, più server aumenterebbero effettivamente la capacità di gestione delle richieste e tale aumento dovrebbe crescere in modo lineare. Quindi, se hai un'applicazione che sta aumentando la sua capacità man mano che aggiungi più server e che fa un banner di aumento lineare che sarebbe classificato come un'applicazione scalabile linearmente.
Quali sono le applicazioni che necessitano di scalabilità?
Quindi, in genere applicazioni che sono di natura ad alta transazione come ASP.NET o ASP.NET Core app Web, servizi Web, IOT, applicazioni per big data o qualsiasi altro .NET generico o .NET Core le applicazioni che utilizzano Entity Framework core richiedono un'elevata scalabilità, giusto? Pertanto, hanno bisogno di un elevato carico transazionale di capacità di gestione all'interno della loro architettura.
Dov'è esattamente il problema della scalabilità?
Allora, dov'è esattamente il problema? Perché hai bisogno di un sistema di memorizzazione nella cache per superare questo problema? È sempre possibile creare una Web Farm e un'App Farm in cui l'applicazione Entity Framework Core può scalare in modo lineare su se stessa creando una Web Farm o un'App Farm. Puoi mettere un sistema di bilanciamento del carico davanti. Quindi, questo non è il principale punto di preoccupazione. Il livello dell'applicazione può sempre essere ridimensionato. Ecco come un Entity Framework Core e qualsiasi tipico .NET o .NET Core le applicazioni sono progettate. Dove puoi instradare le richieste a più server e continuare a usarle in combinazione l'una con l'altra.
Il problema principale è il collo di bottiglia dell'archiviazione dei dati. In genere, se si tratta di un database relazionale, questo è l'esempio che stiamo usando. I database sono in genere un'unica fonte per l'archiviazione di tutti i dati. Sono molto buoni per la conservazione. È qualcosa in cui sono i migliori. Ma quando si tratta di gestire una quantità estrema di carichi di richieste, ad esempio, si ha molto carico di dati transazionali e di riferimento provenienti dalle applicazioni, il database non è progettato per gestire quella maggiore quantità di carico di richieste. Funzionerebbe bene con carichi utente bassi, ma quando inizia a consumare capacità sul lato CPU, sul lato memoria e poi c'è un tunnel DBMS in cui vengono instradate tutte le richieste. È probabile che l'archiviazione dei dati diventi un collo di bottiglia della scalabilità. Ti darebbe un degrado delle prestazioni, in cui inserisce le richieste di coda che vengono generate in fase di esecuzione. Quindi, non è possibile aggiungere un altro server di database.
Prima di tutto, è costoso iniziare e quindi non è possibile utilizzare due server in combinazione l'uno con l'altro. Quindi, non si sommerebbe al valore delle prestazioni, degraderebbe le tue prestazioni e ciò influirebbe anche sull'esperienza dell'utente finale e ciò a sua volta può avere un impatto anche sulla tua attività. Perché, se le tue applicazioni sono lente nelle prestazioni, molti utenti non apprezzerebbero quel comportamento lento o lento dalla tua applicazione. Pertanto, le applicazioni richiedono sempre una bassa latenza e un throughput elevato e il mantenimento di un throughput elevato comporta un pedaggio di perdita di prestazioni ed è ciò che i database tendono a vedere dove semplicemente rallentano le applicazioni o tendono a soffocare completamente nella maggior parte dei casi anche.
La Soluzione
In questa sezione parleremo di come affrontare questo problema. La soluzione è molto semplice. Puoi usare sistema di cache distribuito da NCache. È molto veloce perché è in memoria. È molto scalabile perché non è solo un'unica fonte. Puoi avere tutti i server di cui hai bisogno, aggiunti nel cluster di cache e quei server in un cluster di cache funzionano in combinazione l'uno con l'altro. Puoi distribuire i tuoi dati e quindi distribuire il carico di gestione delle richieste e aggiungendo più server ottieni anche una maggiore scalabilità dal sistema. Non è un sostituto dei database relazionali convenzionali. Si usa una cache distribuita all'interno dell'applicazione EF Core in combinazione con un database. Quindi, puoi memorizzare nella cache i dati a cui si accede più facilmente, i tuoi dati di riferimento o anche alcuni dei tuoi dati transazionali.
E parlerò di come gestire diversi scenari di memorizzazione nella cache, strategie di memorizzazione nella cache che puoi utilizzare all'interno della tua applicazione.
Architettura di distribuzione
Ecco l'architettura di distribuzione che chiarirebbe ulteriormente alcune cose perché è un'opzione migliore rispetto ai database relazionali.
Prima di tutto, la cache distribuita si trova tra l'applicazione e il livello del database. E, dicendo nel mezzo, è essenzialmente che la tua applicazione userebbe prima la cache se trova dati qui dovrebbe tornare se non trova dati qui dovrebbe solo andare al database di back-end, giusto? Quindi, in una posizione logica, si trova tra la tua applicazione e il database.
Per quanto riguarda la distribuzione puoi avere la tua applicazione distribuita su VM, su box fisici, on-prem o in Cloud. NCache è supportato su Microsoft Azure, così come su AWS sotto forma di immagine preconfigurata o qualsiasi altro cloud può utilizzare il nostro installer che può essere scaricato dal nostro sito Web e quindi è possibile iniziare con l'installazione, che è molto facile da impostare. NCache può essere sul proprio livello rispettivo, per server dedicati separati NCache oppure può funzionare sulle stesse scatole. Se disponi di caselle in cui è distribuita la tua applicazione, puoi eseguire la distribuzione NCache anche sullo stesso livello. Ti consigliamo di avere caselle separate e puoi aggiungere da due a tre server per iniziare e quindi puoi aggiungere sempre più server in base ai tuoi requisiti di gestione delle richieste.
Se hai bisogno di gestire, diciamo, 10,000 utenti e il caricamento delle loro richieste associate, puoi eseguire alcuni test e puoi vedere di quanti server hai bisogno. In generale, sulla base di recenti test, siamo stati in grado di raggiungere due milioni di richieste al secondo con appena 4-5 NCache server, giusto? Quindi, puoi vedere quanti server sono necessari per gestire i requisiti di carico dell'applicazione. Solo prerequisito per NCache è .NET o .NET Core. Funziona su Windows, Windows Nano e su server Linux. Allo stesso modo, le tue applicazioni possono trovarsi sulla piattaforma Windows o sulla piattaforma Linux.
E ci sono anche alcune potenti funzionalità di sincronizzazione del database. Come ho detto prima, non è un sostituto dei database convenzionali. Usa il tuo database, viene utilizzato insieme al tuo database, giusto? Quindi, alcuni dati sarebbero cache ma tutti i tuoi dati esisterebbero sempre nel tuo archivio permanente che è il tuo database relazionale. E tra un po' parlerò di come procedere con la memorizzazione nella cache.
3 Casi d'uso di cache distribuita comunemente usati
Ecco alcuni casi d'uso comuni. Casi d'uso generali per la cache distribuita e il più importante è la memorizzazione nella cache dei dati dell'app. Abbiamo Entity Framework Core qui.
Memorizzazione nella cache dei dati dell'applicazione
Quindi, il primo caso d'uso che è il nostro caso d'uso più comune è il nostro caso d'uso di memorizzazione nella cache dei dati dell'app. In questo, in genere si memorizzano nella cache i dati che appartengono al database. La motivazione qui è che risparmi il più possibile costosi viaggi del database e i vantaggi che ottieni sono prestazioni elevate per il recupero dei dati. Poiché i database sono lenti rispetto all'accesso in memoria, quindi è in memoria, quindi è super veloce e quindi hai più server che ospitano e soddisfano la tua richiesta dalla tua applicazione. Quindi, ottieni maggiore scalabilità, maggiore throughput dal sistema e pur mantenendo una bassa latenza data per la cache distribuita e nella maggior parte dei casi è altamente disponibile e affidabile anche in base alla topologia che hai scelto, a differenza dei database che potrebbero non essere replicati su altri server.
Con la memorizzazione nella cache dei dati dell'app puoi memorizzare nella cache quasi tutto. Puoi utilizzare le API dirette. Puoi memorizzare nella cache i tuoi oggetti di dominio, raccolte, set di dati, singoli elementi, risultati, tutti i dati che desideri memorizzare nella cache e hai nuovamente bisogno di quei dati dovresti considerare di utilizzare il nostro caching degli oggetti e con Entity Framework Core, ancora una volta puoi utilizzare API o estensioni dirette metodi che ti mostrerò.
Cache di sessione ASP.NET e SignalR Backplane
Poi un altro caso d'uso per NCache è ASP.NET e ASP.NET Core memorizzazione nella cache specifica. Abbiamo la nostra cache di sessione. Cache di sessione in ASP.NET Core è tramite IDistributedCache così come al nostro NCache Anche il provider di sessioni. Quindi, questa è la seconda opzione e poi abbiamo SignalR Backplane. Questa è un'altra opzione che puoi utilizzare. Se si dispone di un'applicazione SignalR è possibile utilizzare NCache come backplane. Anche questa è un'opzione senza modifica del codice e quindi abbiamo la memorizzazione nella cache delle risposte, lo stato di visualizzazione e la memorizzazione nella cache dell'output. Quindi, queste sono tutte le funzionalità specifiche per ASP.NET e in aggiunta a questo puoi anche utilizzare la memorizzazione nella cache dei dati dell'app all'interno della tua applicazione web, se necessario.
Messaggistica Pub/Sub e query continue
E poi, abbiamo la potente messaggistica Pub/Sub e gli eventi di query continue o direi la messaggistica Pub/Sub e gli eventi. Puoi usare NCache come piattaforma di messaggistica, in cui più applicazioni sono connesse e tali applicazioni possono comunicare tra loro utilizzando la nostra messaggistica Pub/Sub. Un'applicazione può pubblicare messaggi su NCache, che funge da canale di comunicazione. Ha un concetto di argomenti e quindi queste applicazioni per abbonati possono ricevere quel messaggio se sono collegate a quell'argomento. Pertanto, possono coordinarsi tra loro condividendo dati e messaggi personalizzati, se necessario. E possiamo costruire sistemi di social media. Puoi avere un sistema di chat. Puoi avere classifiche. È possibile utilizzarlo in qualsiasi tipo di settore in base alle esigenze, in cui è necessario disporre di diversi componenti dell'applicazione coordinati tra loro.
Comunicazione tra microservizi
I microservizi sono un altro caso d'uso, in cui è necessario disporre di applicazioni di microservizi serverless, interagire tra loro e loro possono utilizzare NCache per le loro esigenze di comunicazione e poi abbiamo anche Continuous Query Events. Eventi regolari in cui i tuoi dati vengono aggiunti, aggiornati o rimossi. Invece di inviare eventi all'applicazione, NCache può inviare eventi alle tue applicazioni in base alle modifiche dei dati e questo potrebbe essere su tutti gli elementi o su elementi selettivi o in base alla Query Continua in cui si mappa un set di dati in NCache ed NCache invia solo eventi per quel set di dati specificato.
C'è anche un quarto caso d'uso. Abbiamo la funzione di ricerca full-text. È molto comune nelle applicazioni di e-commerce. Insieme a NCache abbiamo implementato l'API Lucene .NET. Quindi, se sei interessato alla funzione di ricerca full-text, NCache è completamente attrezzato anche con quello.
Memorizzazione nella cache dei dati dell'app in EF Core
Parliamo di come useresti la memorizzazione nella cache in una tipica applicazione Entity Framework Core.
Configurazione dell'applicazione di esempio
Quindi, prima di tutto, ho questa applicazione. Applicazione di esempio allineata proprio qui. È uno degli esempi che vengono installati con NCache anche. Quindi, se vai su C:\Programmi\NCache\, questi campioni sono disponibili qui.
.NET e .NET Core i campioni sono posizionati separatamente. Quindi, io andrei avanti .NET Core e Entry Framework, abbiamo un esempio di EF Core proprio qui. Quindi, questo è il campione che sto usando.
L'ho leggermente modificato per dimostrare alcuni di questi scenari che ho intenzione di presentare in questo webinar. Altrimenti fa il lavoro di base per il tuo POC. Giusto, quindi, questo è il campione. La prossima cosa che farei è accedere al nostro ambiente demo e iniziare creando un cluster di cache per te in modo da utilizzare effettivamente un cluster di cache e riprenderlo da lì.
Crea una cache raggruppata
Quindi, per la creazione della cache abbiamo il nostro strumento di gestione web attivo e funzionante. Ne creerò uno velocemente. Quindi, andiamo avanti e aggiungiamo una cache in cluster. Chiamiamolo democache. Aggiungerò alcuni numeri interi, democache111. A proposito, puoi mantenere il formato JSON o binario, per quanto riguarda la serializzazione. Ecco qua. Quindi, puoi avere il formato di serializzazione binario o JSON. Andrò avanti con Binary, perché questa è l'opzione predefinita. Ci sono quattro topologie di memorizzazione nella cache tra cui puoi scegliere e abbiamo altri webinar come NCache architetture che sono specificamente mirate, sai, a spiegare NCache architettura. Quindi, andrò avanti con Partitioned Replica Cache perché funziona molto bene per le letture, molto bene per le scritture ed è super scalabile per la capacità delle richieste di lettura e scrittura, se continui ad aggiungere più server ed è dotato anche di repliche , quindi non ci sono tempi di inattività o perdita di dati anche per la tua applicazione.
Quindi, manterrei tutto semplice, predefinito. Replica asincrona tra la partizione attiva e il relativo backup. Quindi, sceglierò quello, è più veloce. Dimensioni del cluster di cache e qui ho specificato i server che ospiteranno il mio cluster di cache. Come ho detto, creerò rapidamente una cache perché il nostro obiettivo principale è Entity Framework Core. Altrimenti, nei nostri webinar regolari NCache architettura o ridimensionamento delle applicazioni Azure con NCache, quei webinar parlavano di tutte queste funzionalità in grande dettaglio. Quindi, in questo particolare webinar, andrò avanti e creerò rapidamente una cache. Bene, quindi, specificherei la porta predefinita TCP/IP e avvierei e avvierei automaticamente questa cache in modo che si avvii automaticamente al riavvio del server. Quindi, è praticamente tutto.
Simula lo stress e monitora le statistiche della cache
Per quanto riguarda le configurazioni della cache, devi solo seguire questa procedura guidata e ciò creerebbe una cache su più server. Penso che sia iniziato anche io. Aprirei la finestra delle statistiche e poi aprirei NCache monitor window che è un altro strumento che viene installato con NCache. Attualmente non ci sono attività ma posso andare avanti ed eseguire un'applicazione dello strumento di stress test. Si chiama test stress tool e simulerebbe alcune attività fittizie, carico fittizio sul mio cluster di cache. Giusto per verificare che tutto sia stato configurato correttamente. Giusto, quindi, puoi vedere, sai, giusto, da mille a millecinquecento richieste al secondo dal server uno così come dal server due. Quindi, in totale gestisce circa tremila richieste al secondo e puoi rivedere la latenza. Abbiamo una latenza operativa media di microsecondi per cache molto minima. Penso che sia una via di mezzo, tra i quattro e i cinque microsecondi.
Quindi, questo grafico si aggiornerebbe e l'unità diminuirebbe. Una volta che, sai, aggiungi un po 'più di carico. Andiamo davvero avanti e facciamolo. Destra. Quindi, ho un'altra istanza in esecuzione. Solo per mostrarti che ora dovrebbe mostrare il valore aumentato proprio qui, ecco fatto. Quindi, abbiamo circa, in precedenza gestiva circa millecinquecento ricerche al secondo per ogni server. Ora è tra le duemila e le tremila richieste al secondo da parte di ciascun server e puoi vedere una media di microsecondi per operazione di cache da circa cinquanta a sessanta microsecondi per operazione. Questo è un enorme guadagno in termini di prestazioni. Considerando che le tue applicazioni non vengono esaurite o che i server non vengono affatto esauriti. Quindi, puoi aspettarti risposte inferiori al millisecondo o al microsecondo dalle tue applicazioni durante l'utilizzo NCache. Quindi, il nostro ambiente è configurato. Tutto è impostato. Penso che siamo a posto. Consentitemi di interrompere questi test e andiamo avanti e creiamo, rivediamo la nostra applicazione di esempio che parla di scenari di memorizzazione nella cache.
Quali entità EF Core memorizzare nella cache?
Parliamo prima di tutto di come eseguire la memorizzazione nella cache all'interno di Entity Framework Core. Quali entità EF Core memorizzare nella cache? Hai due opzioni, in genere. Potresti avere un'entità singola o un risultato della query, che è una raccolta di entità, giusto? Entità singola restituita o potrebbe essere una raccolta. L'entità singola viene archiviata così com'è. La raccolta può essere archiviata come un singolo elemento o ogni elemento della raccolta può anche essere aggiunto individualmente nella cache e parliamo di come procedere.
Opzioni di memorizzazione nella cache delle entità di EF Core
Direct NCache API. Ci sono due approcci. Prima di tutto, puoi usare NCache API direttamente, giusto? Quindi, è qualcosa che puoi usare anche in Open Source, Enterprise o Professional. E poi abbiamo Entity Framework Core Extension Methods su cui dedicherò del tempo.
Memorizzazione nella cache di una singola entità di EF Core: NCache API dirette
API dirette. Ecco un dettaglio delle API dirette. Lascia che te lo mostri da qui, giusto?
Customers GetCustomer (string CustomerId)
{
string key = "Customer:CustomerId:" + CustomerId;
Customers customer = (Customers)_cache.Get(key);
if (customer != null)
{
return customer;
}
else
{
customer = (from cust in database.Customers
where cust.CustomerId == CustomerId
select cust).FirstOrDefault();
_cache.Insert(key, customer);
return customer;
}
}Quindi, in genere questo è il tuo metodo per ottenere il cliente. Se stai utilizzando API dirette, è probabile che tu abbia un ID cliente. Quindi, prima di tutto, devi costruire una chiave cache, giusto. Quindi, è qualcosa che devi fare come un must. Perché, dentro NCache tutto è memorizzato in una coppia chiave-valore. Key è la tua chiave di stringa, per identificare un oggetto. Una parte dell'oggetto è il valore effettivo, la proprietà effettiva che si desidera aggiungere nella cache. Dati effettivi che desideri memorizzare nella cache per la tua applicazione.
Quindi, ho creato questa organizzazione chiave, in cui ho cliente come parola chiave e quindi ID cliente e quindi fornisco un parametro di runtime che mi viene passato, giusto? Quindi, questo identificherebbe questo particolare cliente proprio qui, con l'ID cliente qualcosa di univoco, giusto? In modo che ti consenta in modo univoco di identificare quei clienti e quindi di chiamare la cache. Ottieni di recuperare gli elementi dalla cache. Destra? Quindi, prima di tutto se stai usando la memorizzazione nella cache, devi assicurarti di aver costruito la chiave e quindi prima controlla che i dati siano disponibili nella cache chiamando cache. Ottieni e questo handle della cache è qualcosa che viene restituito quando si inizializza la cache, giusto?
Quindi, sto usando questa cache proprio qui, NCache.Inizializza cache. Ti permette di inizializzare la cache e di connetterti ad essa. Se trovi gli articoli nella cache, il che significa che il cliente non era nullo, sei semplicemente tornato da qui. Si risparmiano viaggi costosi nel database e questa è la motivazione principale dell'utilizzo del sistema di memorizzazione nella cache dove NCache avrebbe i tuoi dati Quindi, risparmi i tuoi viaggi costosi attraverso il database di back-end. Non è necessario accedere al database. Ma poiché è la prima volta che si avvia questa applicazione. Quindi, in tal caso, la cache non avrebbe i dati.
Quindi, in tal caso, eseguiresti Entity Framework Core, collegandoti all'interno di Entity Framework Core. Restituirebbe un singolo articolo o una collezione. È uno scenario a elemento singolo e quindi chiami cache. Inserisci per aggiungerlo effettivamente per l'utilizzo successivo e restituire anche il cliente. Quindi, la prossima volta troverai sempre questi dati nella cache purché non vengano modificati o sincronizzati con i dati. Quindi, questo è il nostro uso unico di Entity, API dirette.
Memorizzazione nella cache della raccolta di entità di EF Core: NCache API dirette
Nel caso delle raccolte, le API dirette sono molto simili.
List GetCustomersByCity (string CustomerCity)
{
string key = "Customers:City = " + CustomerCity;
List custList;
custList = (List)_cache.Get(key);
if (custList != null)
{
return custList;
}
else
{
custList = (from cust in database.Customers
where cust.City == CustomerCity
select cust).ToList();
_cache.Insert(key, custList);
return custList;
}
} Abbiamo clienti per città. La città dei clienti è un parametro di runtime. Costruiremo un elenco di clienti e proveremo a recuperare quell'elenco di raccolta da NCache cache.Get, ottenere un elenco di clienti. Se questo non è un ritorno nullo da qui, se è nullo dobbiamo recuperarlo dal database di back-end e aggiungerlo anche nella cache per il prossimo utilizzo. Quindi, ecco com'è e se desideri archiviare questi articoli del cliente individualmente, puoi anche scorrere questo elenco di utenti e chiamare individualmente la cache. Inserisci fornendo anche chiavi univoche per ogni articolo della raccolta. Quindi, questa è un'altra opzione che puoi utilizzare.
Ma vedi, devi prima costruire una chiave, ottenere l'elemento dalla cache. Se è presente, esegui la gestione null e poi, se non è presente, lo ottieni dal database, esegui la logica dei dati e quindi aggiungilo. Quindi, questo è qualcosa che hai a che fare con Direct NCache API. È il caso d'uso più comune per qualsiasi tipica memorizzazione nella cache del database. Per la memorizzazione nella cache dei dati delle app, questo è ciò che faresti normalmente.
Memorizzazione nella cache di entità singola di EF Core - Metodi di estensione di EF Core
Ma c'è un altro approccio, che è attraverso i nostri metodi di estensione e questo è il momento clou principale. Puoi memorizzare nella cache l'intera raccolta come un elemento o di nuovo nella cache ogni elemento della raccolta separatamente ma tramite metodi di estensione.
Customers GetCustomer (string CustomerId)
{
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs.SeperateEntities
};
Customers customer = (from cust in database.Customers
where cust.CustomerId == CustomerId
select cust).FromCache(out string cacheKey,
options).FirstOrDefault();
return customer;
} Ecco il nostro primo metodo di estensione che voglio mostrarvi. Va bene, quindi, si chiama From Cache ma fa molta automazione per te, giusto. Funziona in modo tale che prima di tutto ti permetta di costruire alcune opzioni di memorizzazione nella cache, giusto? Quindi, prima di tutto crei opzioni di memorizzazione nella cache e uno degli attributi che sto introducendo a questo punto è Memorizza come. Così, NCache ti permetterebbe di scegliere se una collezione è necessaria per essere archiviata come un singolo articolo, come singoli articoli, articoli da collezione. Diciamo che c'erano 10 articoli nella collezione. Quindi, quelli verrebbero aggiunti come 10 elementi separati in NCache o vuoi conservarlo come una collezione che è proprio qui, giusto? Quindi, questa è la seconda opzione. In questo caso verrebbe archiviato come un elemento nella cache.
Quindi, sto usando entità separate. Quindi, se eseguo questo codice proprio qui, ho un metodo di estensione che dice From Cache e se ti mostro la definizione di questo viene da NCache Alachisoft .NCache.EntityFrameworkCore. Questo è lo spazio dei nomi principale e se vengo qui e ti mostro i pacchetti NuGet. Sotto Installato abbiamo Alachisoft .NCachePacchetto .EFCore NuGet. Quindi, questo è il pacchetto NuGet che devi introdurre e successivamente puoi iniziare con questi metodi di estensione. Prima di tutto, è una chiave della cache di riferimento in uscita, quindi la chiave della cache verrà generata da NCache e ti è stato dato. Quindi, questa è la flessibilità e quindi prende solo le opzioni come parametro, giusto. Quindi, fa molta automazione e dietro le quinte sta facendo molto lavoro per te. FromCache funziona in modo tale da controllare automaticamente i dati nella cache prima, questo è il comportamento, se trova, non va al database.
Ma, se non è nella cache e quindi andrebbe al database come regola e otterrebbe l'esecuzione della query, il set di risultati recuperato e quindi aggiunto nella cache utilizzando questa chiave di cache che viene popolata e quindi queste opzioni di memorizzazione nella cache vengono impostate su quell'elemento . Quindi, se lo confronti con questo, non devi costruire la chiave della cache. Non devi controllare tu stesso la gestione dei null o l'ottenimento dalla cache. Non è necessario inserirlo nella cache. Devi solo usare questo metodo di estensione. Quindi, questo rende molte cose automatizzate e il suo modello di programmazione molto semplificato anche per le tue applicazioni.
Memorizzazione nella cache della raccolta di entità di EF Core: metodi di estensione di EF Core
E, nello stesso caso in cui desideri archiviarlo come raccolta, fornisci semplicemente le opzioni di memorizzazione nella cache per essere raccolta e, in questo caso, hai un elenco di clienti che vorresti restituire. Quindi, esegui semplicemente la query e quindi chiami di nuovo FromCache. Quindi, questo completa il nostro primo metodo di estensione e introduzione ad esso.
List GetCustomersByCity (string CustomerCity)
{
List custList;
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs.Collection
};
custList = (from cust in database.Customers
where cust.City == CustomerCity
select cust).FromCache(out string cacheKey,
options).ToList();
return custList;
} Quali dati memorizzare nella cache in EF Core?
Successivamente, parlerò di dati di riferimento e transazionali. Questo è il segmento principale.
Avresti a che fare con applicazioni che hanno molte letture, dati con molte letture che scritture e quindi potrebbero esserci scenari di applicazioni in cui abbiamo letture e scritture, giusto? Quindi, ad esempio, cerca prodotti di dati, dipendenti, che non cambiano così frequentemente ma non sono dati statici, è qualcosa che cambia ma la frequenza delle modifiche non è eccezionale e nella cache dovrebbero esistere interi dati. In questo scenario particolare, spiegherò perché e dovresti scadere dopo, alcune ore o giorni. Ecco come mantenere la cache fresca, questo è un altro segmento.
Quindi abbiamo i dati transazionali. Parlerò di come gestire la memorizzazione nella cache dei dati transazionali. È creato dinamicamente. Ordini, conti, questi sono esempi. Cambia molto frequentemente e in genere i dati storicamente transazionali non erano preferiti per la memorizzazione nella cache. Perché, doveva cambiare e doveva andare via dall'applicazione mentre l'utente è attivo, è necessario solo a quel punto. Ma in base alla nostra esperienza, consigliamo vivamente di abilitare la memorizzazione nella cache anche per i dati transazionali. Perché, anche se non lo stai modificando, i dati sono ancora attivi, potresti leggerli molte volte e se hai milioni di utenti che hanno effettuato l'accesso, ciò comporterebbe milioni di richieste per quei dati che tornano al database e se è memorizzato nella cache e anche potrebbe essere da due a tre richieste mentre cambierà, sarà comunque vantaggioso dal punto di vista delle prestazioni. Quindi, ti consigliamo vivamente di considerare la memorizzazione nella cache di parte delle tue transazioni, se non di tutte.
Memorizzazione nella cache dei dati di riferimento in EF Core
Bene, come gestire la memorizzazione nella cache dei dati di riferimento in EF Core?
Ho un processo in due fasi per questo. Puoi caricare interi dati nella cache, è un must. Quindi, tutti i tuoi dati di riferimento dovrebbero essere caricati nella cache, questo è ciò che consigliamo come must. Come mai? Perché non vuoi assolutamente accedere al database, giusto? Dovresti andare avanti e iniziare a caricare tutti i tuoi dati dal database in NCache e abbiamo un metodo di estensione che se ne occuperebbe immediatamente e quindi utilizzerà solo la cache ed eviterà i viaggi del database.
Il secondo passaggio è sempre memorizzato nella cache come entità separate. Questo è un altro consiglio che ti darei che non dovresti memorizzare nella cache tutti i prodotti o qualsiasi altro, tutti i prodotti come una raccolta, giusto? Potrebbero essere migliaia di prodotti o milioni di prodotti. Ma memorizzarli individualmente ti consentirebbe di recuperare sottoinsiemi di dati in una fase successiva, giusto. Quindi, ad esempio, carichi tutti i prodotti ma in un secondo momento dalla cache sono necessari solo i prodotti fuori produzione. Quindi, se li hai memorizzati singolarmente nella cache, diciamo sessantamila prodotti, questo è l'esempio che ti mostrerò. Puoi trovare solo quelli che ti servono a quel punto. Quindi, non è necessario gestire l'intero set di dati del prodotto e salvare di nuovo viaggi costosi nel database.
Memorizzazione nella cache dei dati di riferimento in EF Core: precaricamento della cacheQuindi, abbiamo un metodo di estensione chiamato LoadIntoCache, quello è il prossimo che ti mostrerò e ti mostrerò anche un esempio funzionante di questo.
void LoadAllProducts (NorthwindContext database)
{
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs.SeperateEntities,
};
// Loads all products into cache as individual entities
var res = (from products in database.Products select
products).LoadIntoCache(options).ToList();
}
Ora, LoadIntoCache, prima di tutto, le opzioni di memorizzazione nella cache dovrebbero essere impostate come "memorizza come entità separate" e quindi dovresti eseguire una query che dovrebbe caricare tutti i prodotti e quindi dovresti chiamare LoadIntoCache e quindi fornire le opzioni e di nuovo creerebbe semplicemente chiavi di cache per tutti quelli individualmente, automaticamente. E continuerebbe a caricare tutti quegli elementi nella cache e quindi puoi eseguire query LINQ come questa e questa query LINQ è contraria NCache. Non utilizza alcun metodo di estensione. Sta chiamando il prodotto nei prodotti del database in cui prodotto. Non è più disponibile e abbiamo solo FromCache. Non andrà affatto al database. Lo sta ricevendo NCache direttamente.
Memorizzazione nella cache dei dati di riferimento in EF Core: ricerca dei dati di riferimento solo dalla cacheSe disponi di dati di riferimento, devi prima caricare entità separate. Usa il caricamento nella cache per caricare tutti i prodotti NCache. Una volta fatto ciò, non è necessario accedere al database. Quindi usi FromCacheOnly invece di FromCache. Il primo metodo di estensione era FromCache che controlla la cache e quindi va al database se non è nella cache. Tuttavia, LoadIntoCache caricherebbe tutti i prodotti e quindi FromCacheOnly assicurerebbe che comunichi solo con la cache presupponendo che tutti i dati siano caricati nella cache.
List<Products> FindDiscontinuedProducts (NorthwindContext database)
{
//Fetch discontinued products only out of all products
List<Products> discontinuedProducts;
discontinuedProducts = (from product in database.Products
where product.Discontinued == true
select product).FromCacheOnly().ToList();
return discontinuedProducts;
}Fammi eseguire questo codice, in modo che tu lo veda in azione. Ho una cache che è configurata proprio qui per questo test e ti mostrerò le statistiche. Ci ho giocato. Vengono caricati 60,000 prodotti. Quindi, lasciami andare avanti e cancellare il contenuto. Giusto, quindi, esaminiamo le statistiche. Dov'è la mia cache? Ecco qua. Giusto, quindi, sono zero elementi e poi andrò avanti ed eseguirò questo. Metterebbe semplicemente nella cache il singolo elemento, quindi raccoglierà tutti gli esempi di codice che ti ho mostrato, ma vorrei mostrarti come funziona LoadIntoCache e sulla base di quello, metterò anche un punto di interruzione lì, ecco fatto.
Quindi, i primi due esempi sono stati il caricamento di un singolo articolo e quindi il caricamento di una raccolta, il codice iniziale che ti avevo mostrato e poi questo qui sta effettivamente caricando tutti i prodotti per mostrarti lo scenario dei dati di riferimento. Prima di tutto, viene archiviato come entità separate e sta impostando alcune priorità, alcune dipendenze, è elaborato in termini di ciò e poi andrà avanti e caricherà tutti i prodotti, recuperandoli dal database e ti consiglio vivamente di continuare a correre caricare il prodotto, caricato nella cache dopo alcuni intervalli, in modo che i dati siano stati recuperati dal database e caricati nella cache funzioni sempre rispetto al database. Andrà sempre al database e qualunque cosa tu abbia nel database, è destinato a essere eseguito sul database e recuperare quei dati su NCache e quindi utilizzare FromCacheOnly in seguito.
Quindi, è così che gestisci i dati di riferimento. Prima di tutto, li conservi singolarmente, separatamente. LoadIntoCache, utilizzando questo metodo di estensione LoadIntoCache, che viene sempre eseguito sul database. Non ha la cache come priorità. Verrebbe sempre eseguito sul database e quindi recuperato tutto NCache e quindi usa FromCacheOnly. Ecco com'è semplice.
Memorizzazione nella cache dei dati transazionali in EF Core
Dati transazionali. È possibile caricare solo il working set. È per la memorizzazione nella cache del set di risultati, giusto?
Personalmente raccomando che se sei interessato a clienti per città, ordini basati su un prodotto, dovresti avere una sorta di memorizzazione nella cache del set di risultati ed è quello che dovresti fare. Dovresti archiviarli come una raccolta o entità separate in base alla dimensione dei risultati, che se una raccolta non è di grandi dimensioni diciamo che ha a che fare con 100 o 200 elementi al massimo, archiviali come una raccolta e, ma se esiste sono più prodotti, più ordini o informazioni sui clienti, che verrebbero classificati come dati transazionali. Archiviali come entità separate. Quindi, puoi estrarne un sottoinsieme e puoi massimizzare l'uso della memorizzazione nella cache.
Memorizzazione nella cache dei dati transazionali in EF Core - Recupera e memorizza nella cache come raccoltaIl caso d'uso per questo è di nuovo molto semplice. Lo memorizzi semplicemente come raccolta o usi FromCache, non usi FromCacheOnly perché vorresti andare al database se non è nella cache.
List<Orders> GetCustomerOrders (string CustomerID)
{
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs = StoreAs.Collection,
};
//Fetch from cache. If not found then fetch from DB.
orderList = (from customerOrder in database.Orders
where customerOrder.Customer.CustomerId==CustomerID
select customerOrder)
.FromCache(out string cacheKey, options).ToList();
return orderList;
}List<Orders> GetCustomerOrders (string CustomerID)
{
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs.SeperateEntities
};
//Fetch from cache. If not found then fetch from DB.
orderList = (from customerOrder in database.Orders
where customerOrder.Customer.CustomerId==CustomerID
select customerOrder)
.FromCache(out string cacheKey, options).ToList();
return orderList;
}Finora abbiamo introdotto tre metodi di estensione. FromCache che funziona automaticamente con cache e database e non nella cache lo otterresti dal database. LoadIntoCache verrebbe sempre eseguito sul database. Recupera gli oggetti e portali nella cache e FromCacheOnly sempre in esecuzione sulla cache e questa è l'unica vera fonte di dati. Non andrebbe al database. Quindi, spero che questo chiarisca molte cose.
Mantenere la cache fresca
Il prossimo segmento si basa su come mantenere la cache fresca in Entity Framework Core e questo è un altro concetto importante che dovete capire quando avete a che fare con due fonti diverse.
Hai abilitato la memorizzazione nella cache. Hai un database di back-end che è la tua fonte di dati principale, un archivio dati persistente e quindi hai una memorizzazione nella cache che ha anche una copia dei dati. Quindi, come garantire che la cache sia fresca rispetto al database. Allora, trascorriamo un po' di tempo qui.
Mantieni la cache fresca: dati di riferimento
Prima di tutto, dovresti, dato che hai l'intero set di dati nella cache, cosa succede se c'è una modifica nel database, giusto?
Quindi, è necessario far scadere i dati dalla cache e per questo ti consigliamo di utilizzare la scadenza e quindi il ricaricamento automatico dei dati potrebbe essere un'opzione. Quindi, la strategia uno è utilizzare la scadenza ma senza ricaricare. Quindi, ogni volta che i dati scadono, vengono ricaricati automaticamente anche nella cache e per questo abbiamo questa configurazione proprio qui, Carica tutti i prodotti.
Strategia 1: usa la scadenza ma con la ricarica automaticavoid LoadAllProducts (NorthwindContext database)
{
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs.SeperateEntities,
};
options.SetAbsoluteExpiration(DateTime.Now.AddHours(10));
options.SetResyncProviderName("MyEFCoreResyncProvider");
// Load all products into cache with Expiration and Auto-Reload
var res = (from products in database.Products select
products).LoadIntoCache(options).ToList();
}Lascia che te lo mostri da qui, giusto. Quindi, prima di tutto, li memorizzi come entità separate perché questo è il caso d'uso dei dati di riferimento. Li carichi come tutti i prodotti e quindi imposti una sorta di scadenza e quindi options.SetResyncProvider, dovrebbe esserci un provider di ricarica e quindi le opzioni di configurazione.IsSyncEnabled su true. Quindi, ricarica automatica, in modo che si ricarichi automaticamente nella cache in caso di scadenza, giusto. Quindi, queste sono le due proprietà insieme a, se SetResyncProviderName imposterebbe automaticamente il flag di ricarica automatica su true.
namespace Alachisoft.NCache.EFSampleResyncProvider
{
public abstract class EFDefaultResyncProvider : IReadThruProvider
{
public virtual void Init(IDictionary parameters, string cacheId)
{
db = InitializedDbContext();
}
public virtual void LoadFromSource(string key, out
ProviderCacheItem cacheItem)
{
cacheItem = new ProviderCacheItem(FetchItemFromDb(key));
cacheItem.AbsoluteExpiration = DateTime.Now.AddHours(10);
cacheItem.ResyncItemOnExpiration = true;
}
public virtual void Dispose()
{
db.Dispose();
}
}
}E poi hai bisogno di ResyncProvider proprio qui, ovvero la nostra implementazione di esempio è proprio qui che sto mostrando.
namespace Alachisoft.NCache.EFSampleResyncProvider.Provider
{
public class EFResncProvider : EFDefaultResyncProvider,
IReadThruProvider
{
public override DbContext InitializedDbContext()
{
return new NorthwindContext();
}
}
}Ecco qua. Devi implementare il nostro IReadThruProvider. Inizializza la tua origine dati, eliminala alla fine e quindi LoadFromSource ti consente di ottenere la chiave e in base a quella chiave costruisci un comando SQL e prendi gli elementi dal database e qui ho fornito un'implementazione di esempio in cui costruiamo un Query SQL dalla chiave di cache che abbiamo.
Giusto, quindi, quella chiave, in questa implementazione di esempio è disponibile anche su GitHub. Quindi, funzionerà in modo tale che i tuoi elementi caricati nella cache, se eseguo il caricamento nella cache ancora una volta, avrebbero la scadenza allegata. Quindi, sarebbero scaduti dopo cinque o dieci ore, qualunque sia il periodo di scadenza, dopodiché questo provider si avvierebbe e chiamerebbe LoadFromSource usando il gestore read-through automaticamente e i dati aggiornati vengono portati in NCache. Giusto, quindi la tua cache sarebbe automaticamente fresca dopo che gli elementi sono scaduti da essa.
Strategia 2: non utilizzare la scadenza, ricaricare manualmenteIl secondo approccio che raccomando personalmente è non usare l'espressione, ricaricare manualmente chiamando LoadIntoCache. Ed è qualcosa di molto semplice che dovresti inventare questo metodo LoadIntoCache, se te lo mostro ancora una volta. Continua a chiamare questo metodo dopo alcuni intervalli e non utilizzare alcuna espressione. Eliminiamo questi.
void LoadAllProducts (NorthwindContext database)
{
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs.SeperateEntities,
};
var res = (from products in database.Products select
products).LoadIntoCache(options).ToList();
}Quindi, sai che questi saranno i dati di riferimento validi solo per diciamo un'ora, due ore, cinque giorni, settimana, mese. Sulla base di ciò, continua a ripetere questo caricare tutti i prodotti. Questo dovrebbe essere chiamato dopo alcuni intervalli, giusto?
Quindi, questa è l'idea che dovresti ricaricare i dati manualmente sulla base di un'ipotesi intelligente fatta sull'intervallo di scadenza, giusto? Quindi, dovresti trovare l'orario di lavoro impostato, dopodiché dovresti chiamare automaticamente il caricamento di tutti i prodotti. In modo che ottenga automaticamente i dati dal database di back-end e i tuoi dati di riferimento siano mantenuti aggiornati.
Quindi, ho intenzione di ribadire questi. Quindi, ci sono due opzioni. Se stai utilizzando i dati di scadenza verranno rimossi dalla cache. Quindi, finiresti con set parziali, quindi è necessario ricaricare automaticamente. Ma, se non usi la scadenza, avresti sempre tutti i dati nella cache per i dati di riferimento e quindi puoi ricaricare manualmente quei dati dopo determinati intervalli. Spero che si chiarisca.
Mantieni la cache fresca: dati transazionali
Successivamente, parlerei di mantenere la cache fresca per i dati transazionali ed è piuttosto semplice. Dovresti sempre usare una scadenza breve senza ricaricare automaticamente. Perché, ancora una volta, si tratta di dati di breve durata che possono essere validi solo per cinque o dieci minuti e dovresti usare FromCache, in modo che se non è nella cache dovresti sempre ottenerlo dal database back-end.
E, eccone un esempio, in cui abbiamo gli ordini dei clienti, li archiviamo come collezione o singoli articoli, dipende interamente da te. Scadenza breve se necessario o non utilizzare una scadenza, oppure utilizzare la scadenza e quindi non utilizzare alcuna ricarica automatica per quella materia. In modo che venga recuperato dal database non appena scaduto. Personalmente consiglio di utilizzare una scadenza configurabile o di trovare la scadenza che sai per certo che è un orario di lavoro per questo set di dati. In modo che dopo non sarebbe più necessario. Quindi, dovrebbe scadere automaticamente e quindi a quel punto imporresti l'accesso al database e lo otterrai automaticamente dal database di back-end.
Scadenza breve, nessuna ricarica automatica private List<Orders> GetCustomerOrders (string CustomerID)
{
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs = StoreAs.Collection
};
options.SetAbsoluteExpiration(DateTime.Now.AddSeconds(60));
List<Orders> orderList = (from customerOrder in database.Orders
where customerOrder.Customer.CustomerId==CustomerID
select customerOrder).FromCache(out string cacheKey,
options).ToList();
return orderList;
}Quindi, abbiamo spiegato come gestire i dati di riferimento, nonché i dati transazionali. Quindi abbiamo anche spiegato come mantenere la cache aggiornata per riferimento, oltre ai dati transazionali.
Gestione delle relazioni nella cache
Uno-a-molti
Alcune altre cose che potresti incontrare con la memorizzazione nella cache. Gestione delle relazioni nella cache per EF Core. Ancora una volta, è molto semplice. Include è supportato, quindi se hai una regione con regioni di database e poi ottieni region.Territory accanto a loro, giusto? Quindi, puoi chiamare FromCache e memorizzerebbe le regioni separatamente e i territori separatamente e formulerebbero una relazione tra regione e territori. Quindi, se ti mostro, ottieni la regione con i territori.
List<Region> GetRegionWithTerritories(NorthwindContext database)
{
List<Region> regionDetails;
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs.SeperateEntities
};
regionDetails = (from region in database.Region select region)
.Include(region => region.Territories)
.FromCache(options).ToList();
return regionDetails;
}Questo è un esempio qui. Destra. Quindi, i dettagli di questa regione includono e quindi stiamo usando FromCache. Quindi, memorizzeremo le regioni e i territori delle regioni separatamente, separeremo gli elementi e poi costruiremo una dipendenza basata su chiavi. Se le regioni subiscono un cambiamento, anche i territori verranno invalidati e viceversa. Quindi, è così che gestiresti le relazioni uno-a-uno o uno-a-molti.
Operazioni di aggregazione di memorizzazione nella cache
Sono supportate anche le operazioni aggregate. Quindi, puoi eseguire questi metodi di estensione con un Deferred First o Default, FromCache. Può essere basato su Conteggio differito, FromCache. Quindi, li memorizzerebbe come set di risultati, giusto? Quindi, non importa se li memorizzi come collezione o singoli articoli perché questo è solo il risultato di operazioni aggregate. Quindi, questa è un'altra possibilità con il nostro Entity Framework.
Operazioni aggregate di memorizzazione nella cache - Entità di ritorno
Shippers GetFirstShipperInstance (NorthwindContext database)
{
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs.Collection
};
Shippers shipper = database.Shippers.DeferredFirstOrDefault()
.FromCache(out string cacheKey, options);
return shipper;
}Operazioni di memorizzazione nella cache di aggregazione - Restituzione di valori
int GetTotalShippersCount (NorthwindContext database)
{
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs.Collection
};
int count = database.Shippers.DeferredCount()
.FromCache(out string cacheKey, options);
return count;
}Architettura di cache distribuita
Quindi, verso la fine, vorrei parlare di alcuni dettagli architettonici sulla memorizzazione nella cache distribuita. Perché dovresti considerarlo. È altamente disponibile, è super affidabile, con replica. È una cache con architettura peer-to-peer. Non c'è un singolo punto di errore. È possibile aggiungere o rimuovere qualsiasi server in fase di runtime e i client hanno il supporto per il failover della connessione compilato su di esso. Quindi, è altamente disponibile e super affidabile con un tempo di attività del 100%. Viene fornito con molte topologie di memorizzazione nella cache, cache client, replica WAN, repliche partizionate e partizionate e posso parlare specificamente di dettagli architetturali se ci sono domande, altrimenti a questo punto si conclude la nostra presentazione.
Alta disponibilità
Topologie di memorizzazione nella cache
Cache client (vicino alla cache)
Replica WAN della cache
Conclusione
Vorrei fare un breve riassunto di questo. In questo webinar abbiamo parlato di opzioni di memorizzazione nella cache, API dirette, Entity Framework Core Extension Methods. Quindi, abbiamo opzioni di scelta tra questi. Eravamo più concentrati sui metodi di estensione di Entity Framework Core perché è quello che vorremmo proiettare. È più facile da usare. Come affrontare i dati di riferimento e transazionali. Quindi, abbiamo parlato di approcci per caricare interi dati per i dati di riferimento e quindi utilizzare l'approccio di entità separate e quindi utilizzare la cache solo per tutti i dati che hai nella cache. Per i dati transazionali, consigliamo di memorizzare nella cache solo il set di risultati e quindi utilizzare il metodo di estensione FromCache in modo da poter accedere al database se non è nella cache. E poi, per mantenere la cache fresca, abbiamo detto che dovresti usare la scadenza con ricarica automatica per i dati di riferimento o non usare la scadenza ma ricaricare manualmente dopo determinati intervalli e per i dati transazionali assicurati di usare la scadenza, giusto? Dovrebbe essere una scadenza breve ma senza ricarica automatica, quindi puoi tornare al database e aggiornare la cache al prossimo utilizzo.
Puoi sempre raggiungerci a support@alachisoft.com. In caso di domande tecniche, puoi anche contattarci all'indirizzo sales@alachisoft.com. Se desideri dare un'occhiata al prodotto, puoi scaricarlo NCache Enterprise per una prova gratuita di 30 giorni.