Redis vs NCache
Webinar registrato
Di Ron Hussain e Zack Khan
NCache è una cache distribuita nativa .NET Open Source molto popolare tra i .NET ad alta transazione, .NET Core e applicazioni Java. Redis è sviluppato da Redis Labs ed è attualmente utilizzato da Microsoft in Azure. In questo webinar, scopri come NCache ed Redis confrontare tra loro. L'obiettivo di questo webinar è rendere il tuo compito di confrontare i due prodotti più facile e veloce, specialmente per quanto riguarda aspetti qualitativi come funzionalità, prestazioni, scalabilità, alta disponibilità, affidabilità dei dati e amministrazione.
Ecco di cosa tratta questo webinar:
- Prestazioni e scalabilità
- Elasticità della cache (disponibilità elevata)
- Topologie della cache
- SQL e LINQ Ricerca nella cache
- Integrazioni di terze parti (EF, EF Core, NHibernate ecc.)
Oggi abbiamo l'argomento di confrontare due prodotti che sono molto simili ma diversi anche sotto molti aspetti. Quindi, abbiamo NCache che è il nostro principale prodotto di memorizzazione nella cache distribuita per .NET e .NET Core applicazioni e quindi confronteremo dal punto di vista delle funzionalità con Redis. Quindi, abbiamo molto da coprire in questo. Esaminerò molti dettagli tecnici a partire dalla piattaforma e dallo stack tecnologico. Poi parleremo del clustering. Come si confrontano questi due prodotti per quanto riguarda il clustering della cache e quali sono i diversi vantaggi che si ottengono utilizzando questi prodotti e, in confronto, come NCache è meglio e poi parlerò di diverse caratteristiche. Andremo confronto funzionalità per funzionalità per quanto riguarda i diversi casi d'uso in cui è possibile utilizzare questi prodotti e quindi il confronto tra questi due prodotti dal punto di vista del confronto delle funzionalità.
Per questo webinar, ho scelto NCache Enterprise 5.0.2, per quanto Redis preoccupa, ci concentreremo principalmente su Azure Redis. Questo è open source Redis 4.0.1.4. Ma vorrei anche darti dettagli sul Redis progetto open source, nonché Redis lab che è la variante commerciale di Redis. Quindi, confronteremo NCache con tutti questi gusti, ma il nostro obiettivo principale sarebbe Microsoft Azure Redis, il modello ospitato di Redis che puoi ottenere in Microsoft Azure.
Il problema della scalabilità
Quindi, prima di iniziare, esaminerò principalmente i dettagli introduttivi su questi due prodotti. Quindi, perché hai esattamente bisogno di una soluzione di memorizzazione nella cache distribuita?
Quindi, e dopo, andresti avanti e confronterai prodotti diversi. Quindi, in genere è la scalabilità e la sfida delle prestazioni che potresti riscontrare all'interno della tua applicazione. Potrebbe essere che la tua applicazione stia ricevendo molto carico di dati e sebbene il tuo livello dell'applicazione sia molto scalabile, puoi sempre creare una web farm, puoi aggiungere più risorse al livello dell'applicazione ma tutte quelle istanze dell'applicazione devono tornare indietro e parlare con il backup -fine origini dati. E, quando è necessario tornare indietro e parlare con quelle origini dati, è lì che si riscontrano problemi di prestazioni perché i database, in genere i database relazionali sono lenti in termini di gestione del carico transazionale.
C'è un problema di prestazioni ad esse associato e quindi in termini di scalabilità orizzontale, ad esempio, se è necessario disporre di molta capacità di gestione delle richieste o di requisiti in merito a cui dobbiamo gestire molte richieste e le vostre applicazioni stanno generando molti carico dell'utente, il database non è progettato per gestire quel carico transazionale estremo. È molto utile per l'archiviazione, è qui che puoi archiviare molti dati, ma andare in giro con un carico transazionale su quei dati è qualcosa per cui il database non sarebbe un ottimo candidato. Potrebbe soffocare. Ti darebbe lentezza e l'esperienza dell'utente finale potrebbe essere degradata.
Quindi, puoi avere un impatto sulle prestazioni e non hai la possibilità di aumentare la capacità all'interno dell'architettura dell'applicazione.
La soluzione: cache distribuita in memoria (NCache)
La soluzione è molto semplice, si utilizza un sistema di memorizzazione nella cache distribuito in memoria come NCache che è super veloce perché è in memoria. Quindi, rispetto a un database relazionale o un file system o qualsiasi altra fonte di dati che non è basata sulla memoria, se proviene da un disco rispetto alla memorizzazione dei dati nella memoria, in memoria, lo renderà super- veloce. Quindi, il primo vantaggio che ne ottieni è che ottieni prestazioni super veloci NCache.
Il secondo vantaggio è che è un cluster di cache. Non è solo una singola fonte. Puoi iniziare con un server, ma in genere ti consigliamo di avere almeno due server e di creare un cluster di cache e non appena crei quel cluster di cache, migliorerebbe, se distribuiamo il carico su tutti i server e tu continui aggiungendo più server in fase di esecuzione.
Quindi, puoi ridimensionare la tua capacità, puoi, sai, aumentare la capacità in fase di esecuzione aggiungendo più server e utilizzarla anche in combinazione con i tuoi database relazionali di back-end. Non è un sostituto dei tuoi database relazionali convenzionali e parleremo di alcuni casi d'uso in futuro.
Distribuzione cache distribuita (NCache)
Ecco una distribuzione tipica.
sto usando NCache come esempio per ora, ma in fondo in questa presentazione confronteremo come Redis viene distribuito e come NCache viene distribuito e quali sono le flessibilità disponibili all'interno di questi prodotti.
Così per NCache, è molto flessibile. Puoi scegliere di distribuirlo sia su Windows che su ambiente Linux. È disponibile in locale e supportato in ambienti cloud. È disponibile anche in Azure AWS marketplaceS. Quindi, puoi semplicemente ottenere un'immagine preconfigurata di NCache e iniziare con esso. Sono disponibili contenitori Docker per Windows e per Linux, che puoi utilizzare su qualsiasi piattaforma, dove è necessario utilizzarlo.
In genere, le tue applicazioni, indipendentemente dal fatto che siano ospitate in locale o nel cloud, potrebbero essere un servizio app, potrebbe essere un Cloud service, potrebbe essere un microservizio, potrebbe essere un sito Web di Azure, qualsiasi tipo di applicazione può connettersi ad esso nel modello client-server e si trova tra l'applicazione e il database back-end e questo è il modello di utilizzo tipico. L'idea qui è che memorizzeresti i dati all'interno NCache e di conseguenza risparmieresti viaggi costosi nel database di back-end. Si salverebbero i viaggi nel database il più possibile e ogni volta che è necessario accedere al database, si andrebbe sempre al database, si prelevano i dati e li si porta nella cache in modo che la prossima volta che i dati esistono e non si hanno per andare alla banca dati. E, di conseguenza, le prestazioni delle tue applicazioni e la scalabilità complessiva sono migliorate perché ora hai accesso alla memoria che migliora le prestazioni. Hai più server che ospitano e servono le tue richieste, le tue richieste di dati. Quindi, è più scalabile in confronto. E poi, ci sono funzionalità di alta disponibilità e affidabilità dei dati che sono anche integrate NCache protocollo.
NCache può essere ospitato sulle stesse scatole in cui sono in esecuzione le tue applicazioni. Oppure potrebbe essere solo un livello separato. Nel cloud, l'approccio preferito sarebbe quello di utilizzare un livello di cache dedicato separato e quindi le tue applicazioni sono, le istanze dell'applicazione sono in esecuzione sul rispettivo livello. Ma entrambi i modelli sono supportati fino a NCache è preoccupato.
Alcuni numeri di scalabilità. Di recente abbiamo condotto questi test nel nostro laboratorio AWS, dove abbiamo simulato il carico delle richieste di lettura e scrittura e abbiamo continuato ad aumentare il carico e dopo un certo punto, quando abbiamo visto che i server erano al massimo, abbiamo aumentato il numero di server nel cluster di cache. Quindi, da 2 a 3 server e poi da 3 a 4, siamo stati in grado di raggiungere 2 milioni di richieste al secondo con solo 5 NCache server e questo non lo è, questo non era un dato touch-and-go. Si trattava di dati di applicazioni reali, ma simulati nel nostro laboratorio AWS all'interno delle nostre applicazioni. E anche il fattore di latenza è stato molto ottimizzato. Siamo stati in grado di ottenere tutto questo con una latenza di microsecondi. Pertanto, le prestazioni delle singole richieste non sono state ridotte, quando siamo stati in grado di ottenere tutto questo carico.
Casi d'uso comuni: cache distribuita
Alcuni casi d'uso e questo è qualcosa per cui è comune Redis anche ma parlerò di come NCache confronterebbe.
Memorizzazione nella cache dei dati dell'app
Dove si memorizza nella cache quasi tutto ciò che normalmente si recupera dal database back-end e i dati sono presenti nel database e ora si desidera memorizzarlo nella cache. Quindi, per risparmiare viaggi costosi nel database e abbiamo già stabilito che il database è lento e quindi non è molto ottimale in termini di gestione del carico delle transazioni. Abbiamo molte funzionalità di sincronizzazione del database su questa linea, ma in questa ti connetti semplicemente NCache e usa fondamentalmente le nostre API per effettuare la connessione, sai, effettuare chiamate di dati a NCache. Quindi, puoi memorizzare nella cache quasi tutto. Potrebbero essere i tuoi oggetti di dominio, raccolte, set di dati, immagini, qualsiasi tipo di dato relativo all'applicazione può essere memorizzato nella cache utilizzando il nostro modello di memorizzazione nella cache dei dati.
ASP.NET/ASP.NET Core Caching
Poi abbiamo il nostro ASP.NET e ASP.NET Core memorizzazione nella cache specifica. Questo è ancora un caso d'uso tecnico, in cui puoi usarlo per ASP.NET o ASP.NET Core memorizzazione nella cache dello stato della sessione. ASP.NET o ASP.NET Core SignalR Backplane. NCache può essere collegato come backplane. Per ASP.NET Core puoi anche usarlo per la memorizzazione nella cache delle risposte. Interfaccia e sessioni di IDistributedCache IDistributedCache interfaccia, queste due funzionalità sono supportate anche con NCache e per le applicazioni legacy puoi anche usarlo per View State e Output Caching. volevo fare una domanda veloce a modo tuo, Ron.
Siamo entrati, la domanda è fa NCache e Azure supportano un modello di programmazione serverless?
Assolutamente. Questo è qualcosa che in termini di distribuzione di Azure, puoi avere le tue applicazioni distribuite sui server o la tua applicazione, per quanto riguarda la tua parte dell'applicazione, anche quelle potrebbero essere applicazioni serverless. Puoi semplicemente includere i nostri pacchetti NuGet all'interno della tua applicazione e quelle applicazioni possono semplicemente creare NCache chiama ogni volta che ne hanno bisogno. Non devono nemmeno avere alcuna installazione di NCache o avere una configurazione del server per quanto riguarda le risorse dell'applicazione. Ma, per quanto NCache la stessa distribuzione lato server è preoccupata perché NCache è l'origine dati, quindi deve avere una macchina virtuale o un set di macchine virtuali, in cui le tue applicazioni si connettono, recuperano e aggiungono dati.
Quindi, dai server, NCache punto di vista del server cache, come fonte di cui hai bisogno NCache server ma per quanto riguarda le tue applicazioni potrebbero essere rigorosamente serverless e non ci sono problemi. Anche l'architettura dei microservizi. Questo è un esempio molto comune, in cui i microservizi sono numerosi. Potrebbe esserci una funzione di Azure, che sta solo eseguendo e che gestisce molti dati e da cui i dati possono provenire NCache. Quindi, tratti NCache come fonte di dati. Considerando che le tue applicazioni possono essere serverless e NCache è completamente compatibile con quel modello.
Pub/Sub Messaggistica ed Eventi
Quindi un altro caso d'uso è in giro Messaggistica Pub/Sub e che ruota attorno ai microservizi perché questo è uno dei casi d'uso impressionanti in cui è possibile utilizzare la messaggistica per applicazioni serverless. I microservizi sono applicazioni server less accoppiate in modo lasco e costruire una comunicazione tra di loro è una grande sfida. Quindi, puoi utilizzare la nostra piattaforma di messaggistica Pub/Sub, dove puoi utilizzare il nostro meccanismo di propagazione di eventi asincroni basato su eventi. Dove più applicazioni possono pubblicare messaggi NCache e gli abbonati possono ricevere quei messaggi.
Poiché si trova in un meccanismo basato su eventi asincroni, le applicazioni dell'editore non devono attendere il riconoscimento o la consegna dei messaggi e allo stesso modo gli abbonati non devono attendere o eseguire il pole per i messaggi. Ricevono una notifica tramite richiamate quando le notifiche. Quindi, è molto flessibile e questo è un altro caso d'uso in cui puoi usarlo NCache come piattaforma di messaggistica Pub/Sub per le tue applicazioni.
NCache Storia
Qualche dettaglio in più e poi parleremo delle differenze tra NCache ed Redis. NCache è stato lanciato nel 2005. È presente sul mercato da oltre 15 anni. Versione attuale di NCache è 5.0, 15a versione. Abbiamo tanti, tanti clienti. NCache è disponibile anche nell'edizione Open Source. Che puoi scaricare dal nostro sito Web e dal repository GitHub.
Alcuni NCache Clienti
Alcuni dei nostri clienti. Puoi anche ottenere un elenco dettagliato.
Piattaforma e tecnologia
Successivamente parleremo di come NCache confronta con Redis e il primo segmento è costruito su alcuni dettagli introduttivi sulla tecnologia in generale. Queste saranno informazioni sulla tecnologia di memorizzazione nella cache distribuita. Ora ci concentreremo direttamente su come NCache confronta con Redis e ho alcuni segmenti che ho formulato.
Quindi, la prima sezione che abbiamo definito è la piattaforma e la tecnologia e inizialmente ho menzionato che stiamo prendendo di mira NCache 5.0.2. Quindi, NCache 5.0 SP2 è la versione principale attiva NCache sito e da Redis punto di vista useremo Azure Redis come confronto e parleremo anche di Open Source e Redis Lab come parte di questo. La maggior parte di questi dettagli sono comuni per diversi gusti di Redis.
Cache .NET nativa
Quindi, provenendo da un background Azure, se hai intenzione di scegliere un prodotto così, la cosa numero uno sarebbe la compatibilità con la piattaforma.
Così, NCache stesso è scritto al 100% in .NET. È un nativo .NET o.NET Core prodotto, per quanto riguarda le tue applicazioni, giusto. Quindi, fondamentalmente, è scritto in .NET e principalmente per applicazioni .NET e viene distribuito su Windows Server 2016, 2019 e persino 2012. Solo prereq per NCache is .NET framework or .NET Core per questo motivo. Considerando che, per Redis, è scritto in C++. NCache è scritto in .NET. È sviluppato al 100%, in realtà C# è il principale linguaggio tecnologico che stiamo usando ed è .NET nativo al 100% e .NET Core. Mentre Redis è una soluzione basata su C++ Linux.
Quindi, venendo dal punto di vista di Windows, dal background di Windows e se le tue applicazioni sono scritte in .NET, la scelta naturale sarebbe quella di utilizzare un prodotto scritto anche in .NET in modo da essere sullo stesso stack tecnologico. Non è necessario avere molte variazioni all'interno dello stack di sviluppo dell'applicazione. Quindi, questo è un problema o una differenza tra questi due prodotti.
Il secondo aspetto è Windows contro Linux e quindi sai cosa è disponibile NCache e su cosa è disponibile Redis lato. Windows, dal punto di vista NCache distribuzione, che è una distribuzione preferita, ma abbiamo anche una distribuzione Linux disponibile con l'aiuto del nostro .NET Core Rilascio del server. Quindi, siamo completamente compatibili su Windows 2012, 2016, 2019. Le nostre immagini Docker sono disponibili anche per la variante Windows. Una variante di NCache. Quindi, puoi semplicemente scaricare la nostra immagine Docker e girare semplicemente l'immagine di Windows NCache se necessario e lo supportiamo pienamente nell'ambiente di produzione. È un supporto ufficiale da parte nostra. Considerando che, se si confronta Redis anche in Microsoft Azure il Redis è ospitato su Linux. L'approccio preferito, il modello di distribuzione preferito è Linux per Redis. La variante di Windows è un progetto di terze parti. Microsoft Open Tech ne ha una versione trasferita. Non c'è supporto ufficiale da Redis si. Il progetto stesso è accantonato. È buggato, instabile e persino l'azzurro Redis, come discusso in precedenza, utilizza la versione Linux e il grosso problema è che non hai un supporto ufficiale dal Redis, Creatori di Redis o da un punto di vista, se vuoi usare il progetto open source e vuoi implementarlo da solo, è lì che vedresti molti problemi.
Come parte di questo, vorrei anche evidenziare un altro aspetto, se si utilizza NCache in locale e ora vuoi eseguire la migrazione da locale e vuoi usarlo in Azure, lo stesso software funziona così com'è. Quindi, non è necessario alcun cambiamento dal trasloco NCache da locale ad Azure. Allo stesso modo, all'interno dei fornitori di cloud se prevedi di utilizzare NCache su Azure puoi semplicemente migrare ad AWS, se necessario. Perché lo stesso identico software è disponibile su tutta la linea su tutte le piattaforme. Considerando che, per quanto Redis è preoccupato, Azzurro Redis è un modello ospitato che viene distribuito su Linux per quanto riguarda la distribuzione del back-end, ma non hai la stessa variante disponibile in locale. Quindi, devi fare i conti con l'open source Redis o qualche fornitore di terze parti. Anche tu devi andare con una variante commerciale, che è un prodotto completamente diverso.
Quindi, il punto principale che vorrei sottolineare qui è quello Redis on-premise che è open source o una versione commerciale rispetto a Redis in azzurro o Redis in AWS che è Elastic Cache. Questi sono prodotti completamente separati. Quindi, c'è una transizione, ci sono molti cambiamenti. Non puoi trasferire Redis da un ambiente all'altro senza subire modifiche. Mancano alcuni set di funzionalità. Alcune API sono diverse. Il modello di distribuzione è completamente cambiato tra questi prodotti. Quindi, non ci sono modifiche se mantieni NCache on-premise su Windows o Linux e ora vuoi migrare e passare ad Azure, sarebbe esattamente lo stesso prodotto e ora vuoi cambiarlo da Azure ad AWS, vuoi cambiare il fornitore del cloud, è più flessibile rispetto a Redis. Così, NCache è molto più flessibile.
supporto Linux, NCache è completamente compatibile, ufficialmente supportato. Anche le prestazioni sono testate e le prestazioni di Linux sono super veloci come alla pari NCache Su Windows. Abbiamo immagini Docker disponibili. Completamente supportato nella produzione e disponiamo di strumenti di monitoraggio e gestione completamente integrati che puoi, questi sono strumenti di gestione e monitoraggio web a cui puoi accedere da qualsiasi luogo. Quindi, anche le tue distribuzioni Linux possono essere gestite e monitorate come faresti con le tue distribuzioni Windows NCache. Linux è supportato anche su Redis. Quindi, il suo supporto alla produzione disponibile da Redis Laboratorio. Azzurro Redis è ospitato anche sulla versione Linux. Quindi, è supportato dal venditore stesso.
Il secondo aspetto dopo la piattaforma è ancora il .NET e .NET Core, lo stack tecnologico. Abbiamo un Cliente ufficiale disponibile. L'abbiamo implementato. Lo supportiamo pienamente e se ci sono set di funzionalità ed è per questo NCache è compatibile su tutta la linea. Quindi, se scegli ambienti on-premise o Azure o AWS, avresti lo stesso sapore di NCache e il suo Cliente disponibili su tutta la linea. E, se ci sono modifiche che devono essere apportate, forniremo tali modifiche ufficialmente perché possediamo tutto, oltre al progetto è interessato. Considerando che, per Redis è una terza parte. Quindi, per lingue diverse, il supporto proveniente da lingue diverse arriva anche da fornitori diversi. Quindi, potrebbe esserci una differenza nel set di funzionalità. Potrebbe esserci una differenza nel ciclo di rilascio. Quindi, per quanto riguarda i requisiti del cliente, devi affidarti a clienti di terze parti per quanto riguarda la tecnologia.
Quindi, voglio evidenziare alcuni aspetti in giro NCache essendo .NET nativo e .NET Core prodotto. NCache è completamente supportato su Windows, così come su Linux. Invece, Redis non è molto stabile su Windows. È la versione trasferita di terze parti ed è disponibile il supporto Linux e questo è il, quindi, devi fare affidamento sul supporto Linux per quanto Redis è preoccupato. Quindi, provenendo da un background tecnologico Microsoft, questo è qualcosa su cui devi fare affidamento.
Prestazioni e scalabilità della cache
Il secondo aspetto sono le prestazioni della nostra cache. Anche questo è un aspetto molto importante.
Entrambi i prodotti sono molto veloci e questa è l'idea del principale vantaggio NCache ed Redis, il motivo principale per cui sceglieresti un prodotto del genere è l'aspetto del miglioramento delle prestazioni. Abbiamo già stabilito che i database sono lenti e non sono molto scalabili. Questi prodotti sono veloci e molto scalabili in confronto. Quindi, non toglierei nulla da Redis. Solo la versione Windows non è stabile e ci sono problemi di prestazioni, ma se hai la versione Linux, è anche molto veloce e scalabile ed è estremamente veloce e NCache è anche molto veloce. È molto scalabile. Abbiamo il nostro protocollo di clustering basato su TCP/IP implementato, che è molto ottimizzato e molto robusto nelle prestazioni.
Tuttavia, ci sono anche alcune differenze qui. Entro NCache abbiamo molte funzioni di miglioramento delle prestazioni. Di recente abbiamo anche tenuto un webinar, in cui abbiamo affrontato sei diversi modi in cui puoi migliorare NCache prestazione. Se hai impostato NCache per impostazione predefinita, ti darà prestazioni molto buone ma per di più, in base ai tuoi casi d'uso, puoi abilitare diverse funzionalità e puoi migliorare ulteriormente le prestazioni e una di queste funzionalità è la nostra cache client.
NCache: cache client (vicino alla cache)
Client Cache è una caratteristica unica di NCache. Redis non ha questa caratteristica.
È una cache locale lato client, che di nuovo è possibile anche per applicazioni serverless, dove puoi avere una copia InProc all'interno del processo della tua applicazione e/o per, sai, applicazioni basate su server, puoi usare una cache client fuori processo . L'idea qui è che risparmierebbe viaggi costosi attraverso la rete al tuo cluster di cache. Questa cache stava già salvando i viaggi nelle origini dati di back-end. Ora puoi avere una cache in mezzo e presumere di avere 100 elementi nella cache, se hai alimentato alcuni elementi sul lato dell'applicazione, sai, diciamo 10 elementi, quei 10 elementi verrebbero riportati automaticamente nella cache del client e la prossima volta la tua applicazione troverebbe quei dati più vicini alla tua applicazione e di conseguenza risparmierebbe costosi viaggi di rete.
E questa è una cache client sincronizzata. La sincronizzazione è gestita da NCache. Qualsiasi cambiamento nel cache del cliente viene propagato nella cache del server come molto perché questa è la copia principale. Questo è un sottoinsieme dei dati e la modifica viene propagata anche ad altre cache client. Se si dispone di uno scenario di dati di riferimento. Se hai molte letture e poi molte scritture, ti consigliamo vivamente di attivare la cache del client e ti offriremo prestazioni molto buone rispetto a una cache in esecuzione sul nostro database.
Di recente abbiamo fatto un POC con uno dei nostri clienti, uno dei nostri clienti più grandi. Dove avevano un flusso di lavoro, che impiegava circa 46 secondi con le configurazioni predefinite. Ne stavano facendo un mucchio NCache chiamate e recupero dati. Quindi, è stato principalmente un caso d'uso intensivo di lettura. Abbiamo attivato la cache del client fuori processo, a proposito, ci sono due versioni, puoi tenerla fuori dal processo, il che significa che un processo di cache separato viene eseguito sulla casella dell'applicazione oppure puoi avere InProc in cui la cache del client viene eseguita all'interno del processo dell'applicazione. InProc non dispone di serializzazione o elaborazione per elaborare il sovraccarico di comunicazione. Quindi, è estremamente veloce. Anche rispetto a OutProc è più veloce. Quindi, con quel cliente, il flusso di lavoro impiegava circa 46 secondi per iniziare. Quindi abbiamo attivato la cache del client di processo, l'abbiamo ridotta a 3 o 4 secondi e quindi l'abbiamo ulteriormente attivata per attivare la cache del client InProc e siamo stati in grado di ottenere tutto ciò in 400-500 millisecondi. Da 46 secondi a 400 a 500 millisecondi, questo è il tipo di miglioramento di cui stiamo parlando e questa funzione non è completamente disponibile in nessun altro prodotto o anche in altre versioni di Redis, Compreso Redis Labs, inclusi il progetto open source e Azure Redis.
Quindi, puoi ottimizzare le prestazioni, utilizzando la nostra cache client ed è un lavoro senza modifiche al codice. È solo una configurazione che si attiva.
Le operazioni in blocco sono supportate su entrambi i lati ma con NCache è, le nostre operazioni in blocco funzionano sull'intero cluster di cache, il che significa che se hai dieci server e hai dati completamente distribuiti, una chiamata in blocco recupererebbe i dati da tutti quei server e il risultato consolidato verrà recuperato. Quindi, tutti questi lavorano in combinazione l'uno con l'altro per formulare il risultato e quindi si ottiene un risultato che è di natura completa. Invece Redis le operazioni in blocco sono a livello di shard. Quindi, devi gestire i dati su un determinato shard. Quindi, questo è il limite. Se lo hai, diciamo più nodi nel cluster di cache e hai frammenti master disponibili, quindi saresti in grado di eseguire operazioni di massa su un determinato shard.
Quindi, questo è il limite. Altrimenti, questa è una buona funzionalità di miglioramento delle prestazioni in cui invece di andare avanti e indietro per le singole richieste invii una grande richiesta e ottieni tutti i dati contemporaneamente e di conseguenza dimostri le tue prestazioni.
Serializzazione, questa è un'altra caratteristica e c'è un altro aspetto perché la maggior parte del tuo tempo verrebbe speso per serializzare e deserializzare i dati e questo è vero per NCache così come per Redis. Per impostazione predefinita, entrambi i prodotti verrebbero serializzati e deserializzati ma con NCache esiste un modo per migliorare il sovraccarico di serializzazione e deserializzazione. Abbiamo una serializzazione veloce e complessa, che ottimizzerebbe il tuo tempo di serializzazione, che normalmente richiederebbe la tua applicazione. I tuoi oggetti diventano complessi. Quindi, senza alcuna modifica al codice, puoi definirli come tipi compatti e NCache assicurerebbe che esegua la serializzazione compatta su di essi in fase di esecuzione e migliorerebbe il sovraccarico di serializzazione e deserializzazione.
Infine, abbiamo anche la funzione di compressione. La compressione viene eseguita sul lato client. In genere, se hai a che fare con oggetti più grandi, diciamo 2 MB, 3 MB o diciamo 500 kilobyte, è un oggetto più grande. Quindi, in genere ti consigliamo di gestire oggetti più piccoli, ma se hai oggetti più grandi, c'è molto utilizzo della rete e quindi anche le prestazioni vengono degradate. Insieme a NCache puoi attivare la compressione. Questa è un'opzione di modifica del codice, che non è disponibile su Redis lato e comprimerebbe automaticamente gli elementi durante l'aggiunta nella cache. Quindi, l'oggetto più piccolo viene aggiunto e trasferito tra, viaggia tra l'applicazione e la cache e allo stesso modo lo stesso oggetto più piccolo viene recuperato anche dall'estremità dell'applicazione. Gestire un carico utile più piccolo migliora le prestazioni delle tue applicazioni. Pertanto, le prestazioni complessive dell'applicazione aumenterebbero se la compressione fosse attivata.
Quindi, consigliamo qualsiasi oggetto maggiore di, diciamo, 100 kilobyte dovresti assolutamente attivare la compressione e c'è una soglia che puoi abilitare e solo gli oggetti più grandi vengono compressi, gli oggetti più piccoli vengono lasciati così come sono.
Pertanto, tutte queste funzionalità di miglioramento delle prestazioni, cache client, operazioni in blocco, serializzazione compatta, compressione non sono disponibili o Redis. Ad esempio, la cache del client non è disponibile. Le operazioni in blocco sono disponibili ma sono limitate. Non ci sono opzioni di ottimizzazione della serializzazione e la compressione è qualcosa che non è disponibile. Quindi, è qui che hai una chiara differenza tra NCache ed Redis, Dove NCache è un pacchetto completo in cui abbiamo integrato molte funzionalità incentrate sulle prestazioni.
Alta disponibilità
Il segmento successivo è l'alta disponibilità ed è qui che vedrai un'enorme differenza di set di funzionalità NCache ed Redis. L'elevata disponibilità è un altro aspetto in cui queste parti possono essere confrontate. Per le applicazioni mission-critical, questo è un aspetto molto importante per cui è necessaria una fonte. Ora stai portando i tuoi dati che normalmente si trovano nel database e all'interno del database avresti una sorta di mirroring, una sorta di backup, giusto?
Quindi, con i dati spostati in un prodotto che è cache distribuita, sebbene migliori le tue prestazioni, è molto scalabile ma l'elevata disponibilità è un aspetto molto importante. Per le applicazioni mission-critical i tempi di inattività non sono accettabili. Avrebbe un impatto sulla tua attività e l'esperienza dell'utente può essere influenzata. Quindi, non è conveniente. Quindi, è molto importante che la tua applicazione sia sempre in grado di ottenere una risposta dalla cache in cui sono presenti i dati. Quindi, qui abbiamo un'enorme serie di differenze di funzionalità.
Cluster di cache
NCache è un cluster di cache con architettura peer-to-peer al 100%.
È dinamico e autorigenerante e parlerò di come, sai, funziona, ma in confronto Redis utilizza master/slave. Quindi, essendo un'architettura peer-to-peer NCache ti consente di aggiungere e rimuovere automaticamente i server ed è perfetto per le tue applicazioni. Puoi andare avanti e aggiungere tutti i server di cui hai bisogno. Ad esempio, hai iniziato con 2 server. Ora vuoi aggiungere il 3° server, puoi farlo al volo. Non è necessario arrestare la cache o le applicazioni client che sono collegate a quella cache. Si osserva un'esperienza senza soluzione di continuità. In questo modo, le tue applicazioni possono continuare a funzionare senza tempi di inattività o perdita di dati grazie alle nostre funzionalità di alta disponibilità e affidabilità dei dati. Considerando che, nel Redis non è possibile aggiungere automaticamente nuovi shard. Perché non esiste un ribilanciamento automatico dei dati. Questo è il cuore della natura dinamica del nostro cluster di cache. Entro NCache, ribilancia automaticamente i dati se desideri aggiungere nuovi server.
Quindi, ci sono due scenari. Uno in cui si aggiunge un nuovo server per aumentare la capacità, per aumentare la scalabilità e l'altro scenario è che si interrompe un server.
Quindi, affrontiamo prima lo scenario del nodo aggiunto. Viene aggiunto un nuovo nodo. Insieme a NCache, i tuoi dati verrebbero distribuiti automaticamente.
Ad esempio, da 2 a 3 server, se ne aggiungi altri 2, hai 6 elementi qui e aggiungi un altro server a cui i dati esistenti verranno trasmessi, verranno bilanciati sul server appena aggiunto. Quindi, quel server prenderebbe parte dei dati dai server esistenti e ciò verrà eseguito automaticamente. È di natura dinamica. Quindi, c'è un ribilanciamento automatico dei dati che avviene. Insieme a Redis, è un ribilanciamento manuale dei dati e questo vale per Azure Redis perché in Azure sono disponibili diversi set di livelli. C'è un livello base, c'è un livello intermedio e c'è un avanzato. Il clustering entra in gioco solo con advanced qui, che è anche costoso e per di più hanno bisogno di almeno 3 server, il che è ancora una volta una limitazione.
Con NCache puoi anche avere il clustering completamente attivo e funzionante con solo 2 server e per di più, l'aggiunta di un nuovo server richiede un ribilanciamento manuale dei dati. Questo è un grosso problema. Quindi, avresti una sorta di limitazione sull'applicazione e quando prevedi di aggiungere capacità. Considerando che, con NCache puoi raggiungere questo obiettivo in fase di esecuzione. Puoi aggiungere più server al volo.
Il secondo aspetto è un server che non funziona. Quindi, abbiamo, dentro Redis abbiamo un concetto di padrone e schiavo. Un master replica i dati in slave. C'è un frammento di schiavo. Quindi, il master deve replicare i dati e può essere in modalità Sync o Async. In Redis, se uno shard slave si arresta, il master stesso si interrompe, il cluster diventa inutilizzabile. Quindi, questo è un grosso problema e può succedere tutto il tempo. Rigorosamente su distribuzioni on-premise in cui si dispone di un open source o Redis Distribuzione in laboratorio di Redis. In tal caso, se un server si interrompe e si tratta dello slave di uno shard master, il cluster stesso diventerebbe inutilizzabile. Quindi, devi essere coinvolto e fare un intervento manuale per riprenderti da quello scenario. Mentre all'interno NCache è automatico. Quindi, qualsiasi server può andare inattivo, il nodo sopravvissuto e potrebbe essere attivo o di backup.
Ad esempio, questo server non funziona, questa è una partizione attiva, ha anche una partizione di backup. Se l'intero server si interrompe, il backup promuove l'attivo. La partizione di backup viene promossa ad attiva e ottieni tutti i dati dal nodo sopravvissuto e c'è un failover di connessione che è integrato in essa. Qualsiasi server che interrompe i client lo rileverebbe in fase di esecuzione e deciderebbe e eseguirà il failover sui nodi sopravvissuti e qui vorrei rafforzare quel concetto che con il Redis hai bisogno di almeno 3 server. Questo è il concetto di regola maggioritaria. Il coordinatore del cluster deve vincere le elezioni. Non è il caso di NCache. Puoi iniziare a lavorare completamente al cluster di cache con solo 2 nodi e ti offrirà funzionalità complete di alta disponibilità. Qualsiasi server che non funziona, un nodo sopravvissuto è completamente in grado di funzionare senza problemi e questo non è il caso Redis.
Configurazioni dinamiche. È possibile modificare le configurazioni del cluster in fase di esecuzione e ciò comporta l'aggiunta di nuovi server, la rimozione di server o la modifica di alcune impostazioni nel cluster di cache. Questo è qualcosa che puoi applicare su un intero cluster di arresto anomalo in fase di esecuzione senza interromperlo. Mentre per Redis, è limitato. Ci sono molte configurazioni che devi applicare manualmente e poi ci sono molti eventi di integrità del cluster su cui sono disponibili NCache lato, a cui puoi iscriverti. È possibile utilizzare strumenti di monitoraggio e gestione su di esso. Invece, Redis non ha queste caratteristiche.
Quindi, questo è un concetto molto importante. Lascia che te lo riassuma. Aggiunta e rimozione di un server in Redis è qualcosa che ti darebbe molti problemi. Per l'aggiunta di dati non verrebbe ribilanciato automaticamente. Quindi, non è un'architettura peer-to-peer al cento per cento. Pertanto, il cluster di cache ha una capacità limitata. Allo stesso modo, se uno shard slave va giù, il cluster stesso diventa inutilizzabile. Perché c'è un problema di distribuzione che ora devi gestire manualmente. Anche il failover è manuale, giusto? Quindi, se un server non funziona, devi eseguire il failover manualmente e iniziare a utilizzare i nodi sopravvissuti. Se aggiungi nuovi server, dovrebbe passare manualmente ai server appena aggiunti.
Quindi, queste sono tutte le limitazioni che avresti e sai, sarei sorpreso di vedere l'utilizzo di un'implementazione di produzione di tale natura e ora devi portare capacità o devi disattivare i server per la manutenzione. Quindi, sarebbe molto difficile con un prodotto simile Redis. Mentre, NCache ti offre un'esperienza senza interruzioni. Dove puoi aggiungere o rimuovere server al volo senza alcun impatto.
Partizioni / frammenti dinamici
Ora un altro concetto all'interno, sai, il cluster è il meccanismo di autoguarigione.
NCache ha partizioni dinamiche. Aggiungi più server, i dati ottengono redisomaggio, nuove partizioni vengono formulate in fase di esecuzione. Allo stesso modo, se si interrompe un server, il cluster renderebbe disponibile il backup e si riparerebbe da solo e formulerebbe un cluster di cache a 2 nodi sano se lo si riducesse da 3 a 2 e quindi l'aspetto dell'affidabilità. Ha le partizioni di replica giuste, che è anche disponibile su Redis come forma di schiavi, ma la loro elevata disponibilità dipende dalla replica. Non hanno con Redis non avresti disponibilità elevata, se non hai shard slave configurati. Quindi, devi avere frammenti di slave disponibili. Considerando che, con il NCache, abbiamo topologie.
Ad esempio, Partitioned Cache, dove abbiamo frammenti master, partizioni master. Se questo server si interrompe, hai ancora un'elevata disponibilità perché i client lo rileverebbero, eseguirebbero il failover e inizierebbero a utilizzare il nodo di sopravvivenza. Avrebbero una perdita di dati e questo è vero Redis anche. Perdita di dati perché non c'è replica ma è ancora altamente disponibile e quindi abbiamo un miglioramento a questo, in cui abbiamo anche il supporto per la replica. Se questo server si interrompe, non solo il backup del server viene reso disponibile, i client eseguono automaticamente il failover. Così, Redis è limitato. L'elevata disponibilità dipende dalla replica. Non è altamente disponibile, se la replica non è attivata, il che è anche un fattore limitante.
E poi il meccanismo di autoguarigione, sebbene non sia necessario alcun intervento manuale.
Se inizi con 3 server, disattivi un server, useresti una partizione attiva, un master e quindi perdi anche uno slave di un altro server. Quindi, in tal caso, il backup del server 3 era sul server 1, quindi questo viene attivato. Si unisce alle partizioni attive in fase di esecuzione. Non è necessario alcun intervento. È necessario il lavoro manuale e quindi il server di partizione 2 formulerebbe una partizione sana sul server 1. Quindi, il cluster si riparerebbe automaticamente e questa è la natura dinamica di NCache in confronto a Redis. Dove per Redis, gli shard non possono essere riadattati in fase di esecuzione. Il cluster si interrompe se lo shard slave si interrompe. I dati redisla tribuzione non è dinamica. L'elevata disponibilità dipende dalla replica che non è il caso NCache. NCache fornisce alta disponibilità anche senza replica.
Quindi, tutti questi vantaggi da cui esci NCache, lo rende un prodotto molto più superiore perché queste caratteristiche sono completamente mancanti o limitate Redis e questo vale per Azure Redis. Questo vale anche per l'open source perché si tratta di prodotti molto comparabili e questo vale anche per Redis Labs Redis anche l'offerta.
NCache Dimo
Ora dedicherò un po' di tempo, sai, a mostrare il prodotto reale in azione in modo che tu abbia un'idea di come NCache viene configurato. Quindi, questo è il nostro ambiente demo. Ci ho lavorato. Quindi, creerò solo una nuova cache. Questo è il nostro strumento di gestione web che viene installato con NCache. La modalità di serializzazione può essere binaria o JSON. Dipende interamente da te. Assegnerò solo un nome alla cache e ti mostrerò come creare un cluster di cache, collegare un'applicazione client e monitorarla e gestirla.
Quindi, manterrò tutto semplice perché l'obiettivo principale di questo webinar è intorno NCache vs. Redis, quindi manterrò tutti i dettagli semplici. Replica partizionata, questa è la nostra topologia più consigliata. Replica asincrona tra attivo e backup. Quindi, puoi scegliere Sincronizza. Async è più veloce, quindi andrò con quello. Dimensioni del cluster di cache. Quindi specificherò questi nodi del server dove NCache è già installato. Porta TCP. NCache è un protocollo di comunicazione di base TCP/IP. Quindi, manterrò tutto semplice e su questo abiliterò solo lo sfratto in modo che la cache si riempia. Quindi, rimuove automaticamente alcuni elementi dalla cache e di conseguenza fa spazio agli elementi più recenti. Avvia questa cache e finisci. Avvialo automaticamente all'avvio del servizio, quindi, ogni volta che il mio server viene riavviato, si unisce automaticamente al cluster di cache e il gioco è fatto. È così semplice configurare un cluster di cache e quindi utilizzarlo, che ti mostrerò di seguito.
Supporto cloud (Azure e AWS)
Quindi, il nostro modello di servizio gestito sta arrivando. Il nostro prossimo rilascio è incentrato su ciò che penso sia da due a tre settimane lungo la strada. Quindi, avremo una gestione completa NCache software come modello di servizio in Azure e in AWS.
Al momento, sarà il modello VM. Se si dispone in locale, è possibile utilizzare box fisici o VM. Se scegli Azure, devi configurare la tua VM tramite Marketplace oppure puoi semplicemente configurare una VM e quindi installarla NCache software scaricando dal nostro sito web. E poi abbiamo anche l'ambiente containerizzato. Abbiamo immagini Docker e siamo completamente supportati su Azure Kubernetes Service, EKS - Elastic Kubernetes Service e qualsiasi altro, ad esempio, piattaforma OpenShift Kubernetes, NCache è già completamente integrato e completamente supportato su quelle piattaforme. Per quanto riguarda l'aspetto gestito, questo è qualcosa che sta venendo fuori. Quindi, tra due o tre settimane da adesso sarebbe completamente disponibile.
Quindi, ti mostrerò la finestra delle statistiche, che è un contatore perfmon e comunque queste opzioni di monitoraggio sono disponibili per NCache, in termini di NCache su Windows così come su ambiente Linux, giusto?
Quindi, eseguirò uno strumento di stress test. Penso che ce ne sia già uno in esecuzione per un'altra cache. Quindi, andrò avanti e ne eseguirò un altro e questo simulerebbe il nostro carico fittizio sul nostro cluster di cache. Devi solo specificare il nome e rileva automaticamente i server utilizzando i file di configurazione e si connette semplicemente ad esso.
Quindi, abbiamo lo stato del cluster completamente connesso, le richieste al secondo che mostrano il throughput, la latenza per microsecondo medio per operazione di cache, aggiunte, recuperi, aggiornamenti, eliminazioni, dimensione della cache, CPU, memoria. Quindi, ottieni una vista di monitoraggio centralizzata. Puoi usare questo strumento. Puoi anche usare Windows perfmon.
Per Linux abbiamo il nostro monitoraggio personalizzato. Quindi, puoi utilizzare il nostro strumento di monitoraggio direttamente anche per i server Linux e puoi anche utilizzare qualsiasi strumento di terze parti per il monitoraggio NCache anche. Quindi, questa è stata una rapida occhiata al nostro processo di creazione della cache. Alcuni aspetti di monitoraggio e gestione.
Quindi, tornando. Dal momento che discutiamo alcuni dettagli. La prossima cosa di cui vorrei discutere è l'offerta cloud / supporto cloud. Adesso Redis stesso, puoi scegliere una cache non gestita, puoi anche scegliere la cache gestita e quindi c'è un servizio ospitato che è disponibile e l'opzione di gestione è di fornitori di terze parti. L'opzione ospitata proviene da Azure Redis, dove puoi avere una variante open source di Redis personalizzato da Microsoft e disponibile come modello ospitato. Considerando che, il NCache lato, abbiamo il modello del server cache, il modello VM. Ho già discusso dell'approccio del contenitore. È completamente compatibile con Windows e con i container Linux. Sono disponibili dimostrazioni video per Azure Service Fabric per contenitori Windows, dettagli sull'architettura dei microservizi. Abbiamo il servizio Azure Kubernetes che usa i contenitori Linux. EKS – Elastic Kubernetes Service e poi penso che abbiamo anche realizzato Red Hat OpenShift Containers tramite Kubernetes.
Quindi, queste sono tutte opzioni di distribuzione del contenitore disponibili ed è flessibile, la sua piattaforma, sai, non è specifica della piattaforma. Quindi, puoi distribuirlo in qualsiasi tipo di piattaforma containerizzata senza problemi. Il servizio gestito è in arrivo, quindi ne abbiamo già discusso. Quindi, questo è qualcosa in cui NCache avrebbe gestito il servizio, ma è nella nostra prossima versione.
Un aspetto importante è che il vantaggio dell'utilizzo di un modello di VM, anche se devi connetterti a una VM anziché a un servizio ma controlli tutto. È possibile eseguire codice lato server che tratterò in seguito, ma l'aspetto più importante è l'aspetto delle prestazioni. Abbiamo già discusso del fatto che ci sono molte funzionalità di prestazioni all'interno NCache, che mancano in Redis. Se scegli di avere Azure Redis, dovresti connetterti all'infrastruttura di Azure. Quindi, quelle sono VM, quelle sono in esecuzione in una rete virtuale separata. Questi si trovano nelle vicinanze ma ancora una volta sono lontani. È diverso dalla tua rete virtuale che hai in Microsoft Azure e dove hai tutte le distribuzioni delle tue applicazioni.
Con NCache puoi scegliere il nostro NCache distribuzione sulla stessa rete virtuale, come le reti virtuali dell'applicazione. Ad esempio, il servizio app, il sito Web di Azure, i microservizi di Azure sono in esecuzione su una rete virtuale di Azure. Puoi scegliere di distribuire le macchine virtuali di Azure sulla stessa rete virtuale e migliorare le prestazioni delle tue applicazioni. Sulla base dei nostri test all'interno del nostro laboratorio, NCache era da quattro a cinque volte più veloce del modello SaaS di Redis che normalmente ottieni in Microsoft Azure. Quindi, questo è un aspetto molto importante che vorrei sottolineare.
Inoltre, ottieni molto controllo sulla tua VM. Hai il pieno controllo sull'avvio di una cache, aumentando le dimensioni, ottieni la piena capacità. Non c'è limite alle unità di richiesta, non c'è limite alle dimensioni, non c'è ingombro di utilizzo e non ti viene addebitato alcun costo come parte di ciò. Porti la tua licenza e potrebbe anche essere perpetuo, potrebbe anche essere una licenza in abbonamento, che potrebbe essere molto flessibile in termini di licenza. Inoltre, puoi eseguire il codice lato server sopra il tuo NCache server. Puoi gestirlo completamente. Puoi ottimizzarlo completamente. Puoi scrivere molte interfacce. Come read-through, write-through, write-behind, caricatore di cache e alcune funzionalità di griglia di calcolo come MapReduce, Aggregator, processori Entry e questo è possibile solo con NCache. Anche il nostro modello SaaS che sarebbe un modello ospitato che avrebbe tutte queste offerte disponibili, il che non sarà il caso di Redis. Quindi, questa è la nostra piattaforma.
Mantenere la cache fresca
Il prossimo segmento, i prossimi 15 minuti che vorrei dedicare, sai, al confronto del livello di funzionalità e per questo ho definito alcuni segmenti. Quindi, inizierò se hai bisogno di mantenere la cache fresca e questo è molto importante, dovrebbe esserci un webinar separato proprio su questo, come mantenere la cache fresca in particolare per quanto riguarda le origini dati di back-end, per quanto riguarda l'uso dell'applicazione casi.
Quindi, rispetto a Redis, sai, NCache ha molte caratteristiche anche su questo lato.
Abbiamo la scadenza della base dei tempi, che è assoluta e scorrevole, ma abbiamo anche un meccanismo di ricarica automatica disponibile per questo. Redis ha solo una scadenza assoluta e scorrevole senza alcun meccanismo di ricarica. Per il ricaricamento, ti permettiamo di implementare un'interfaccia, chiamata read-through handler, che è un codice lato server. Ancora una volta, è possibile perché NCache ti consente di dare, avere pieno accesso alle tue VM dove NCache è ospitato. Quindi, puoi distribuire il codice lato server in aggiunta NCache E l'uso NCache potenza di calcolo per eseguirne il backup.
Puoi sincronizzare la tua cache con il database. NCache è molto forte sulla sincronizzazione del database. Abbiamo una dipendenza SQL. Abbiamo una dipendenza da DB che è compatibile solo con DB. Abbiamo stored procedure .NET CLR. Quindi, tutte queste funzionalità ti consentono di sincronizzare la cache con il database. E l'idea qui è se c'è una modifica nel database, un record nel database cambia e il record è stato memorizzato nella cache, queste due origini potrebbero non essere sincronizzate. Quindi, con NCache, se c'è una modifica nel database puoi invalidare o ricaricare automaticamente quei dati NCache in fase di esecuzione. Questa è una caratteristica unica di NCache. Nessun altro prodotto ha questa caratteristica. Quindi, puoi avere una cache completamente sincronizzata con il tuo database back-end e questo non è vero solo per i database relazionali, abbiamo anche funzionalità sul lato delle origini dati non relazionali.
La dipendenza da file è un'altra caratteristica in cui puoi rendere gli elementi dipendenti dal file. Contenuto del file, se il contenuto cambia, gli elementi vengono rimossi o ricaricati automaticamente. E la dipendenza personalizzata, puoi usarla con qualsiasi fonte. Potrebbe essere un NoSQL database, potrebbe essere un file system o relazionale, qualsiasi connettore, qualsiasi servizio web. Quindi, puoi rendere gli articoli convalidati in base ai tuoi requisiti flessibili. Abbiamo fornito un'implementazione di questa dipendenza con Cosmos DB. Quindi, abbiamo implementato la sincronizzazione di NCache con Cosmos DB. Se stai usando NCache insieme a cosmos DB, puoi usare la dipendenza personalizzata e penso di aver fatto anche un webinar su questo.
Gestione dei dati relazionali. Quindi, i dati relazionali hanno relazioni. Gli elementi nella cache sono coppie di valori chiave in modo da poter creare relazioni tra elementi diversi e questo è qualcosa su cui non è disponibile Redis lato. Quindi, dovresti occuparti degli articoli in base al loro merito separato. Considerando che, con NCache puoi combinare gli elementi in gruppi uno a uno, uno a molti o molti a molti. L'elemento padre subisce una modifica, l'elemento figlio può essere automaticamente invalidato o ricaricato, se necessario.
Raggruppamento dati, ricerca SQL e LINQ
Un altro aspetto è il raggruppamento e la ricerca dei dati, dove NCache è molto forte e Redis non ha alcuna caratteristica. E ancora, questo è vero per Azure Redis che è comunque molto limitato. L'open source Redis è leggermente avanti ma è ancora limitato in termini di funzionalità. Persino il Redis Lab, la versione commerciale di Redis, che non è dotato di queste caratteristiche.
È disponibile la ricerca SQL. Puoi cercare elementi all'interno NCache in base agli attributi dell'oggetto. Gli oggetti vengono aggiunti nella cache. È possibile definire indici per i loro attributi. Ad esempio, i prodotti possono essere all'indice per il loro ID, il loro prezzo, le loro categorie e ora puoi eseguire la ricerca su quei prodotti utilizzando questi attributi. Un tipico esempio potrebbe essere selezionare un prodotto in cui la categoria del punto del prodotto è qualcosa o il prezzo del punto del prodotto è maggiore di 10 e il prezzo del punto del prodotto è inferiore a 100 e NCache eseguirebbe la ricerca in memoria su tutti gli elementi, su tutti i server, consoliderebbe i risultati e ti riporterebbe il set di risultati. Quindi, non devi più occuparti delle chiavi. Recupera i dati in base a un criterio.
Sono disponibili anche ricerche LINQ. Abbiamo .NET e .NET Core app. Se stai utilizzando, sai, la ricerca LINQ puoi eseguire la ricerca LINQ NCache anche. Quindi, questa è una caratteristica unica NCache where Redis non ha alcun supporto. Redis qualsiasi, tutti i sapori di Redis, non hanno questo supporto.
Puoi avere gruppi, sottogruppi. Puoi logicamente creare raccolte all'interno NCache. Non è disponibile in Redis e puoi recuperare, aggiornare e rimuovere i dati in base a quei gruppi.
È possibile attribuire tag e tag con nome. Ad esempio, puoi utilizzare parole chiave che possono essere allegate ai tuoi articoli. Un tipico esempio potrebbe essere che puoi taggare tutti i clienti con il tag cliente. Tutti gli ordini con un tag ordine e gli ordini di un determinato cliente possono anche avere un ID cliente allegato come tag. Quando hai bisogno di ordini, dici semplicemente prendi per tag e fornisci gli ordini come tag, in modo da ottenere tutti gli ordini. Quando hai bisogno di ordini di un determinato cliente, dici di ottenere per qualsiasi tag o ottenere per tag e fornire l'ID cliente ti otterrebbero tutti gli ordini ma solo per quell'ID cliente. Quindi, questa è la flessibilità di utilizzare tag e tag con nome che hai con NCache. Redis non li supporta.
Codice .NET lato server
Abbiamo già discusso del fatto che in genere utilizziamo il pattern cache-aside, in cui controlli prima i dati nella cache, se viene trovato lì restituisci, se non trovi dati nella cache andresti al database di back-end nella tua applicazione e quindi recuperare quei dati e portarli nella cache. Quindi, c'è un null, recuperi null e poi vai al database. Puoi automatizzarlo con l'aiuto del gestore Read-Thru. È un codice lato server che viene eseguito sul tuo NCache server. Anche il nostro servizio gestito avrebbe questa funzione. Quindi, implementi questa interfaccia che ti consente di connetterti a qualsiasi origine dati. Potrebbe essere un servizio Web, potrebbe essere un'origine dati relazionale o un'origine dati non relazionale e ci sono un sacco di metodi che verrebbero chiamati non appena viene trovato un null nella cache.
Quindi, chiami il metodo Cache.Get, abilita il flag Read-Thru. Se l'elemento non è nella cache, la chiamata viene passata al tuo gestore Read-Thru e di conseguenza dovresti recuperare i dati dal database back-end passando attraverso quel codice del gestore. Qual è il tuo codice utente in esecuzione NCache lato server. Quindi, puoi passare senza problemi NCache e ottieni i dati di cui hai bisogno.
Il write-through è opposto, che è anche supportato e Redis non ha queste funzionalità in cui è possibile aggiornare qualcosa nella cache e ora si desidera aggiornare il database, è possibile aggiornare il database chiamando il proprio gestore di write-through. Implementare e registrare questo gestore write-through e NCache lo chiamerebbe per aggiornare il database di back-end e il write-behind è opposto. Qualsiasi aggiornamento sulla cache, l'applicazione client restituisce e NCache aggiornerebbe il database back-end in modo asincrono dietro le quinte. Così, NCache può persino migliorare le tue prestazioni per le operazioni di scrittura sul database, cosa che non è possibile con Redis o qualsiasi altro prodotto, se non hai la possibilità di eseguire codice lato server. E questo è un .NET puramente nativo e .NET Core librerie di classi che puoi implementare e registrare come read-through e write tramite interfacce, cosa possibile con NCache.
Il caricatore di cache è un'altra caratteristica. Dove puoi precompilare la cache implementando un'interfaccia e registrandoti con NCache. Quindi, ogni volta che riavvii la cache, carichi automaticamente alcuni dei tuoi dati importanti all'interno NCache e questo funziona su tutti i server contemporaneamente. Quindi, è super veloce. Quindi, puoi precompilare tutti i tuoi dati e non devi mai più andare al database. Troverai sempre quei dati perché li hai precaricati.
Dipendenza personalizzata, Processore di ingresso, queste sono ancora una volta caratteristiche che sono uniche solo per NCache e il motivo il motivo principale per non essere in grado di utilizzare queste funzionalità. Prima di tutto, Redis non dispone di queste funzionalità, i moduli non sono supportati in Azure Redis o anche in open source Redis. Lato server, il codice non è possibile con Azure Redis. Principalmente, perché non hai alcun accesso alle VM sottostanti e questo era il motivo principale per cui mi riferivo in precedenza a quello con NCache su un modello di VM al momento, hai pieno accesso a dove lo distribuisci, come lo controlli, come lo gestisci. Quindi, hai il pieno controllo. Non è una scatola nera come Redis è.
Replica WAN per multi-datacenter
Qualche dettaglio in più e poi concluderò questo. La replica WAN è un altro aspetto.
Attivo-passivo è supportato Redis, dove puoi trasferire l'intero datacenter, la cache da un datacenter all'altro. In NCache, abbiamo attivo-passivo. Quindi, transizione unidirezionale dei dati da un datacenter all'altro. Abbiamo anche active-active, che è molto urgente, caso d'uso molto importante in cui potresti avere entrambi i siti attivi. Hai bisogno degli aggiornamenti del sito uno sul sito due e viceversa. Quindi, non è un'abilità attiva Redis lato. Non hai questa capacità, quindi non puoi eseguire siti attivi-attivi con Redis. Con NCache questo è vero per il caso d'uso della memorizzazione nella cache dei dati della tua app in cui hai dati su entrambi i siti in fase di aggiornamento e ciò è possibile anche attraverso le nostre sessioni multisito. Quindi, questo è un altro spazio in cui NCache è un chiaro vincitore.
Topologie della cache
Poi qualche altro dettaglio. Topologie di memorizzazione nella cache. Abbiamo un elenco enorme di topologie di memorizzazione nella cache rispetto a Redis.
Quindi, sulla base di diversi casi d'uso abbiamo Mirrored, Replicated, Partitioned e poi Partition Replica e poi abbiamo già discusso, abbiamo discusso di come NCache il clustering è migliore in generale e abbiamo molte più opzioni rispetto a Redis offerte.
Strumenti della GUI - Amministrazione e monitoraggio della cache
Quindi abbiamo gli strumenti della GUI. Ecco un confronto. Gestore, sorvegliante.
Mentre disponiamo di strumenti PowerShell, disponiamo di strumenti di dump e ricarica, amministrazione completa, gli aspetti di monitoraggio sono integrati in esso. Invece, Redis è limitato anche su questo fronte e come parte di ciò ti ho mostrato alcuni dettagli e questo è vero per Windows così come per le distribuzioni Linux di NCache.
Funzionalità specifiche di ASP.NET
Alcune funzionalità di memorizzazione nella cache specifiche di ASP.NET.
Sessioni, abbiamo sessioni multisito, da ASP.NET ad ASP.NET Core la condivisione della sessione è in arrivo. Multisito ASP.NET e ASP.NET Core le sessioni sono disponibili. Visualizza stato, cache di output. Redis ha solo sessioni, che è molto semplice rispetto a NCache. Blocco della sessione, di cui fa parte la condivisione della sessione NCache. La memorizzazione nella cache di output è supportata su entrambe le estremità e in aggiunta abbiamo SignalR Backplane, Asp.NET Core memorizzazione nella cache delle risposte. Quindi, tutto ciò rende un set completo di funzionalità per i requisiti di memorizzazione nella cache specifici del Web. Quindi, puoi rivedere il set di funzionalità in dettaglio.
Condivisione dei dati di runtime con eventi
E poi abbiamo la messaggistica Pub/Sub.
Abbiamo eventi a livello di articolo e abbiamo anche un sistema di notifica degli eventi basato su criteri, che è di gran lunga superiore rispetto a Redis. Ho un webinar separato sulla nostra messaggistica Pub/Sub. Quindi, ti consiglio vivamente di esaminarlo se ci sono domande. Quindi, penso che concluderò a questo punto.
Integrazioni di terze parti
Infine, integrazioni di terze parti.
Abbiamo anche NHibernate ed Entity Framework. AppFabric l'involucro è disponibile. Memcached l'involucro è disponibile. Quindi, se stai passando da questi prodotti, puoi passare senza problemi a NCache in confronto a Redis.
Sicurezza e crittografia
Alcuni dettagli su crittografia di sicurezza e penso che siamo già in tempo.
Conclusione
Quindi, è un buon momento per concluderlo. Quindi, la prima cosa è che ogni volta che voi ragazzi, ogni volta che volete, potete andare su www.alachisoft.com e puoi scaricare una versione aziendale di NCache e ti mostreremo personalmente come funziona nel tuo ambiente. Quindi, ti invitiamo ad andare direttamente al sito Web, ottenere quella prova gratuita di 30 giorni di Enterprise. Pianificare una demo sarà un nostro piacere. Inoltre, avremo a disposizione una registrazione di questo webinar. Quindi, tieni d'occhio le tue e-mail e i social media quando te lo comunichiamo. Se oggi non siamo arrivati alle tue domande e so che ne abbiamo molte altre in arrivo e siamo proprio al limite, per favore, inviaci un'e-mail support@alachisoft.com.
Se hai domande tecniche, avremo una risposta per te e se sei interessato a procedere e candidarti NCache nel tuo ambiente solo tu puoi contattare sales@alachisoft.com come pure.