Gestione dei dati relazionali in una cache distribuita
Webinar registrato
Di Ron Hussain e Adam J. Keller
In questo webinar video scopri come applicare le tue relazioni di dati esistenti per memorizzare nella cache gli oggetti per la memorizzazione nella cache distribuita.
Puoi aspettarti di sentire parlare di:
- Il modello di archiviazione dei dati per un database relazionale e per una cache distribuita
- La bontà della mappatura relazionale degli oggetti: come gestire le relazioni dei dati a livello di oggetto
- Mappatura delle relazioni "uno-uno", "uno-molti" e "molti-molti".
- utilizzando NCache funzionalità per costruire relazioni tra oggetti per imitare i comportamenti dei dati relazionali
- uso di dipendenze basate su chiavi, linguaggio di query degli oggetti, gruppi, API di gruppo, raccolte e tag
- Altre importanti funzionalità di memorizzazione nella cache distribuita per i dati relazionali
Parlerò di avere una cache distribuita in atto. Quando hai un database relazionale, sai, hai alcune sfide, alcuni problemi di prestazioni, alcuni problemi di scalabilità e quindi sposti la transizione nell'utilizzo di una cache distribuita insieme al database relazionale. Quali sono le sfide che ricevi e come gestirle? Quindi, questo è ciò che abbiamo in agenda per il webinar di oggi.
Sarà abbastanza pratico. Voglio mostrarti alcuni esempi di codice. Parlerò di alcuni esempi reali. Ho alcuni esempi in fila che userò effettivamente per dimostrarlo. E poi, verso la fine, avrei anche una parte pratica per ripassare alcune cose di base NCache configurazioni.
NCache, questo è il principale prodotto di memorizzazione nella cache distribuita. Lo useremo come prodotto di esempio per questo particolare webinar. Ma, nel complesso, è un webinar generale sull'argomento. Abbiamo un dato relazionale nel database e quindi hai una cache distribuita. Come eseguire la transizione e quindi iniziare a utilizzare la cache distribuita all'interno, sai, i dati relazionali che hanno relazioni e che sono dati strutturati. Quindi, esaminiamo questo.
Che cos'è la scalabilità?
Quindi, prima di tutto, parlerò di scalabilità, il concetto di scalabilità. La scalabilità è un'abilità all'interno dell'applicazione in cui è possibile aumentare il carico transazionale. Dove puoi gestire sempre più richieste caricate dall'architettura dell'applicazione. E non scendi a compromessi con le prestazioni, quindi, se hai un throughput elevato e una bassa latenza, tale capacità si chiama scalabilità. Quindi, puoi gestire un'enorme quantità di carichi di richieste e le prestazioni delle singole richieste non diminuiscono. È lo stesso! Inoltre, con più risorse puoi persino aumentarlo e la scalabilità lineare è un termine associato che ti consente di scalare effettivamente verso l'esterno dove hai più o più capacità di gestione del carico delle richieste introdotta nel sistema aggiungendo più server. E, nella maggior parte dei casi, le prestazioni non diminuiscono.
Quindi, se hai una bassa latenza e hai un miglioramento lineare nel carico delle richieste, in precedenza gestivi diciamo 10,000 richieste al secondo o anche per cinque utenti hai una certa quantità di latenza, diciamo alcuni millisecondi o tempi di risposta inferiori al millisecondo per cinque utenti ; dovresti avere lo stesso tipo di risposte, lo stesso tipo di eseguire lo stesso tipo di latenza per cinquemila utenti o cinquantamila utenti. E quella capacità di continuare ad aumentare il carico dell'utente e il carico delle richieste associate, si chiama scalabilità lineare.
Quali app necessitano di scalabilità?
Quindi, quali sono le applicazioni tipiche che necessitano di scalabilità,
Saranno le tue applicazioni Web ASP.NET, le applicazioni Web Java o persino le applicazioni Web generali .NET che sono rivolte al pubblico. Potrebbe essere un sistema di e-commerce, potrebbe essere un sistema di biglietteria aerea, un sistema di prenotazione o potrebbe essere un servizio finanziario o un servizio sanitario che ha molti utenti che utilizzano effettivamente il suo volto pubblico. Potrebbe trattarsi di servizi Web WCF o qualsiasi altro servizio di comunicazione che interagisce con alcuni livelli di accesso ai dati o si occupa di alcune applicazioni front-end. Tuttavia, potrebbe gestire milioni di richieste in un dato momento. Potrebbe essere Internet of Things, alcuni dispositivi back-end in grado di elaborare dati che alcune attività elaborano per quei dispositivi. Quindi, potrebbe caricare molte richieste. Elaborazione di big data che è la parola d'ordine comune in questi giorni in cui abbiamo molti piccoli server di calcolo poco costosi e attraverso la distribuzione di dati su più server si elaborano effettivamente enormi quantità di carichi di dati.
E, allo stesso modo, ci sarebbero enormi richieste di modelli caricate per quei dati particolari. E poi potrebbero esserci altre applicazioni server generali e applicazioni di livello che potrebbero gestire milioni di richieste, molti utenti, quelli sono i principali candidati per la scalabilità. Queste sono le applicazioni che necessitano di scalabilità all'interno dell'architettura.
Collo di bottiglia della scalabilità
Questo è un diagramma tipico. Qual è il collo di bottiglia della scalabilità?
Quindi, queste sono le applicazioni. In base alla progettazione, questi framework sono molto scalabili. Modulo Web ASP.NET o modulo WCF ci sono opzioni che puoi usare per scalare in orizzontale questi sistemi. Ma parlano tutti con un database back-end e in genere è un database relazionale. Potrebbe anche essere un archivio di sessione ASP.NET o un mainframe o un file system, ma non è quello che tratteremo nel webinar di oggi. Il webinar di oggi è più incentrato sui dati relazionali. Quindi, i dati relazionali sono un'unica fonte. Anche se qui hai una piattaforma molto scalabile. Puoi aggiungere sempre più server su questo livello. È possibile eseguire la scalabilità orizzontale inserendo un servizio di bilanciamento del carico in primo piano e tale servizio di bilanciamento del carico può instradare le richieste tra server diversi. Ma tutti questi server Web finiscono per parlare con un livello di database che non è così scalabile.
Quindi, questa sarà una fonte di contesa. Sarà lento all'inizio e poi non può scalare. È un'unica fonte, non è possibile aggiungere sempre più server di database per aumentare la capacità della richiesta. Quindi, la capacità della richiesta può essere massimizzata e ciò può portare a una latenza elevata. Quindi, è un problema di capacità per la gestione di una richiesta e potrebbe anche finire in un problema di latenza in modo che possa soffocare il sistema quando si caricano enormi richieste.
La Soluzione
Quindi, questo è il problema principale con le origini dati relazionali e la soluzione è molto semplice: inizi a utilizzare una cache distribuita.
Un sistema di cache distribuito come NCache che è super veloce perché è in memoria in confronto e quindi è linearmente scalabile. Non è solo un singolo server. È un ambiente con più server in cui abbiamo un team di server uniti in capacità. Unisci la capacità di memoria e la capacità transazionale e ne ottieni un modello scalabile in modo molto lineare. E, NCache è esattamente quel tipo di soluzione che puoi utilizzare per gestire i problemi di scalabilità del database.
Che cos'è la cache distribuita in memoria?
Com'è un sistema generale di cache distribuita in memoria NCache? Quali sono le caratteristiche?
Cluster di più server cache economici
Sarà un cluster di più server cache economici che sono uniti in una capacità logica.
Quindi, questo ne è un esempio. Potresti avere da due a tre server di memorizzazione nella cache. Per NCache, puoi utilizzare l'ambiente Windows 2008, 2012 o 2016. Unico prerequisito per NCache è .NET 4. Ed è un livello intermedio tra la tua applicazione e il database ed è molto scalabile rispetto al livello del tuo database, ma è qualcosa che ti darebbe lo stesso tipo di scalabilità che otterresti da un Web .NET accelerato modulo o modulo Web dei servizi Web WCF.
Sincronizza gli aggiornamenti della cache su tutti i server cache
Sincronizza gli aggiornamenti della cache su tutti i server cache in modo che la coerenza dei dati sia incorporata nel protocollo. Tutti gli aggiornamenti vengono applicati in modo automatico con una comprensione della visualizzazione dei dati coerente per tutti i client ad esso collegati.
Ridimensiona linearmente le transazioni e la capacità di memoria
Dovrebbe essere ridimensionato in modo lineare per le transazioni e dalla capacità di memoria si aggiungono semplicemente più server e non dovrebbe aumentare la capacità in risposta a ciò. Se hai due server e aggiungi il terzo e il quarto server, dovrebbe essenzialmente raddoppiare la capacità di quel sistema ora che hai il doppio della quantità di servizio. Quindi, ecco cosa NCache anche offerte.
Replica i dati per l'affidabilità
Quindi la replica è un'altra caratteristica per l'affidabilità. Qualsiasi server inattivo, prima di tutto, non dovrebbe avere alcuna perdita di dati o tempi di inattività. Dovrebbe essere un sistema altamente affidabile altamente disponibile e questo è ciò che NCache prendersi cura di.
NCache Distribuzione
Quindi, dopo aver discusso di questo, hai un problema di scalabilità con origini dati relazionali e sistemi di memorizzazione nella cache distribuiti come NCache è una soluzione a questo e diventa un livello centrale tra le tue applicazioni e il database e i tuoi dati esistono in due posti.
Hai i dati nel database e quindi hai i dati nella cache distribuita. Allora NCache gestisce anche alcuni problemi di sincronizzazione che potresti avere quando disponi di dati su due origini diverse. C'è un webinar separato su questo argomento, ma, solo per farti sapere che ci sono alcuni provider di livello di accesso ai dati, ci sono alcune dipendenze di notifica delle modifiche che puoi impostare.
Pertanto, qualsiasi modifica nel database può attivare un invalidamento o un aggiornamento degli elementi nella cache e allo stesso modo qualsiasi modifica o aggiornamento che si verifica nella cache può essere applicata al database. Quindi, questo può essere ottenuto con l'aiuto dei nostri fornitori di livelli di accesso ai dati; Read-through e Write-through.
Inoltre, abbiamo anche alcune dipendenze di modifica del database, dipendenze di modifica dei record che abbiamo effettivamente utilizzato per garantire la sincronizzazione del 100% tra il database e i record della cache. Ma in genere i dati esistono in due luoghi diversi. Hai dei dati nella cache che di solito è un sottoinsieme dei dati e quindi hai i dati effettivi nel database. Quando si migrano i dati, si tratta essenzialmente di una migrazione di dati. Anche se stai usando queste due fonti in combinazione l'una con l'altra, ma si tratta di due fonti diverse.
Quali dati memorizzare nella cache?
Prima di andare avanti, parleremo rapidamente dei tipi di dati che puoi memorizzare nella cache, potrebbero essere dati di riferimento, potrebbero essere dati transazionali.
È più un dato ad alta intensità di lettura che viene memorizzato nella cache di solito appartiene al database relazionale. Non è che non stia cambiando, non è statico al 100%. Sta cambiando i dati ma la frequenza di quel cambiamento non è eccezionale. Quindi, questo verrebbe classificato come un dato di riferimento. E poi abbiamo sempre dati transazionali che cambiano molto frequentemente. Con la stessa frequenza di pochi secondi, pochi minuti o in alcuni casi potrebbe essere di pochi millisecondi.
Inoltre, la maggior parte dei dati memorizzati nella cache è relazionale. È portato da un database relazionale e ho già discusso del fatto che hai i dati della copia master nel database relazionale e quindi hai un sottoinsieme di quei dati, un riferimento e transazionale, portato nella cache distribuita. Destra!
Qual è la sfida?
Allora, qual è la sfida? Quindi, discutiamo effettivamente di quella sfida! Quando si spostano i dati da un'origine dati in una relazione in una cache distribuita per ottenere maggiori prestazioni, maggiore scalabilità e maggiore affidabilità per il sistema. Discutiamo rapidamente di quali sono le sfide che vedi.
Funziona molto bene. Migliora le tue prestazioni perché è in memoria. è linearmente scalabile, quindi si occupa dei problemi di scalabilità con il database. Non è un singolo punto di errore perché ci sono più server e qualsiasi server può essere interrotto. Puoi attivare i server senza problemi. La manutenzione diventa molto più semplice. I tuoi aggiornamenti diventano molto più semplici. Quindi, in confronto, ottieni molti vantaggi. Ma c'è una sfida che devi affrontare e devi tenerne conto quando migri i tuoi dati o sposti i tuoi dati dal database alla cache distribuita e inizi a utilizzare il sistema di cache distribuita.
Quindi, la cache distribuita è un'interfaccia simile a una tabella hash. Destra! Ogni elemento è separato con la chiave e un valore, giusto? Quindi, è una tabella hash in cui elementi, ogni oggetto nella cache o ogni elemento nella cache o un record nella cache è rappresentato con l'aiuto di una chiave. Quindi, non è una tabella o non è un dato relazionale in cui abbiamo relazioni, abbiamo schemi definiti, abbiamo entità che hanno relazioni adeguate tra loro. Sarà un elemento valore chiave separato che rappresenta un oggetto nella cache. Pertanto, il database ha relazioni tra entità e quando si migrano i dati o quando si spostano i dati da un database relazionale a una cache distribuita, si perde quella relazione caratteristica di quei dati.
Quindi, per impostazione predefinita, non hai questa capacità, quindi possiamo rimuoverla. Questa è una delle sfide principali e poi ci sono altre sfide associate che le query del database risultano in una raccolta di oggetti. Risulta anche in una tabella di dati o in un lettore di dati. Quindi, gestire tabelle di dati e lettori di dati in una cache distribuita non è una buona idea, giusto? quindi affronteremo effettivamente tutte queste sfide una per una.
In primo luogo, discuteremo di come gestire le relazioni nella cache distribuita dopo aver portato i dati da un'origine dati relazionale nella cache come gestisci quei dettagli.
Sbircia nel NCache API
Quindi, dopo parleremo dell'API di memorizzazione nella cache.
Ora che abbiamo discusso che è fondamentalmente un archivio di valori chiave. Abbiamo un cache.add in cui abbiamo una chiave "mykey" e quindi abbiamo un oggetto che è qualsiasi dato consentito e oggetto serializzato consentito. potrebbe essere qualsiasi oggetto cliente, oggetto prodotto, oggetto ordine. Ma questo è un esempio molto semplice di Hello World in cui chiamiamo metodi di valore chiave usando cache.add, cache.update. Allo stesso modo, chiamiamo cache.get per recuperare lo stesso elemento e quindi chiamiamo cache.remove.
Gestisci le relazioni nella cache
Andare avanti! Quindi, come gestire le relazioni nella cache? Ora che abbiamo definito questa sfida che la cache è un'interfaccia simile a una tabella hash, è una coppia di valori chiave. Il valore è un oggetto .NET e la chiave è una chiave stringa che si formatta e questi sono oggetti indipendenti l'uno dall'altro. E il database ha tabelle di relazioni che hanno relazioni tra loro. Potrebbe trattarsi di una relazione uno-a-molti e molti-a-molti tra tabelle diverse.
Primo passaggio: utilizzare la dipendenza dalla cache
Ci sono due cose che dovresti considerare di fare prima di tutto dovresti considerare di usare la dipendenza dalla cache e ci concentriamo principalmente sulla dipendenza basata sulla chiave che è una delle funzionalità e ti mostrerò alcuni esempi di codice su ciò che ti aiuta a mantenere un traccia della dipendenza unidirezionale tra gli elementi della cache.
Quindi, potresti avere un oggetto genitore e quindi potresti avere un oggetto dipendente su quel particolare Oggetto. E il modo in cui funziona è che un elemento dipende da un altro. L'elemento principale, l'oggetto principale o l'oggetto padre; se subisce una modifica viene aggiornato o rimosso l'elemento dipendente automatico viene rimosso dalla cache.
Un tipico esempio che ho messo in fila nelle prossime diapositive è l'elenco degli ordini per un determinato cliente. Quindi, hai un cliente A. Ha un elenco di ordini, diciamo 100 ordini, cosa succede se quel cliente viene aggiornato o rimosso dalla cache. Non hai bisogno di quegli ordini associati con quello, quindi potresti voler fare qualcosa anche per la raccolta di quegli ordini ed è esattamente a cosa serve questa dipendenza per cui devi avere un collegamento tra questi 2 record poiché questi sono correlati nel nel banca dati relazionale.
Quindi questa dipendenza può anche essere di natura a cascata in cui A dipende da B e B dipende da C. Qualsiasi cambiamento nella C attiverebbe un'invalidazione di B e ciò a sua volta invaliderebbe anche A. Quindi, potrebbe essere una dipendenza a cascata e quindi potrebbe anche essere una dipendenza da più elementi. Un articolo può dipendere dall'articolo A così come dall'articolo B e, allo stesso modo, un articolo principale può avere anche più articoli secondari. E questa era una funzionalità inizialmente introdotta dalla cache di ASP.NET. Era una delle caratteristiche potenti che NCache ha anche. Lo forniamo come oggetto di dipendenza dalla cache separato e uno degli oggetti fantasiosi e questo sarà l'obiettivo principale di questo particolare webinar.
Secondo passaggio: utilizzare la mappatura relazionale degli oggetti
Secondo passaggio, per mappare i tuoi dati relazionali, c'è un'altra sfida che ti consigliamo di mappare effettivamente i tuoi oggetti di dominio sul tuo modello di dati, giusto?
Quindi, i tuoi oggetti di dominio dovrebbero rappresentare una tabella di database. Dovresti usare una sorta di mappatura O/R, puoi anche usare alcuni strumenti di mappatura O/R. Semplifica la tua programmazione, puoi riutilizzare il codice dopo aver mappato le classi sulle tabelle del database. Puoi utilizzare anche gli strumenti di mappatura ORM o O/R come Entity Framework e NHibernate. Questi sono alcuni strumenti popolari.
L'idea qui è che dovresti avere classi nell'applicazione. Gli oggetti, gli oggetti di dominio nell'applicazione. Quindi, i tuoi oggetti di database, tabelle di dati o lettori di dati vengono trasformati mappati sugli oggetti di dominio. Quindi, una tabella cliente dovrebbe rappresentare una classe cliente nell'applicazione. Allo stesso modo, la raccolta ordinata o la tabella degli ordini dovrebbero rappresentare la classe dell'ordine e l'applicazione. E poi quelli sono gli oggetti che gestisci e memorizzi nella cache distribuita e formuli relazioni con l'aiuto di Key Dependency.
Esempio di gestione delle relazioni
Facciamo un esempio!
E abbiamo il nostro modello di database di Northwind. Abbiamo la tabella dei clienti, abbiamo la tabella degli ordini e poi abbiamo il prodotto. Abbiamo tutti i nomi delle colonne del cliente, abbiamo l'ID cliente, il nome dell'azienda, il telefono, la città, lo stato, il paese, alcuni attributi. Allo stesso modo, abbiamo prodotto con ID prodotto, nome, prezzo, unità in magazzino, unità in ordine, livello di riordino. Quindi, quelli sono alcuni attributi o alcune colonne del prodotto e quindi abbiamo anche la tabella degli ordini che ha l'ID cliente e l'ID prodotto come chiavi esterne. Questa è la formulazione di una chiave primaria composita e quindi abbiamo la data dell'ordine, la data di spedizione e alcuni attributi degli ordini stessi. E se lo noti, c'è una relazione uno-a-molti tra cliente e ordine e poi c'è una relazione uno-a-molti tra prodotto e ordine. Allo stesso modo, abbiamo molti-a-uno e molti-a-uno rispettivamente tra ordine e cliente e ordine e prodotto. Quindi, affronteremo questo particolare scenario.
Inizialmente, è stata la relazione molti-a-molti del prodotto del cliente che si è normalizzata in due relazioni uno-a-molti. Quindi, questo è un modello di dati normalizzato e useremo un esempio di questo in cui abbiamo una classe nell'oggetto principale mappato su questo particolare modello di dati. Quindi, parleremo un po' dell'oggetto primario, ma lascia che ti mostri rapidamente l'esempio qui.
Si noti che gli oggetti di dominio sono mappati sul nostro modello di database. Per questo stesso esempio, abbiamo una classe cliente che ha un ID cliente che verrà utilizzato come chiave primaria e quindi abbiamo una raccolta di ordini che rappresenta troppe relazioni con la classe dell'ordine. Allo stesso modo, abbiamo un prodotto che ha attributi di prodotto uguali a questi ID prodotto, nome, prezzo unitario, giusto? E poi abbiamo anche la raccolta degli ordini qui che rappresenta una relazione uno-a-molti e sul lato dell'ordine abbiamo l'ID cliente portato da qui ID prodotto portato da qui e poi abbiamo il cliente che ordina, il cliente molti-a- una relazione e quindi abbiamo l'ordinazione di prodotti così tanti in una relazione catturata come parte dell'oggetto dominio.
Quindi, questa è una delle tecniche che tratterò in dettaglio nelle prossime diapositive. Lascia che ti mostri anche questi oggetti all'interno di Visual Studio, quindi questo è uno della classe.
using Alachisoft.NCache.Web.Caching;
using Alachisoft.NCache.Runtime;
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using Alachisoft.NCache.Runtime.Dependencies;
using System.Collections;
namespace Relationships
{
public class Customer
{
public long CustomerId;
public string CompanyName;
public string Phone;
public string City;
public string State;
public string Country;
// one-to-many list of Order objects
public IList<Order> Orders;
public void CacheCustomer(Cache cache, Customer cust)
{
// Let's preserve "orders"
IList<Order> orders = cust.Orders;
// Let's now empty "orders" so it doesn't get cached with customer
cust.Orders = null;
string custKey = "Customer:CustomerId:" + cust.CustomerId;
cache.Add(custKey, cust, null,
Cache.NoAbsoluteExpiration,
Cache.NoSlidingExpiration,
CacheItemPriority.Default);
// Dependency ensures orders is removed if Cust updated/removed
string[] keys = new string[1];
keys[0] = custKey;
CacheDependency dep = new CacheDependency(null, keys);
string orderskeys = "Customer:Orders:CustomerId:" + cust.CustomerId;
cache.Add(orderskeys, orders, dep,
Cache.NoAbsoluteExpiration,
Cache.NoSlidingExpiration,
CacheItemPriority.Default);
}
public void CacheProducts(Cache cache, double unitPrice, IList<Product> products)
{
// Let's cache each product as seperate item. Later
// we'll search them through OQL
foreach (Product product in products)
{
string productKey = "Product:ProductId:" + product.ProductId;
cache.Add(productKey, product, null,
Cache.NoAbsoluteExpiration,
Cache.NoSlidingExpiration,
CacheItemPriority.Default);
cache.GetGroupData("DummyGroup", "DummySubGroup");
cache.GetByTag(new Alachisoft.NCache.Runtime.Caching.Tag("DummyTag"));
}
}
public IList<Product> FindProducts(Cache cache, double unitPrice)
{
string query = "SELECT Relationships.Product WHERE this.UnitPrice >= ?";
Hashtable values = new Hashtable();
values.Add("UnitPrice", unitPrice);
ICacheReader products = cache.ExecuteReader(query, values, true);
IList<Product> prodList = new List<Product>();
// For simplicity, assume that list is not very large
while (products.Read())
{
prodList.Add((Product)products.GetValue(1));// 1 because on 0 you'll get the Cache Key
}
return prodList;
}
}
}Una cosa che consiglierei è di decorare queste classi con tag serializzabili, giusto? Quindi, devi memorizzarli nella cache, giusto? Quindi, questi oggetti di dominio dovrebbero essere serializzati perché questi sono quelli che viaggeranno avanti e indietro tra l'applicazione client e la cache distribuita.
Quindi, abbiamo la classe del cliente, abbiamo la classe del prodotto, proprio qui. Un elenco di ordini e abbiamo una classe d'ordine che ha anche tutti gli attributi mostrati nella diapositiva della presentazione.
Cos'è l'Oggetto Principale?
Successivamente, parleremo dell'oggetto primario. Ora che abbiamo mostrato alcuni oggetti principali che sono mappati su questo modello di dati di dominio. Ti mostreremo alcune tecniche per esaminare le relazioni uno-a-molti e molti-a-molti.
Quindi, prima di tutto, parlerò di un termine che userò nelle prossime diapositive.
Oggetto primario, è un oggetto di dominio. È mappato sul tuo database. È un punto di partenza della tua applicazione, ad esempio, hai un oggetto cliente e quindi se hai bisogno di ordini hai bisogno che il cliente inizi, giusto? Quindi, è il primo oggetto che la tua applicazione recupera e tutti gli altri oggetti correlati a questo verranno portati in relazione a questo, giusto?
Un altro esempio potrebbe essere se stai elaborando gli ordini correttamente, quindi potresti voler recuperare gli ordini in quell'unità di elaborazione e quindi vorresti conoscere il cliente che l'ha ordinato per spedire quel particolare ordine, giusto? Quindi, in tal caso, l'ordine diventa il tuo oggetto principale e quindi ha una relazione molti a uno o ha una relazione con uno dei clienti che ha effettivamente ordinato quel particolare ordine o tutti i prodotti all'interno di quell'ordine. Quindi, sarà in un modo o nell'altro, ma daremo useremo un oggetto primario che verrà memorizzato nella cache e quindi renderemo altri oggetti dipendenti da quello. Questo è l'approccio che seguirà.
Relazioni nella cache distribuita
Quindi, iniziamo davvero con questo. Quindi, prima di tutto, parleremo delle relazioni uno-a-uno e molti-a-uno all'interno della cache distribuita che è lo scenario più comune, giusto? Quindi, un'opzione è quella di memorizzare nella cache gli oggetti correlati con l'oggetto primario. Ora che hai visto i nostri oggetti di dominio, abbiamo un elenco di ordini come parte dei clienti. Quindi, se popolamo questi ordini e il cliente ha quegli ordini come parte di esso, se memorizzi il cliente come un singolo oggetto nella cache che contiene tutti gli ordini come parte di esso, giusto? Quindi, questo avrebbe portato a termine il lavoro.
Oggetto correlato alla cache con oggetto principale
Quindi, ecco un esempio di codice per questo.
// cache order along with its OrderingCustomer and OrderedProduct
// but not the "Orders" collection in both of them
public void CacheOrder(Cache cache, Order order)
{
// We don't want to cache "Orders" from Customers and Product
order.OrderingCustomer.Orders = null;
order.OrderedProduct.Orders = null;
string orderKey = "Order:CustoimerId:" + order.CustomerId
+ ":ProductId:" + order.ProductId;
cache.Add(orderKey, order, null,
Cache.NoAbsoluteExpiration,
Cache.NoSlidingExpiration,
CacheItemPriority.Default);
}Abbiamo un ordine cache, impostiamo il cliente che effettua l'ordine all'interno dell'ordine su "null". Tutto ok! Quindi, che non abbiamo ordini che hanno anche un riferimento al cliente. È ridondante. Questa non è una buona pratica di programmazione, ma è solo per farla rispettare. Non vogliamo ordini cache dal cliente e ID prodotto. Quindi, vogliamo solo avere un cliente aggiunto nella cache e quindi vorremmo solo avere ordini come parte di quello.
Allora, diamo un'occhiata a questo, giusto? Quindi, lo impostiamo su null e quindi lo memorizziamo semplicemente o se non lo impostiamo su null questo può effettivamente avere un riferimento a quello. Allo stesso modo, se abbiamo un cliente, giusto? quindi se non impostiamo l'ordine su null anche se questo è un oggetto separato ma se memorizziamo semplicemente questo cliente, lascia che ti porti a questo, poiché ha un elenco di ordini, se memorizziamo semplicemente questo cliente come singolo oggetto nella cache, ha la nostra raccolta di ordini come parte di quell'oggetto. Anche se lo sto impostando null per un altro esempio, ma solo per mostrarti questo caso particolare, puoi ordinare un oggetto grande e avrebbe tutti gli oggetti correlati come parte di quell'oggetto.
Quindi, devi iniziare dal tuo oggetto di dominio, dovresti avere la tua relazione catturata come parte dell'oggetto di dominio e dovresti farlo a prescindere. E, dopo che dovresti memorizzare nella cache, dovresti effettivamente avere un elenco popolato di ordini, un elenco di oggetti correlati come parte di quello. Quindi, questo è l'approccio più semplice che puoi ottenere.
Ci sono alcuni vantaggi che hai un oggetto che rappresenta tutto. Ma ci sono anche alcuni inconvenienti. Sarebbe un oggetto di dimensioni maggiori. In alcuni casi hai solo bisogno di un cliente ma finiresti per ricevere ordini come parte di questo. Avrai a che fare con un carico utile maggiore. E non hai ordini granulari come elementi separati nella cache, quindi dovresti sempre occuparti della raccolta di ordini anche se sei interessato solo a uno, giusto? Quindi, questo è un approccio. Questo è il punto di partenza.
Oggetti correlati alla cache separatamente
In secondo luogo, l'oggetto pesato nella cache viene memorizzato nella cache come elemento separato.
public void CacheOrder(Cache cache, Order order)
{
Customer cust = order.OrderingCustomer;
// Set orders to null so it doesn't get cached with Customer
cust.Orders = null;
string custKey = "Customer:CUstomerId:" + cust.CustomerId;
cache.Add(custKey, cust, null,
Cache.NoAbsoluteExpiration,
Cache.NoSlidingExpiration,
CacheItemPriority.Default);
// Dependency ensures order is removed if Cust updated/removed
string[] keys = new string[1];
keys[0] = custKey;
CacheDependency dep = new CacheDependency(null, keys);
string orderKey = "Order:CustomerId:" + order.CustomerId
+ ":ProductId:" + order.ProductId;
cache.Add(orderKey, order, dep,
Cache.NoAbsoluteExpiration,
Cache.NoSlidingExpiration,
CacheItemPriority.Default);
}Un esempio è la classe dell'ordine in cui abbiamo l'ordine nella cache, giusto? Quindi, questo è l'esempio in cui abbiamo un cliente. Prima di tutto, giusto? E poi memorizziamo il cliente come un unico oggetto, puoi vedere che abbiamo ottenuto l'ordine e quindi dall'ordine abbiamo estratto il cliente e quindi abbiamo impostato la raccolta degli ordini all'interno di quell'oggetto cliente su null, giusto? Quindi, questo è qualcosa che dovresti fare all'interno del costruttore, ma viene fatto qui solo per imporre che questo oggetto cliente non abbia questo ordine come parte di quello. E poi memorizzi questo cliente come un unico oggetto. Quello che stiamo facendo qui è creare una chiave cliente che è cliente, ID cliente, il parametro di runtime e quindi archiviare il nostro cliente come un singolo oggetto nella cache.
La prossima cosa che stiamo facendo è creare una dipendenza dalla cache. Quindi, abbiamo parlato di due passaggi che volevamo fare: un passaggio era mappare il tuo modello di dati sul tuo oggetto di dominio, quindi i tuoi oggetti di dominio dovrebbero rappresentare una tabella relazionale nel database e quindi una volta che pianifichi di memorizzarli nella cache, hai l'oggetto primario in questo caso è il cliente e quindi abbiamo ordini che sono correlati al cliente nella relazione uno-a-molti. Puoi creare una dipendenza tra il cliente e la raccolta degli ordini con l'aiuto di un oggetto di dipendenza della cache. Crei una dipendenza dalla cache. Questa stessa dipendenza dalla cache accetta due parametri; il primo è il file, giusto? Quindi, può dipendere dal nome del file e può anche dipendere dalla chiave, giusto? Quindi, impostiamo il primo parametro su null. Quindi, non vogliamo che dipenda da alcun file.
C'è un'altra caratteristica che dentro NCache dove puoi rendere gli elementi dipendenti da un determinato file system alcuni file sul tuo file system. E, quindi, se si utilizza la dipendenza basata sulla chiave, è necessaria la chiave dell'elemento padre da cui l'elemento figlio verrà reso dipendente. E, quindi, costruiamo la chiave dell'ordine della raccolta dell'ordine. Abbiamo l'intera raccolta di ordini proprio qui che viene trasmessa a questo metodo e quindi chiamiamo semplicemente Cache.Add order.
Ora cliente e ordine sono correlati tra loro. Abbiamo un elenco di ordini di questo cliente che sono rappresentati come un oggetto separato nella cache, quindi ogni volta che hai bisogno di tutti gli ordini di questo particolare cliente devi solo usare questa chiave. Tutto quello che devi fare è chiamare, lasciami usare questo esempio proprio qui. Mi dispiace! Puoi chiamare Cache.Get e quindi passare semplicemente la chiave dell'ordine e questo ti porterebbe a questo particolare ordine che abbiamo costruito all'interno di questo metodo, giusto?
Quindi, questo è ciò di cui hai bisogno per recuperare contemporaneamente tutta la raccolta di tutti gli ordini di questo particolare cliente. Ma cosa succede se il cliente subisce un cambiamento? Se il cliente viene aggiornato, la raccolta degli ordini non deve rimanere nella cache. Può essere rimosso o in alcuni casi può anche essere aggiornato, giusto?
Quindi, questo è il nostro approccio numero due che è più sofisticato in termini di archiviazione, in termini di usabilità e mappa anche due record nella nostra relazione di relazione uno-a-molti o relazione Molti-a-uno. Potrebbe essere anche un altro modo, di cui parleremo tra un po', dove puoi avere elenchi di ordini e ogni ordine può essere mappato su quei singoli ordini può essere mappato su quegli ordini di ID multipli possono essere mappati su un cliente se l'ordine è l'oggetto principale per quel particolare codice dell'applicazione. Ora questo definisce una relazione tra cliente e ordini.
Alcuni dettagli in più sulla funzione di dipendenza dalla cache.
Se vado qui, è prima di tutto esposto ma con l'aiuto di Alachisoft.NCache.Runtime.Dependencies e questo è uno degli overload che usi e quindi usi semplicemente questo metodo particolare, proprio qui. E il comportamento di questo è in modo tale da consentirti di monitorare semplicemente la dipendenza unidirezionale tra gli oggetti e potrebbe anche essere collegato a cascata come discusso in precedenza nella presentazione.
Uno a Molti Relazione
Successivamente, parleremo di relazioni uno-a-molti. Dato che abbiamo parlato di uno a uno o molti a uno in cui avevamo un ordine e poi avevamo un cliente, quindi questo è simile a uno a molti nella maggior parte dei casi ma poiché era il punto di partenza era l'ordine e quindi abbiamo inserito il cliente, abbiamo memorizzato il cliente e quindi memorizziamo la raccolta degli ordini e quindi abbiamo definito una relazione molti-a-uno tra la raccolta degli ordini e quel cliente.
Ora, la relazione uno-a-molti sarà molto simile a quella di cui abbiamo discusso. La nostra prima opzione è memorizzare nella cache la raccolta di oggetti come parte dell'oggetto principale, quindi il cliente è il tuo oggetto principale, l'ordine dovrebbe farne parte.
Il secondo elemento è che i tuoi oggetti correlati sono memorizzati nella cache separatamente ma singoli elementi nella cache, giusto?
Uno a molti: raccolta di oggetti correlati alla cache separatamentepublic void CacheCustomer(Cache cache, Customer cust)
{
// Let's preserve "orders"
IList<Order> orders = cust.Orders;
// Let's now empty "orders" so it doesn't get cached with customer
cust.Orders = null;
string custKey = "Customer:CustomerId:" + cust.CustomerId;
cache.Add(custKey, cust, null,
Cache.NoAbsoluteExpiration,
Cache.NoSlidingExpiration,
CacheItemPriority.Default);
// Dependency ensures orders is removed if Cust updated/removed
string[] keys = new string[1];
keys[0] = custKey;
CacheDependency dep = new CacheDependency(null, keys);
string orderskeys = "Customer:Orders:CustomerId:" + cust.CustomerId;
cache.Add(orderskeys, orders, dep,
Cache.NoAbsoluteExpiration,
Cache.NoSlidingExpiration,
CacheItemPriority.Default);
}Quindi, questa è una raccolta separata, abbiamo ordini, abbiamo un oggetto cliente qui uno a molti e il cliente ha ordini, ne abbiamo ricavato la raccolta e quindi imposteremo gli ordini del cliente su null in modo che il cliente sia un e oggetto, un oggetto principale, la raccolta degli ordini è un oggetto separato e quindi si archivia il cliente, si archivia la dipendenza della cache dei dati e si archiviano gli ordini. Quindi, sarà uno a molti l'intera collezione.
Uno a molti: memorizza nella cache ogni oggetto nella raccolta correlata separatamenteIl secondo approccio è che questa raccolta può anche essere scomposta.
public void CacheCustomer(Cache cache, Customer cust)
{
// Let's preserve "orders"
IList<Order> orders = cust.Orders;
// Let's now empty "orders" so it doesn't get cached with customer
cust.Orders = null;
string custKey = "Customer:CustomerId:" + cust.CustomerId;
cache.Add(custKey, cust, null,
Cache.NoAbsoluteExpiration,
Cache.NoSlidingExpiration,
CacheItemPriority.Default);
// Dependency ensures orders is removed if Cust updated/removed
string[] keys = new string[1];
keys[0] = custKey;
CacheDependency dep = new CacheDependency(null, keys);
// Let's cache each order as seperate item but assign it
// a group so we can fetch all orders for a given customer
foreach (Order order in orders)
{
string orderKey = "Order:CustomerId:" + order.CustomerId
+ ":ProductId:" + order.ProductId;
CacheItem cacheItem = new CacheItem(order);
cacheItem.Group = "Customer:CustomerId:" + cust.CustomerId;
cacheItem.Dependency = dep;
cache.Add(orderKey, cacheItem);
}
}La raccolta degli ordini può essere separata, ogni elemento all'interno di tale raccolta può essere un elemento separato nella cache. Quindi, in questo caso useremmo semplicemente lo stesso approccio. Otterremo i clienti, otterremo gli ordini, memorizzeremo il cliente, creeremo una dipendenza di quel cliente utilizzando la dipendenza dalla chiave e quindi itereremo attraverso tutti gli ordini.
Fammi solo passare attraverso il metodo del cliente della cache proprio qui perché è più intuitivo qui. Quindi, otteniamo la raccolta degli ordini da esso, impostiamo gli ordini dei clienti su null in modo che i clienti riguardino solo il cliente, memorizziamo il cliente nella cache usando la cache. Aggiungi la chiave, costruisci una dipendenza della cache attorno a una particolare chiave del cliente e quindi ripetiamo semplicemente. C'è un giro qui intorno. Dovremmo effettivamente iterarlo e questo è effettivamente meglio che lo ripetiamo e quindi lo memorizziamo semplicemente come singoli elementi nella cache in modo che l'ordine abbia la sua chiave in ogni ordine è un elemento separato nella cache. E poi un'altra cosa che abbiamo fatto è che abbiamo effettivamente raggruppato questi che chiamiamo elementi della cache aggiungi gruppo e anche l'ID cliente è un gruppo. Quindi, in realtà stiamo gestendo anche una raccolta all'interno della cache.
Fammi vedere se ho.. ecco, in realtà, per esempio, abbiamo questo proprio qui. Potremmo effettivamente memorizzare nella cache questi prodotti, questo è un altro esempio, in cui abbiamo girato tutta la raccolta di prodotti e poi li abbiamo archiviati individualmente e poi abbiamo effettivamente messo tutto in un gruppo, giusto?
Quindi, questo prodotto che viene archiviato come articolo può anche essere archiviato in questo modo dove abbiamo un ProdCacheItem. La mia tastiera sta suonando, quindi per favore abbi pazienza! Usiamo questo per ora e poi lo farò semplicemente. Posso effettivamente aggiungere un gruppo. Quindi, questo è lungo questo mi consentirebbe effettivamente di impostare un gruppo per questo. Diciamo un gruppo fittizio ora. Se conservo questo articolo della cache e potrebbe effettivamente avere un prodotto come articolo per questo, giusto? Quindi, invece di memorizzare l'oggetto grezzo reale, posso persino organizzarlo in un gruppo. Posso semplicemente usare l'elemento della cache del prodotto. Ecco qua! Destra? Quindi, ora in realtà è o invece di usare il gruppo fittizio diciamo gruppo di prodotti giusto e quando ho bisogno di recuperarlo posso semplicemente usare il gruppo di prodotti e mi prenderebbe tutti gli articoli di questa collezione in una volta. Sebbene questi vengano archiviati individualmente, si tratta di singole Cache. Ricevi chiamate, i singoli prodotti all'interno della raccolta di prodotti vengono ordinati individualmente, ma posso organizzarli in un gruppo in una raccolta e quindi recuperarli. Ma la cosa bella di questo è che sta ancora usando una dipendenza, giusto? Quindi, utilizza una dipendenza di un cliente da quei singoli articoli.
Quindi, prendiamo un esempio, abbiamo un cliente che ha centinaia di ordini. Quindi, in totale avremmo un articolo per cliente nella cache, avremmo centinaia di ordini archiviati separatamente come cento articoli nella cache e c'è una dipendenza unidirezionale tra quell'unico cliente e cento ordini. Se rimuovi quel cliente dalla cache, cento ordini verrebbero invalidati contemporaneamente. E ora hai il vantaggio di recuperare i singoli ordini, se necessario. Quindi, puoi interagire con quegli elementi individualmente. Un elemento alla volta. Hai bisogno di un determinato ordine che puoi elaborare e quando hai bisogno dell'intera raccolta di quegli ordini in una volta, puoi semplicemente chiamare Cache.GetGroupData e fornire il gruppo di prodotti e quindi il sottogruppo potrebbe essere qualsiasi cosa. Potrebbe essere nullo anche e quindi puoi anche usare il tag.
Per esempio; l'altro modo per gestirlo è che usi l'articolo del prodotto e crei un tag per esso, giusto? E poi tu... c'è un... yeah! eccolo lì e puoi fornire un tag che può essere simile al tag del prodotto, giusto? e quindi puoi associare questo come parte di quello.
Quindi, questo funzionerebbe effettivamente sulle stesse righe e puoi anche chiamare i metodi get by tag e questo si prenderebbe cura di tutti gli elementi contemporaneamente. Ti porterebbe tutti gli oggetti in una volta. Quindi, questo ti darebbe un maggiore controllo sulla disposizione dei dati nella cache e quindi mantenendo intatta una relazione uno-a-molti.
Quindi, questo si occupa di uno scenario molto particolare in cui abbiamo una relazione uno-a-molti e abbiamo un oggetto aggiunto e quindi abbiamo quegli elementi sui molti lati che la raccolta ha memorizzato individualmente gli elementi di quella raccolta archiviati individualmente nella cache e quindi hai ancora una dipendenza e quindi hai ancora un tipo di comportamento di raccolta per quello con quegli elementi correlati. Quindi, quegli elementi sono correlati tra loro, formano una collezione e quindi hanno la nostra relazione con un altro oggetto in una Formulazione uno-a-molti. Quindi, questo frammento di codice, un'API intuitiva molto semplice si prende cura di tutti questi scenari. Hai una relazione uno-a-molti catturata con l'aiuto della dipendenza dalle chiavi. Hai organizzato quegli elementi individualmente nella cache, ma li hai comunque inseriti in una raccolta logica di gruppi o tag e quindi quando hai bisogno di quegli elementi individualmente che chiami cache inizia a ottenere, giusto?
Quindi, un modo per ottenere questo oggetto è chiamare Cache.Get, giusto? e usa la chiave che è la chiave del prodotto qui, giusto? Quindi, questo ti porterebbe questo particolare prodotto che viene archiviato con questa particolare chiave, giusto? E l'altra opzione è che hai bisogno di tutti gli elementi all'interno di quella raccolta contemporaneamente in modo da poter usare Cache.GetGroupData. Quindi, può darti un comportamento di raccolta e allo stesso tempo può anche darti la gestione individuale di quegli articoli correlati.
Quindi, questo dovrebbe occuparsi delle collezioni e degli articoli all'interno della collezione e uno a molti in una volta sola.
Molte-a-molte relazioni
Successivamente, abbiamo una relazione molti-a-molti.
Le relazioni molti-a-molti non esistono in genere negli oggetti di dominio. Verrà sempre normalizzato anche in due relazioni uno-a-molti nel database. In effetti, avevamo una relazione molti-a-molti tra cliente e prodotti. Relazioni molti-a-molti che abbiamo normalizzato con l'aiuto di un oggetto intermedio in due relazioni uno-a-molti. Quindi, abbiamo uno a molti qui e molti a uno qui tra l'ordine del cliente e l'ordine per prodotto, rispettivamente. Quindi, è così che affronteresti molti-a-molti. Quindi, finirebbe per utilizzare relazioni uno-a-uno molti-a-uno o uno-a-molti.
Quindi, questo dovrebbe prendersi cura delle tue relazioni molti-a-molti.
Gestione delle raccolte nella cache distribuita
Il prossimo è che avevi una collezione, l'abbiamo già toccato con l'aiuto del nostro esempio di prodotto, ma lo esaminerò ancora per memorizzarlo nella nostra collezione come un unico articolo.
Ad esempio, immagazzini il prodotto. Esaminiamolo, vero?
public void CacheProducts(Cache cache, double unitPrice, IList<Product> products)
{
// cache the entire collection as one item
string productskey = "Product:UnitPrice:" + unitPrice;
cache.Add(productskey, products, null,
Cache.NoAbsoluteExpiration,
Cache.NoSlidingExpiration,
CacheItemPriority.Default);
}
public IList<Product> FindProducts(Cache cache, double unitPrice)
{
string productskey = "Product:UnitPrice:" + unitPrice;
IList<Product> products = (IList<Product>)cache.Get(productskey);
return products;
}Quindi, hai prodotti nella cache, quindi crei un codice Product Key e quindi hai un elenco di prodotti che viene portato qui e quindi li metti nella cache e hai un singolo oggetto. E, come ho spiegato in precedenza, funzionerà, ti farebbe solo portare a termine il lavoro e funzionerebbe principalmente quando hai bisogno di tutti gli elementi di quell'elenco contemporaneamente. Non sei interessato ai singoli elementi di quell'elenco. Ti interessa interamente l'intero elenco del negozio come un unico articolo, ma renderà l'oggetto più pesante e non ti darebbe supporto per la codifica, la ricerca e questo è il nostro prossimo argomento. Poiché è un elenco generico, elenco, contiene un prodotto ma per NCache questa è solo una lista, io elenco. Destra! Quindi, non sei in grado di individuare l'oggetto all'interno di quell'elenco e quindi gli attributi e quindi non hai la possibilità di cercare in base a tali attributi.
Quindi, un modo più sofisticato di gestire questo problema consiste nel memorizzare nella cache ogni elemento della raccolta separatamente. Che abbiamo trattato come parte del nostro esempio precedente, ma esaminiamolo ancora una volta. Per esempio; esaminiamo i prodotti della cache ancora una volta e questo li memorizzi semplicemente come singoli articoli. Fammi trovare questo esempio per te! BENE! Eccolo.
Quindi, prima di tutto, conserveremo i prodotti singolarmente, giusto? Avremo una chiave costruita attorno a quella per i singoli prodotti. La cosa bella di questo è che tutti i singoli elementi della raccolta di prodotti sono archiviati come singoli elementi nella cache in modo da poterli recuperare usando la chiave che è l'overload per quello, il metodo per quel Cache.Get. Puoi anche recuperarli come raccolta. È qualcosa di cui abbiamo discusso in grande dettaglio. Un'altra opzione è che esegui anche query e queste query di ricerca simili a SQL possono essere applicate direttamente agli attributi degli oggetti. E puoi farlo solo se li hai archiviati individualmente tutti gli articoli all'interno della raccolta sono archiviati come singoli articoli. Li associ a un oggetto di dominio, in questo caso un prodotto, e i prodotti all'interno di una raccolta di prodotti vengono archiviati singolarmente come elementi separati nella cache.
Ora puoi indicizzare il prezzo unitario del prodotto, l'ID prodotto e quindi eseguire una query come questa. Seleziona prodotto, che è lo spazio dei nomi del prodotto, dove imposta il prezzo unitario uguale a un parametro di runtime. E poi puoi chiamare Cache.ExecuteReader e questo ti recupererà tutti i prodotti che puoi scorrere e continuare a recuperare anche nella tua applicazione. Allo stesso modo, puoi anche dire dove This.Tag. Se hai associato un tag sopra di esso, puoi anche eseguire query su quello. Questo è un altro vantaggio dei tag insieme ai vantaggi di recupero, vantaggi in termini di prestazioni, ti dà anche flessibilità dal punto di vista della ricerca. E i tag ti danno anche Cache.Get da un tag. Ti fornisce tutte le API, ottieni da tutti i tag ottieni da qualsiasi tag, quindi puoi effettivamente recuperare oggetti anche usando queste API di tag. Ma la caratteristica che volevo evidenziare è che li disponi individualmente. Questo è il punto di partenza. Puoi creare raccolte logiche utilizzando Tag o Gruppi. Quindi, il recupero è più facile. Hai bisogno di singoli elementi che chiami Cache.Get. Ottieni gli oggetti in base alla chiave. Hai bisogno di raccolte, usa il gruppo o il tag visualizzato e sopra di esso puoi eseguire query e puoi associare, puoi effettivamente recuperare i nostri articoli in base a un criterio.
In questo caso potrebbe essere il prezzo unitario. Potrebbe essere un prezzo unitario maggiore di 10 e inferiore a cento. Quindi, gli operatori logici sono supportati, potresti anche avere un po' di aggregazione, conteggio, somma, ci sono alcuni ordini di ordinamento da parte di un gruppo per operatore simile in funzione, quindi è piuttosto eccitante esteso per quanto riguarda il supporto è simile a SQL è un sottoinsieme di Query SQL ma è molto flessibile nell'uso e ti offre molta facilità d'uso in termini di elementi di cui hai bisogno. Non è più necessario lavorare con le chiavi. Quindi, ciò accadrebbe solo se utilizzi semplicemente ogni elemento della raccolta archiviato separatamente nella cache. Spero che aiuti.
Per iniziare NCache
Questo completa il nostro argomento di oggi. Verso la fine, ti mostrerò solo cinque semplici passaggi per iniziare NCache per andare oltre NCache configurazioni e quindi essere in grado di eseguire queste API in un'applicazione reale.
Bene! Quindi, ho intenzione di iniziare rapidamente con questo. Ho lo strumento di gestione aperto. A proposito, abbiamo recentemente rilasciato, in realtà abbiamo appena rilasciato la 4.9. Quindi, questa è la nostra versione più recente, quindi potresti voler iniziare con quella. Quindi, tutto ciò che devi fare è creare una cache, per nome, scegliere dopo, scegliere una topologia di memorizzazione nella cache, la cache di replica della partizione è la più adatta, l'opzione asincrona per la replica e qui specificare i server che ospiteranno questa cache. Ho già installato la demo uno e due NCache.
Quindi, il primo passo è scaricare e installare NCache. Il secondo passaggio consiste nel creare una cache denominata. Quindi, lo esaminerò, manterrò tutto predefinito perché questo non è l'ambito principale della discussione oggi. Esaminerò solo i valori predefiniti e le dimensioni della cache che si trova su ciascun server. Basta configurare le impostazioni di base e scegliere la finitura.
Il terzo passaggio consiste nell'aggiungere un nodo client. Userò solo la mia macchina. Vedi se ho accesso a questo, sì! Tutto ok! Quindi, quella è la mia macchina proprio qui. L'ho aggiunto, quindi il passaggio tre è completo. Tutte le configurazioni sul server e nel client sono complete. Ora devo avviare e testare questo cluster di cache come parte del mio passaggio 4, quindi lo esaminerò e quindi lo userò nell'applicazione reale. Quindi, è così semplice iniziare NCache.
Ti mostrerò alcuni contatori veloci per mostrarti le cose in azione e poi concluderemo rapidamente anche la presentazione. Farò clic con il pulsante destro del mouse e sceglierò le statistiche che aprirebbero i contatori delle prestazioni e posso anche aprire strumenti di monitoraggio NCache monitor, viene installato con NCache.
Quindi, è guidato dal contatore delle prestazioni. Fornisce contatori delle prestazioni lato server e anche contatori lato client. E, sul lato dell'applicazione client, posso eseguire questa applicazione dello strumento di stress test che viene nuovamente installata NCache. Prende il nome poiché ci sono configurazioni fatte in modo che si connetta automaticamente alla cache e inizi a simulare il carico sul mio cluster di cache. Ecco qua! Quindi, abbiamo il carico della richiesta in arrivo qui e sull'altro server.
Allo stesso modo, abbiamo l'attività mostrata su questo server così come i client collegati al server visualizzatore di report e al client. E poi puoi anche avere i tuoi dashboard personalizzati in cui puoi collegare uno di questi contatori. Ad esempio, i registri API sono un buon esempio. Registra tutte le richieste che vengono eseguite sulla cache in questo momento in tempo reale, giusto?
Quindi, questo è un rapido esempio di utilizzo di questi contatori dal menu principale di sinistra. Come ho detto, questo è solo per farti un'idea di come appare la memorizzazione nella cache. Ora posso effettivamente usarlo in un'applicazione reale. Posso usare la mia macchina proprio qui e posso semplicemente usare l'esempio di funzionamento di base che viene installato NCache. Tutto quello che devi fare è che ci siano diverse cartelle di aghi all'interno delle operazioni di base di campioni .NET, per quanto riguarda l'utilizzo NCache librerie lato client che puoi usare NCache Pacchetto SDK NuGet. Questo è il modo più semplice per ottenere tutte le risorse lato client.
L'altra opzione è che usi effettivamente Alachisoft.NCache.Runtime e Alachisoft.NCache.Librerie Web Tu stesso. Tu includi quelli. Questi sono qualcosa con cui queste sono le librerie che iniziano NCache nelle cartelle della cache di Microsoft. Una volta installato NCache ne farebbe parte e poi ti mostrerò rapidamente cosa devi fare. Ecco qua! Quindi, la prima cosa di cui hai bisogno è aggiungere riferimenti a queste due librerie; runtime e web, includi questi spazi dei nomi che ho appena evidenziato. Web.caching e quindi da quel momento in poi questo esempio è abbastanza buono per inizializzare di base la cache che si connette ad esso, creare un oggetto leggendolo, eliminarlo aggiornandolo ogni sorta di operazioni di creazione, lettura, aggiornamento, eliminazione.
Quindi, questo è il modo in cui inizializzi la cache. Questa è la chiamata principale, giusto? È necessario che il nome della cache restituisca un handle di cache e quindi chiami semplicemente la cache o aggiungi tutto in una coppia di valori chiave Cache.Get elementi e quindi per aggiornare la cache degli elementi o inserirli e quindi Cache.delete. Inoltre, ti abbiamo già mostrato alcuni esempi dettagliati sull'utilizzo della dipendenza basata su chiavi utilizzando i tag utilizzando i gruppi che utilizzano SQL come la ricerca. Quindi, questo dovrebbe effettivamente darti alcuni dettagli sulla configurazione dell'ambiente e quindi essere in grado di usarlo in un'applicazione reale.
Questo conclude la nostra presentazione.