Redis vs NCache
Webinar registrato
Di Ron Hussain e Zack Khan
NCache è una cache distribuita nativa .NET Open Source molto diffusa tra le applicazioni .NET, .NET Core e Java ad alto numero di transazioni. Redis è sviluppato da Redis Labs ed è attualmente utilizzato da Microsoft in Azure. In questo webinar, scopri come NCache and 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 come argomento il confronto di due prodotti molto simili ma anche diversi sotto molti aspetti. Quindi, abbiamo NCache che è il nostro principale prodotto di caching distribuito per applicazioni .NET e .NET Core e poi lo confronteremo dal punto di vista delle funzionalità con RedisQuindi, abbiamo molto da trattare in questo articolo. Esaminerò molti dettagli tecnici a partire dalla piattaforma e dallo stack tecnologico. Poi parleremo del clustering. Come questi due prodotti si confrontano per quanto riguarda il clustering della cache e quali sono i diversi vantaggi che si ottengono dall'utilizzo di questi prodotti e, a confronto, come... NCache è meglio e poi parlerò delle diverse caratteristiche. Andremo confronto funzionalità per funzionalità per quanto riguarda i diversi casi d'uso in cui è possibile utilizzare questi prodotti e poi come questi due prodotti si confrontano dal punto di vista del confronto delle funzionalità.
Per questo webinar ho scelto NCache Enterprise 5.0.2, per quanto riguarda Redis per quanto riguarda, ci concentreremo principalmente su Azure RedisQuesto è open source Redis 4.0.1.4. Ma vorrei anche darti dettagli sul Redis progetto open source, così come, Redis laboratorio che è la variante commerciale di RedisQuindi, confronteremo NCache con tutti questi gusti ma il nostro focus principale sarebbe Microsoft Azure Redis, il modello ospitato di Redis che puoi ottenere in Microsoft Azure.
Il problema della scalabilità
Quindi, prima di iniziare, vorrei innanzitutto illustrare i dettagli introduttivi di questi due prodotti. Perché esattamente hai bisogno di una soluzione di caching distribuito?
Quindi, e dopo, si procederebbe a confrontare diversi prodotti. Quindi, in genere, si tratta della sfida di scalabilità e prestazioni che potresti riscontrare all'interno della tua applicazione. Potrebbe essere che la tua applicazione riceva un carico di dati elevato e, sebbene il tuo livello applicativo sia molto scalabile, puoi sempre creare una web farm, puoi aggiungere più risorse al livello applicativo, ma tutte queste istanze dell'applicazione devono tornare indietro e comunicare con le fonti dati back-end. E, quando devi tornare indietro e comunicare con queste fonti dati, è lì che si verificano problemi di prestazioni perché i database, in genere i database relazionali, sono lenti in termini di gestione del carico transazionale.
Esiste un problema di prestazioni associato a questi sistemi e, in termini di scalabilità orizzontale, ad esempio, se è necessaria una notevole capacità di gestione delle richieste o se ci sono requisiti che richiedono di gestire molte richieste e le applicazioni generano un carico utente elevato, il database non è progettato per gestire un carico transazionale così elevato. È ottimo per l'archiviazione, dove è possibile archiviare molti dati, ma avere un carico transazionale su tali dati non è un buon candidato per questo scopo. Potrebbe bloccarsi. Ciò comporterebbe lentezza e l'esperienza dell'utente finale potrebbe risultare compromessa.
Quindi, è possibile avere un impatto sulle prestazioni e non è possibile aumentare la capacità all'interno dell'architettura dell'applicazione.
La soluzione: cache distribuita in memoria (NCache)
La soluzione è molto semplice: utilizzare un sistema di caching distribuito in memoria come NCache che è superveloce perché è in memoria. Quindi, rispetto a un database relazionale, un file system o qualsiasi altra fonte dati che non sia basata sulla memoria, se i dati provengono da un disco, rispetto all'archiviazione in memoria, saranno superveloci. Quindi, il primo vantaggio che si ottiene è che si ottengono prestazioni superveloci. NCache.
Il secondo vantaggio è che si tratta di un cluster di cache. Non si tratta di una singola sorgente. Si può iniziare con un server, ma in genere consigliamo di averne almeno due e di creare un cluster di cache. Non appena creato, la situazione migliorerebbe se distribuissimo il carico su tutti i server e continuassimo ad aggiungere altri server in fase di esecuzione.
Quindi, puoi scalare la tua capacità, puoi, sai, aumentare la capacità in fase di esecuzione aggiungendo più server e puoi anche utilizzarlo in combinazione con i tuoi database relazionali back-end. Non si tratta di una sostituzione dei tuoi database relazionali convenzionali e parleremo di alcuni casi d'uso più avanti.
Distribuzione cache distribuita (NCache)
Ecco una tipica distribuzione.
sto usando NCache come esempio per ora, ma più avanti in questa presentazione confronteremo come Redis viene distribuito e come NCache viene implementato e quali sono le flessibilità disponibili all'interno di questi prodotti.
Così per NCacheÈ molto flessibile. Puoi scegliere di distribuirlo sia in ambiente Windows che Linux. È disponibile on-premise e supportato in ambienti cloud. È disponibile sia su Azure che sui marketplace AWS. Quindi, puoi semplicemente ottenere un'immagine preconfigurata di NCache e inizia a usarlo. Sono disponibili contenitori Docker sia per Windows che per Linux, utilizzabili su qualsiasi piattaforma su cui sia necessario.
In genere, le applicazioni, che siano ospitate on-premise o nel cloud, potrebbero essere un servizio app, un servizio cloud, un microservizio, un sito web Azure, qualsiasi tipo di applicazione può connettersi ad esso nel modello client-server e si trova tra l'applicazione e il database back-end. Questo è il modello di utilizzo tipico. L'idea è che i dati vengano archiviati all'interno. NCache e di conseguenza si risparmierebbero costosi accessi al database back-end. Si risparmierebbero il più possibile gli accessi al database e ogni volta che si ha bisogno di accedervi, si andrebbe sempre al database, si recupereranno i dati e li si inserirà nella cache, in modo che la volta successiva che i dati saranno disponibili non sia necessario accedervi. Di conseguenza, le prestazioni delle applicazioni e la scalabilità complessiva migliorano perché ora si ha accesso in memoria, il che migliora le prestazioni. Si hanno più server che ospitano e gestiscono le richieste, le richieste di dati. Quindi, è più scalabile in confronto. E poi, ci sono funzionalità di alta disponibilità e affidabilità dei dati integrate. NCache protocollo.
NCache Possono essere ospitati sugli stessi server in cui sono in esecuzione le applicazioni. Oppure potrebbero essere semplicemente su un livello separato. Nel cloud, l'approccio preferito sarebbe quello di utilizzare un livello di cache dedicato separato, e quindi le applicazioni e le istanze delle applicazioni vengono eseguite sul rispettivo livello. Tuttavia, entrambi i modelli sono supportati per quanto riguarda NCache è preoccupato.
Alcuni numeri sulla scalabilità. Abbiamo recentemente condotto questi test nel nostro laboratorio AWS, dove abbiamo simulato il carico di richieste di lettura e scrittura e abbiamo continuato ad aumentare il carico. Dopo un certo punto, quando abbiamo visto che i server stavano raggiungendo il limite massimo, abbiamo aumentato il numero di server nel cluster di cache. Quindi, da 2 a 3 server e poi da 3 a 4, siamo riusciti a raggiungere un throughput di 2 milioni di richieste al secondo con solo 5. NCache server e questo non è, non si trattava di dati improvvisati. Si trattava di dati applicativi reali, ma simulati nel nostro laboratorio AWS all'interno delle nostre applicazioni. E anche il fattore di latenza era molto ottimizzato. Siamo riusciti a ottenere tutto questo con una latenza di microsecondi. Quindi, le prestazioni delle singole richieste non hanno subito alcun degrado quando siamo riusciti a gestire tutto questo carico.
Casi d'uso comuni: cache distribuita
Alcuni casi d'uso e questo è qualcosa che è comune per Redis anche ma parlerò di come NCache si confronterebbe.
Memorizzazione nella cache dei dati dell'app
Dove memorizzi nella cache quasi tutto ciò che normalmente recuperi dal database back-end e i dati esistono nel tuo database e ora vuoi memorizzarli nella cache. In questo modo risparmi costosi viaggi al 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 questo caso ti connetti semplicemente a NCache e utilizzare fondamentalmente le nostre API per effettuare connessioni, sai, effettuare chiamate dati a NCacheQuindi, puoi memorizzare nella cache quasi tutto. Che si tratti di 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 caching dei dati.
Caching in ASP.NET / ASP.NET Core
Poi abbiamo la nostra cache specifica per ASP.NET e ASP.NET Core. Anche questo è un caso d'uso tecnico, in cui è possibile utilizzarla per la cache dello stato della sessione ASP.NET o ASP.NET Core. Backplane SignalR per ASP.NET o ASP.NET Core. NCache può essere collegato come Backplane. Per ASP.NET Core è possibile utilizzarlo anche per la memorizzazione nella cache delle risposte. Interfaccia IDistributedCache e sessioni tramite 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 farti una domanda veloce, Ron.
Siamo entrati, la domanda è: NCache e Azure supporta un modello di programmazione senza server?
Assolutamente. Questo è un aspetto che, in termini di distribuzione di Azure, consente di distribuire le applicazioni su server oppure, per quanto riguarda la parte applicativa, anche su applicazioni serverless. È sufficiente includere i nostri pacchetti NuGet all'interno dell'applicazione e queste applicazioni possono semplicemente... NCache chiamate ogni volta che ne hanno bisogno. Non devono nemmeno avere alcuna installazione di NCache o avere un server configurato per quanto riguarda le risorse dell'applicazione. Ma, per quanto riguarda, NCache la distribuzione lato server stessa è interessata perché NCache è la fonte dei dati, quindi deve avere una VM o un set di VM, in cui le applicazioni si connettono, recuperano e aggiungono dati.
Quindi, dai server, NCache dal punto di vista del server cache, come fonte di cui hai bisogno NCache server, ma per quanto riguarda le applicazioni, questi potrebbero essere rigorosamente serverless e non ci sarebbero problemi. Anche l'architettura dei microservizi. Questo è un esempio molto comune, dove i microservizi... ce ne sono molti. Potrebbe esserci una funzione di Azure, che è semplicemente in esecuzione e gestisce molti dati, e quei dati possono provenire da NCacheQuindi, tratti NCache come fonte di dati. Considerando che le tue applicazioni possono essere serverless e NCache è pienamente compatibile con quel modello.
Messaggistica e eventi Pub/Sub
Poi c'è un altro caso d'uso Messaggistica Pub/Sub e che ruota attorno ai microservizi, perché questo è uno dei casi d'uso più interessanti in cui è possibile utilizzare la messaggistica per applicazioni serverless. I microservizi sono applicazioni serverless debolmente accoppiate e stabilire una comunicazione tra loro è una grande sfida. Pertanto, è possibile utilizzare la nostra piattaforma di messaggistica Pub/Sub, dove è possibile sfruttare il nostro meccanismo di propagazione asincrona degli eventi basato sugli eventi. In questo modo, più applicazioni possono pubblicare messaggi su NCache e gli abbonati possono ricevere tali messaggi.
Poiché si basa su un meccanismo basato su eventi asincroni, le applicazioni publisher non devono attendere la conferma di ricezione o la consegna dei messaggi, e allo stesso modo i subscriber non devono attendere o attendere i messaggi. Vengono avvisati tramite callback quando ricevono notifiche. Quindi, è molto flessibile e questo è un altro caso d'uso in cui è possibile utilizzarlo. NCache come piattaforma di messaggistica Pub/Sub per le tue applicazioni.
NCache Storia
Qualche dettaglio in più e poi parleremo delle differenze tra NCache and Redis. NCache è stato lanciato nel 2005. È sul mercato da oltre 15 anni. La versione attuale di NCache è la 5.0, la 15a versione. Abbiamo moltissimi clienti. NCache è disponibile anche in edizione Open Source, scaricabile dal nostro sito web e dal repository GitHub.
Alcuni NCache Clienti
Ecco alcuni dei nostri clienti. Puoi anche ottenere un elenco dettagliato.
Piattaforma e tecnologia
Ora parleremo di come NCache confronta con Redis Il primo segmento si basa su alcuni dettagli introduttivi sulla tecnologia in generale. Si tratterà di informazioni sulla tecnologia di caching distribuito. Ora ci concentreremo direttamente su come NCache confronta con Redis e ho alcuni segmenti che ho formulato.
Quindi, la prima sezione che abbiamo definito è quella della piattaforma e della tecnologia e inizialmente ho detto che ci stiamo concentrando NCache 5.0.2. Quindi, NCache 5.0 SP2 è la versione principale su NCache sito e da Redis dal punto di vista useremo Azure Redis come confronto e parleremo anche di Open Source e Redis Lab come parte di ciò. La maggior parte di questi dettagli sono comuni per diversi tipi di Redis.
Cache .NET nativa
Quindi, se si ha esperienza con Azure, se si ha intenzione di scegliere un prodotto, la cosa più importante è la compatibilità con la piattaforma.
Così, NCache è scritto al 100% in .NET. È un prodotto nativo .NET o .NET Core, per quanto riguarda le tue applicazioni, giusto? Quindi, in pratica, è scritto in .NET e principalmente per applicazioni .NET e viene distribuito su Windows Server 2016, 2019, persino 2012. L'unico prerequisito per NCache è .NET framework o .NET Core, per esempio. Mentre, per Redis, è scritto in C++. NCache è scritto in .NET. È sviluppato al 100%, in realtà C# è il linguaggio tecnologico principale che stiamo usando ed è nativo al 100% .NET e .NET Core. Mentre Redis è una soluzione basata su C++ Linux.
Quindi, da una prospettiva Windows, con un background Windows e se le vostre applicazioni sono scritte in .NET, la scelta naturale sarebbe quella di utilizzare un prodotto anch'esso scritto in .NET, in modo da essere sullo stesso stack tecnologico. Non è necessario avere molte varianti all'interno dello stack di sviluppo delle applicazioni. Quindi, questo è un problema o una differenza tra questi due prodotti.
Il secondo aspetto è Windows contro Linux e poi sai cosa è disponibile in NCache e cosa è disponibile su Redis lato. Windows, dal punto di vista di NCache distribuzione, che è una distribuzione preferita ma abbiamo anche una distribuzione Linux disponibile con l'aiuto della nostra versione di .NET Core Server. Quindi, siamo completamente compatibili con Windows 2012, 2016, 2019. Le nostre immagini Docker sono disponibili anche per la variante Windows. Una variante di NCacheQuindi, puoi semplicemente scaricare la nostra immagine Docker e semplicemente far girare l'immagine Windows di NCache secondo necessità e lo supportiamo pienamente in ambiente di produzione. È un supporto ufficiale da parte nostra. Mentre, se si confronta Redis anche in Microsoft Azure il Redis è ospitato su Linux. L'approccio preferito, il modello di distribuzione preferito è Linux per RedisLa variante Windows è un progetto di terze parti. Microsoft Open Tech ne ha una versione convertita. Non esiste alcun supporto ufficiale da parte di Redis stesso. Il progetto stesso è stato accantonato. È pieno di bug, instabile e persino Azure Redis, come discusso in precedenza, utilizza la versione Linux e il grosso problema con questo è che non hai un supporto ufficiale da parte di Redis, Creatori di Redis oppure, da un certo punto di vista, se si desidera utilizzare il progetto open source e si desidera distribuirlo nella propria sede, è lì che si potrebbero riscontrare molti problemi.
Come parte di questo, vorrei anche evidenziare un altro aspetto: se si utilizza NCache on-premise e ora vuoi migrare da on-premise e vorresti utilizzare in Azure lo stesso software che funziona così com'è. Quindi, non è necessario apportare modifiche allo spostamento. NCache da on-prem ad Azure. Allo stesso modo, all'interno dei fornitori cloud, se si prevede di utilizzare NCache Su Azure puoi semplicemente migrare su AWS, se necessario. Perché lo stesso identico software è disponibile su tutte le piattaforme. Mentre, per quanto riguarda, Redis è preoccupato, Azure Redis è un modello ospitato che viene distribuito su Linux per quanto riguarda la distribuzione backend, ma non è disponibile la stessa variante in locale. Quindi, bisogna affidarsi all'open source. Redis o da un fornitore terzo. Anche in questo caso, bisogna optare per una variante commerciale, che è un prodotto completamente diverso.
Quindi, il punto principale che vorrei sottolineare qui è che Redis on-premise che è open source o una versione commerciale rispetto a Redis in Azzurro o Redis in AWS, che è Elastic Cache. Sono prodotti completamente separati. Quindi, c'è una transizione, ci sono molti cambiamenti. Non è possibile effettuare il porting Redis da un ambiente all'altro senza dover apportare modifiche. Mancano alcuni set di funzionalità. Alcune API sono diverse. Il modello di distribuzione è completamente diverso tra questi prodotti. Quindi, non ci sono cambiamenti se si mantiene 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 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 alla pari con NCache Su Windows. Disponiamo di immagini Docker. Completamente supportate in produzione e disponiamo di strumenti di monitoraggio e gestione completamente integrati, che puoi utilizzare. 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 distribuzioni Windows NCacheLinux è supportato anche su RedisQuindi, il suo supporto alla produzione è disponibile tramite Redis Lab. Azzurro Redis è ospitato anche sulla versione Linux. Quindi è supportato dal fornitore stesso.
Il secondo aspetto dopo la piattaforma è ancora una volta .NET e .NET Core, lo stack tecnologico. Abbiamo un client ufficiale disponibile. Lo abbiamo implementato. Lo supportiamo completamente e se ci sono set di funzionalità ed è per questo NCache è compatibile con tutti i sistemi. Quindi, se scegli ambienti on-premise, Azure o AWS, avrai lo stesso tipo di NCache e il suo Cliente disponibile su tutta la linea. E, se dovessero esserci modifiche da apportare, le forniremo ufficialmente perché siamo proprietari di tutto, così come del progetto in questione. Mentre, per Redis Si tratta di una terza parte. Quindi, per lingue diverse, il supporto proveniente da lingue diverse proviene anche da fornitori diversi. Potrebbe esserci una differenza nel set di funzionalità. Potrebbe esserci una differenza nel ciclo di rilascio. Quindi, per quanto riguarda la tecnologia e i requisiti del cliente, è necessario affidarsi a clienti terzi.
Quindi, vorrei evidenziare alcuni aspetti riguardanti NCache Si tratta di un prodotto nativo .NET e .NET Core. NCache è pienamente supportato su Windows, così come su Linux. Mentre, Redis non è molto stabile su Windows. È la versione porting di terze parti ed è disponibile il supporto Linux, quindi devi fare affidamento sul supporto Linux per quanto riguarda Redis è preoccupato. Quindi, provenendo da un background tecnologico Microsoft, questo è qualcosa su cui devi fare affidamento.
Prestazioni e scalabilità della cache
Il secondo aspetto riguarda le prestazioni della nostra cache. Anche questo è un aspetto molto importante.
Entrambi i prodotti sono molto veloci e questa è l'idea che ne rappresenta il vantaggio principale. NCache and RedisIl motivo principale per cui scegliereste un prodotto del genere è il miglioramento delle prestazioni. Abbiamo già stabilito che i database sono lenti e poco scalabili. Questi prodotti sono veloci e molto scalabili al confronto. Quindi, non toglierei nulla a RedisSolo 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 implementato il nostro protocollo di clustering basato su TCP/IP, che è altamente ottimizzato e molto robusto nelle prestazioni.
Tuttavia, anche qui ci sono alcune differenze. All'interno NCache Abbiamo molte funzionalità per migliorare le prestazioni. Di recente abbiamo anche realizzato un webinar in cui abbiamo affrontato sei diversi modi in cui è possibile migliorare NCache prestazioni. Se si imposta NCache di default, ti offrirà ottime prestazioni ma, in più, in base ai tuoi casi d'uso, puoi abilitare diverse funzionalità e migliorare ulteriormente le prestazioni. Una di queste funzionalità è la nostra cache client.
NCache: Cache client (Cache vicina)
La cache client è una funzionalità esclusiva di NCache. Redis non ha questa caratteristica.
Si tratta di una cache locale lato client, che è possibile anche per applicazioni serverless, dove è possibile avere una copia InProc all'interno del processo applicativo e/o, per le applicazioni basate su server, è possibile utilizzare una cache client esterna al processo. L'idea è che si eviteranno costosi spostamenti in rete verso il cluster di cache. Questa cache risparmiava già spostamenti verso le fonti dati back-end. Ora è possibile avere una cache intermedia e supporre di avere 100 elementi nella cache: se si immettono alcuni elementi sul lato applicazione, diciamo 10 elementi, questi 10 elementi verrebbero automaticamente riportati nella cache client e la prossima volta l'applicazione troverebbe quei dati più vicini all'applicazione stessa, risparmiando di conseguenza costosi spostamenti in rete.
E questa è una cache client sincronizzata. La sincronizzazione è gestita da NCacheQualsiasi cambiamento nel cache del cliente viene propagato sulla cache del server in quanto si tratta della copia master. Si tratta di un sottoinsieme dei dati e tale modifica viene propagata anche alle altre cache client. Se si dispone di uno scenario con dati di riferimento, ovvero con molte letture e successive scritture, consigliamo vivamente di attivare la cache client, che offre prestazioni molto elevate rispetto a una cache in esecuzione sul nostro database.
Di recente abbiamo realizzato una POC con uno dei nostri clienti, uno dei più grandi. Avevano un flusso di lavoro che richiedeva circa 46 secondi con le configurazioni predefinite. Stavano realizzando un sacco di NCache chiamate e recupero dati. Quindi, si trattava principalmente di un caso d'uso intensivo in lettura. Abbiamo attivato la cache client fuori processo, a proposito, ci sono due varianti: è possibile mantenerla fuori processo, il che significa che un processo di cache separato viene eseguito sul box dell'applicazione, oppure si può avere InProc, dove la cache client viene eseguita all'interno del processo dell'applicazione. InProc non ha serializzazione o overhead di comunicazione tra processi. Quindi, è estremamente veloce. Anche rispetto a OutProc è più veloce. Quindi, con quel cliente il flusso di lavoro impiegava circa 46 secondi per avviarsi. Poi abbiamo attivato la cache client fuori processo, riducendo il tempo a 3-4 secondi e poi abbiamo ulteriormente attivato la cache client InProc e siamo riusciti a ottenere tutto questo in 400-500 millisecondi. Da 46 secondi a 400-500 millisecondi, questo è il tipo di miglioramento di cui stiamo parlando e questa funzionalità è completamente non disponibile in nessun altro prodotto o nemmeno in altre varianti di InProc. Redis, di cui Redis Laboratori, inclusi progetti open source e Azure Redis.
Quindi, puoi ottimizzare le prestazioni utilizzando la cache del nostro client, senza dover modificare il codice. È solo una configurazione che puoi attivare.
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 si hanno dieci server e dati completamente distribuiti, una chiamata in blocco recupererebbe i dati da tutti quei server e il risultato consolidato verrebbe recuperato. Quindi, tutti questi elementi lavorano in combinazione tra loro per formulare un risultato che è completo per natura. Mentre Redis Le operazioni in blocco avvengono a livello di shard. Quindi, è necessario gestire i dati su un determinato shard. Questa è la limitazione. Se, ad esempio, si hanno più nodi nel cluster di cache e si hanno shard master disponibili, si potrebbero eseguire operazioni in blocco su un determinato shard.
Ecco, questo è il limite. Altrimenti, questa è una buona funzionalità per migliorare le prestazioni, in quanto invece di andare avanti e indietro per singole richieste, si invia una richiesta più grande e si ottengono tutti i dati in una volta sola, dimostrando così le proprie prestazioni.
La serializzazione è un'altra caratteristica e c'è un altro aspetto perché la maggior parte del tempo verrebbe spesa nella serializzazione e deserializzazione dei dati e questo è vero per NCache così come per RedisPer impostazione predefinita, entrambi i prodotti verrebbero serializzati e deserializzati, ma con NCache Esiste un modo per migliorare il sovraccarico di serializzazione e deserializzazione. Disponiamo di una serializzazione rapida e complessa, che ottimizzerebbe i tempi di serializzazione, normalmente richiesti dall'applicazione. Gli oggetti diventano complessi. Quindi, senza alcuna modifica al codice, è possibile definirli come tipi compatti e NCache garantirebbe l'esecuzione della serializzazione compatta su di essi in fase di esecuzione e migliorerebbe il sovraccarico di serializzazione e deserializzazione.
Infine, abbiamo anche una funzionalità di compressione. La compressione viene eseguita sul lato client. In genere, se si ha a che fare con oggetti più grandi, diciamo 2 MB, 3 MB o 500 kilobyte, si tratta di un oggetto più grande. Quindi, in genere consigliamo di gestire oggetti più piccoli, ma se si hanno oggetti più grandi, si verifica un notevole utilizzo della rete e quindi anche le prestazioni risultano ridotte. Con NCache puoi attivare la compressione. Questa è un'opzione senza modifica del codice, che non è disponibile su Redis lato e comprimerebbe automaticamente gli elementi durante l'aggiunta alla cache. Quindi, oggetti più piccoli vengono aggiunti e trasferiti, viaggiano tra l'applicazione e la cache e, allo stesso modo, lo stesso oggetto più piccolo viene recuperato anche sul lato applicazione. Gestire un payload più piccolo migliora le prestazioni delle applicazioni. Quindi, le prestazioni complessive dell'applicazione aumenterebbero se la compressione fosse attivata.
Quindi, consigliamo di attivare la compressione per qualsiasi oggetto di dimensioni superiori, diciamo, a 100 kilobyte. Esiste una soglia che è possibile abilitare e solo gli oggetti più grandi vengono compressi, mentre quelli più piccoli vengono lasciati così come sono.
Quindi, tutte queste funzionalità di miglioramento delle prestazioni, cache client, operazioni in blocco, serializzazione compatta, compressione, o non sono disponibili o RedisAd esempio, la cache client non è disponibile. Le operazioni in blocco sono disponibili, ma sono limitate. Non ci sono opzioni di ottimizzazione della serializzazione e la compressione non è disponibile. Quindi, è qui che si nota una netta differenza tra NCache and RedisDurante la serata, NCache è un pacchetto completo in cui sono integrate numerose funzionalità incentrate sulle prestazioni.
Alta disponibilità
Il segmento successivo è l'alta disponibilità ed è lì che vedrai un'enorme differenza di funzionalità tra NCache and RedisL'alta disponibilità è un altro aspetto in cui queste componenti possono essere confrontate. Per le applicazioni mission-critical, questo è un aspetto molto importante: è necessaria una fonte. Ora, si importano i dati che normalmente si trovano nel database e all'interno del database si avrebbe una sorta di mirroring, una sorta di backup, giusto?
Quindi, spostare i dati in un prodotto che utilizza una cache distribuita, sebbene migliori le prestazioni, è molto scalabile, ma l'elevata disponibilità è un aspetto molto importante. Per le applicazioni mission-critical, qualsiasi downtime non è accettabile. Avrebbe un impatto negativo sul business e sull'esperienza utente. Quindi, non è conveniente. Quindi, è molto importante che l'applicazione sia sempre in grado di ricevere risposta dalla cache in cui si trovano 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 auto-guarigione e parlerò di come, sai, funziona ma in confronto Redis utilizza master/slave. Quindi, essendo un'architettura peer-to-peer NCache consente di aggiungere e rimuovere automaticamente server, senza soluzione di continuità per le applicazioni. È possibile aggiungere tutti i server necessari. Ad esempio, se si è iniziato con 2 server e si desidera aggiungerne un terzo, è possibile farlo al volo. Non è necessario arrestare la cache o le applicazioni client connesse a tale cache. L'esperienza utente è fluida e senza interruzioni. Le applicazioni possono quindi continuare a funzionare senza tempi di inattività o perdite di dati grazie alle nostre funzionalità di elevata disponibilità e affidabilità dei dati. Redis Non è possibile aggiungere automaticamente nuovi shard. Perché non esiste un ribilanciamento automatico dei dati. Questo è il fulcro della natura dinamica del nostro cluster di cache. All'interno NCache, ribilancia automaticamente i dati se si desidera aggiungere nuovi server.
Quindi, ci sono due scenari. Uno in cui si aggiunge un nuovo server per aumentare la capacità e la scalabilità, e l'altro in cui si disattiva un server.
Quindi, affrontiamo prima lo scenario dell'aggiunta di un nodo. Un nuovo nodo viene aggiunto. Con NCache, i tuoi dati verranno distribuiti automaticamente.
Ad esempio, da 2 a 3 server, se ne aggiungi altri 2, avevi 6 elementi e aggiungevi un altro server a cui i dati esistenti sarebbero trasmessi, e che sarebbero bilanciati sul server appena aggiunto. Quindi, quel server prenderebbe una parte dei dati dai server esistenti e ciò avverrebbe automaticamente. È di natura dinamica. Quindi, si verifica un ribilanciamento automatico dei dati. Con Redis, si tratta di un ribilanciamento manuale dei dati e questo è vero per Azure Redis Perché in Azure sono disponibili diversi livelli. Ce n'è uno base, uno intermedio e uno avanzato. Il clustering entra in gioco solo con il livello avanzato, che è anche costoso e, inoltre, richiede almeno 3 server, il che rappresenta un'ulteriore limitazione.
Con NCache È anche possibile avere un clustering completamente operativo con soli 2 server e, per di più, l'aggiunta di un nuovo server richiede un ribilanciamento manuale dei dati. Questo è un grosso problema. Quindi, si avrebbe una sorta di limitazione sull'applicazione e sul momento in cui si pianifica di aggiungere capacità. Mentre, con NCache Puoi farlo in fase di esecuzione. Puoi aggiungere altri server al volo.
Il secondo aspetto è un server che non funziona. Quindi, abbiamo, all'interno Redis Abbiamo un concetto di master e slave. Un master replica i dati sullo slave. C'è uno shard dello slave. Quindi, il master deve replicare i dati e può essere in modalità sincrona o asincrona. In RedisSe uno shard slave si blocca, il master stesso si arresta e il cluster diventa inutilizzabile. Quindi, questo è un grosso problema e può accadere di continuo. Rigorosamente su distribuzioni on-premise in cui si dispone di un open source o Redis Distribuzione in laboratorio di RedisIn tal caso, se un server si blocca e si trova ad essere lo slave di uno shard master, il cluster stesso diventerebbe inutilizzabile. Pertanto, è necessario intervenire manualmente per ripristinare tale scenario. Mentre all'interno NCache È automatico. Quindi, qualsiasi server può andare giù, il nodo sopravvissuto potrebbe essere attivo o di backup.
Ad esempio, se questo server si arresta, questa è una partizione attiva, che ha anche una partizione di backup. Se l'intero server si arresta, il backup promuove la partizione attiva. La partizione di backup viene promossa ad attiva e si ottengono tutti i dati dal nodo attivo, con un failover di connessione integrato. Qualsiasi server inattivo, i client lo rileverebbero in fase di esecuzione e deciderebbero di eseguire il failover sui nodi attivi. Qui vorrei ribadire il concetto che con... Redis Sono necessari almeno 3 server. Questo è il concetto di regola della maggioranza. Il coordinatore del cluster deve vincere un'elezione. Questo non è il caso di NCacheÈ possibile avviare un cluster di cache completamente funzionante con soli 2 nodi e ottenere funzionalità di alta disponibilità complete. In caso di server inattivo, un nodo attivo è perfettamente in grado di funzionare senza problemi, cosa che non avviene con Redis.
Configurazioni dinamiche. È possibile modificare le configurazioni del cluster in fase di esecuzione, aggiungendo nuovi server, rimuovendo server o modificando alcune impostazioni del cluster di cache. Questa è un'opzione che è possibile applicare a un intero cluster in crash 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 disponibili su NCache lato, a cui puoi abbonarti. Puoi utilizzare strumenti di monitoraggio e gestione. Mentre, Redis non ha quelle caratteristiche.
Quindi, questo è un concetto molto importante. Lasciate che ve lo riassuma. Aggiungere e rimuovere un server in Redis È qualcosa che creerebbe molti problemi. Perché l'aggiunta di dati non verrebbe automaticamente ribilanciata. Quindi, non è un'architettura peer-to-peer al 100%. Quindi, il cluster di cache ha una capacità limitata. Allo stesso modo, se uno shard slave si guasta, 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 si guasta, devi eseguire manualmente il failover e iniziare a utilizzare i nodi sopravvissuti. Se aggiungi nuovi server, dovresti passare manualmente ai server appena aggiunti.
Quindi, queste sono tutte le limitazioni che avresti e, sai, sarei sorpreso di vedere l'utilizzo di una distribuzione di produzione di tale natura e ora devi aumentare la capacità o devi disattivare i server per manutenzione. Quindi, sarebbe molto difficile con prodotti come Redis. Mentre, NCache ti offre un'esperienza fluida, dove puoi aggiungere o rimuovere server al volo senza alcun impatto.
Partizioni dinamiche / frammenti
Ora, un altro concetto all'interno del cluster è il meccanismo di autoguarigione.
NCache Dispone di partizioni dinamiche. Aggiungendo altri server, i dati vengono ridistribuiti e vengono create nuove partizioni in fase di esecuzione. Allo stesso modo, se si disattiva un server, il cluster renderebbe disponibile il backup e si ripristinerebbe automaticamente, creando un cluster cache a 2 nodi funzionante se lo si disattivasse da 3 a 2, con conseguente miglioramento dell'affidabilità. Dispone di partizioni di replica, anch'esse disponibili su Redis come forma di schiavi ma la loro elevata disponibilità dipende dalla replicazione. Non hanno con Redis non avresti un'elevata disponibilità se non avessi shard slave configurati. Quindi, devi avere shard slave disponibili. Mentre, con NCache, abbiamo topologie.
Ad esempio, la cache partizionata, dove abbiamo shard master, partizioni master. Se questo server dovesse andare in crash, si avrebbe comunque un'elevata disponibilità perché i client lo rileverebbero, andrebbero in failover e inizierebbero a utilizzare il nodo di sopravvivenza. Avrebbero una perdita di dati e questo vale per Redis Anche. Perdita di dati perché non c'è replica, ma i dati sono comunque altamente disponibili. Abbiamo anche un miglioramento, che include il supporto per la replica. Se questo server si guasta, non solo il backup del server viene reso disponibile, ma anche i client eseguono automaticamente il failover. Quindi, Redis è limitato. La sua elevata disponibilità dipende dalla replicazione. Non è altamente disponibile se la replicazione non è attivata, il che è un altro fattore limitante.
E poi c'è il meccanismo di autoguarigione, anche se non è necessario alcun intervento manuale.
Se si inizia con 3 server, se ne arresta uno, si utilizza una partizione attiva, un master e si perde anche uno slave di un altro server. Quindi, in quel caso, il backup del server 3 era sul server 1, che viene attivato. Si unisce alle partizioni attive in fase di esecuzione. Non è necessario alcun intervento. È necessario un intervento manuale e quindi il server di partizione 2 creerà una partizione sana sul server 1. Quindi, il cluster si ripristinerà 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 arresta se lo shard slave si arresta. La ridistribuzione dei dati non è dinamica. L'alta disponibilità dipende dalla replicazione, il che non avviene con NCache. NCache garantisce un'elevata disponibilità anche senza replica.
Quindi, tutti questi vantaggi che ottieni da NCache, lo rende un prodotto molto più superiore perché queste sono completamente mancanti o limitate funzionalità in Redis e questo è vero per Azure RedisQuesto vale anche per l'open source perché si tratta di prodotti molto simili e questo vale anche per Redis Labs Redis offrendo anche.
NCache Demo
Ora dedicherò un po' di tempo a mostrare il prodotto reale in azione in modo che tu possa avere un'idea di come NCache viene configurato. Quindi, questo è il nostro ambiente demo. Ci ho lavorato. Quindi, creerò semplicemente una nuova cache. Questo è il nostro strumento di gestione web che viene installato con NCacheLa modalità di serializzazione può essere binaria o JSON. Dipende interamente da te. Darò un nome alla cache e ti mostrerò come creare un cluster di cache, connettere un'applicazione client e monitorarla e gestirla.
Quindi, manterrò tutto semplice perché l'obiettivo principale di questo webinar è 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 Sincronizzazione. Asincrona è più veloce, quindi opterò per quella. Dimensione del cluster di cache. Quindi specificherò questi nodi server dove NCache è già installato. Porta TCP. NCache è un protocollo di comunicazione di base TCP/IP. Quindi, semplificherò tutto e abiliterò semplicemente l'espulsione in modo che la cache si riempia. Quindi, rimuove automaticamente alcuni elementi dalla cache e di conseguenza fa spazio per gli elementi più recenti. Avvia questa cache e termina. Avvia 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. Ecco quanto è semplice configurare un cluster di cache e poi utilizzarlo, come vi mostrerò di seguito.
Supporto cloud (Azure e AWS)
Quindi, il nostro modello di servizio gestito sta per arrivare. La nostra prossima release si concentrerà su questo, credo tra due o tre settimane. Quindi, avremo un modello completamente gestito. NCache modello di software come servizio in Azure e in AWS.
Al momento, si tratterà di un modello basato su VM. Se si dispone di un ambiente on-premise, è possibile utilizzare box fisici o VM. Se si sceglie Azure, è necessario configurare la VM tramite il marketplace oppure è possibile configurare una VM e quindi installarla. NCache software scaricabile dal nostro sito web. Disponiamo anche di un ambiente containerizzato. Disponiamo di immagini Docker e siamo pienamente supportati su Azure Kubernetes Service, EKS - Elastic Kubernetes Service e qualsiasi altra piattaforma Kubernetes, ad esempio OpenShift. NCache è già completamente integrato e supportato su quelle piattaforme. Per quanto riguarda l'aspetto gestito, è qualcosa che sta per arrivare. Quindi, tra due o tre settimane sarà completamente disponibile.
Quindi, vi mostrerò la finestra delle statistiche, che è un contatore Perfmon e tra l'altro queste opzioni di monitoraggio sono disponibili per NCache, in termini di NCache sia in ambiente Windows che in ambiente Linux, giusto?
Quindi, eseguirò uno strumento di stress test. Credo che ce ne sia già uno in esecuzione per un'altra cache. Quindi, ne eseguirò un altro, simulando un carico fittizio sul nostro cluster di cache. Basta specificare il nome e il sistema rileva automaticamente i server utilizzando i file di configurazione e si connette ad essi.
Abbiamo quindi lo stato del cluster completamente connesso, le richieste al secondo che mostrano il throughput, la latenza in microsecondi medi per operazione di cache, aggiunte, recuperi, aggiornamenti, eliminazioni, dimensione della cache, CPU, memoria. In questo modo, si ottiene una vista di monitoraggio centralizzata. È possibile utilizzare questo strumento. È anche possibile utilizzare Windows PerfMon.
Per i sistemi basati su Linux offriamo il nostro monitoraggio personalizzato. Puoi quindi utilizzare il nostro strumento di monitoraggio direttamente anche per i server Linux, oppure puoi utilizzare qualsiasi strumento di terze parti per il monitoraggio. NCache Anche questo è stato un rapido sguardo al nostro processo di creazione della cache. Alcuni aspetti di monitoraggio e gestione.
Quindi, tornando indietro. Dato che abbiamo discusso alcuni dettagli, la prossima cosa di cui vorrei parlare è l'offerta cloud/supporto cloud. Ora Redis Di per sé, puoi scegliere una cache non gestita, puoi anche scegliere una cache gestita e poi c'è un servizio ospitato disponibile e l'opzione di gestione è di fornitori terzi. L'opzione ospitata è di Azure Redis, dove puoi avere una variante open source di Redis personalizzato da Microsoft e disponibile come modello ospitato. Mentre, sul NCache Sul lato, abbiamo un modello di server cache e un modello di VM. Ho già parlato dell'approccio basato sui container. È completamente compatibile sia con i container Windows che con quelli Linux. Abbiamo dimostrazioni video disponibili per Azure Service Fabric per container Windows, con dettagli sull'architettura dei microservizi. Abbiamo Azure Kubernetes Service che utilizza container Linux. EKS – Elastic Kubernetes Service e poi credo che abbiamo anche implementato Red Hat OpenShift Containers tramite Kubernetes.
Quindi, queste sono tutte opzioni di distribuzione dei container disponibili ed è flessibile, la sua piattaforma, sapete, non è specifica per una piattaforma. Quindi, è possibile distribuirlo su qualsiasi tipo di piattaforma containerizzata senza problemi. Il servizio gestito è in arrivo, quindi ne abbiamo già parlato. Quindi, è qualcosa in cui NCache avrebbe gestito il servizio, ma questo sarà nella nostra prossima versione.
Un aspetto importante è il vantaggio di utilizzare un modello VM: sebbene sia necessario connettersi a una VM anziché a un servizio, si ha il controllo totale. È possibile eseguire codice lato server, di cui parlerò più avanti, ma l'aspetto più importante è l'aspetto prestazionale. Abbiamo già discusso delle numerose funzionalità di performance all'interno di NCache, che mancano in RedisSe scegli di avere Azure Redis, dovresti connetterti all'infrastruttura di Azure. Quindi, quelle sono VM, che sono in esecuzione in una rete virtuale separata. Si trovano nelle vicinanze, ma anche in questo caso sono lontane. È diversa 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 delle reti virtuali delle applicazioni. Ad esempio, il servizio App, il sito web di Azure e i microservizi di Azure vengono eseguiti su una rete virtuale di Azure. È possibile scegliere di distribuire le VM di Azure sulla stessa rete virtuale e migliorare le prestazioni delle applicazioni. In base ai test effettuati in laboratorio, NCache era da quattro a cinque volte più veloce del modello SaaS di Redis che normalmente si trovano in Microsoft Azure. Questo è un aspetto molto importante che vorrei sottolineare.
Oltre a ciò, ottieni un ampio controllo sulla tua VM. Hai il pieno controllo sull'avvio di una cache, sull'aumento delle dimensioni e sulla piena capacità. Non ci sono limiti alle unità di richiesta, non ci sono limiti alle dimensioni, non c'è alcun impatto sull'utilizzo e non ti vengono addebitati costi. Puoi utilizzare la tua licenza, che può essere perpetua o in abbonamento, il che può essere molto flessibile in termini di licenze. Inoltre, puoi eseguire codice lato server sul tuo NCache server. È possibile gestirlo completamente. È possibile ottimizzarlo completamente. È possibile scrivere molte interfacce. Come read-through, write-through, write-behind, cache loader e alcune funzionalità di griglia di calcolo come MapReduce, Aggregator, processori di ingresso e questo è possibile solo con NCacheAnche il nostro modello SaaS, che sarebbe un modello ospitato che avrebbe tutte queste offerte disponibili, il che non accadrà con RedisQuesta è la nostra piattaforma.
Mantenere la cache fresca
Il prossimo segmento, i prossimi 15 minuti, li dedicherei al confronto dei livelli di funzionalità, e per questo ho definito alcuni segmenti. Quindi, inizierò se avete bisogno di mantenere aggiornata la cache, e questo è molto importante. Dovrebbe esserci un webinar separato proprio su questo, su come mantenere aggiornata la cache, in particolare per quanto riguarda le fonti dati back-end, in relazione ai casi d'uso della vostra applicazione.
Quindi, in confronto a Redis, Sai, NCache ha molte caratteristiche anche da questo lato.
Abbiamo una scadenza temporale, 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 ricaricamento. Per ricaricare, consentiamo di implementare un'interfaccia, chiamata gestore read-through, che è un codice lato server. Anche in questo caso, ciò è possibile perché NCache ti consente di dare, avere pieno accesso alle tue VM dove NCache è ospitato. Quindi, puoi distribuire codice lato server su NCache E l'uso NCache potenza di calcolo per supportarlo.
Puoi sincronizzare la tua cache con il database. NCache è molto forte nella sincronizzazione del database. Abbiamo una dipendenza da SQL. Abbiamo una dipendenza da DB che è compatibile solo con DB. Abbiamo stored procedure CLR .NET. Quindi, tutte queste funzionalità consentono di sincronizzare la cache con il database. L'idea è che se si verifica una modifica nel database, un record nel database cambia e quel record è memorizzato nella cache, queste due fonti possono non essere sincronizzate. Quindi, con NCache, se c'è una modifica nel database puoi invalidare automaticamente o ricaricare quei dati in NCache in fase di esecuzione. Questa è una caratteristica esclusiva di NCacheNessun altro prodotto offre questa funzionalità. Quindi, puoi avere una cache completamente sincronizzata con il tuo database back-end e questo non vale solo per i database relazionali: offriamo funzionalità anche per le fonti dati non relazionali.
La dipendenza da file è un'altra funzionalità che consente di rendere gli elementi dipendenti da un file. Se il contenuto del file cambia, gli elementi vengono rimossi o ricaricati automaticamente. La dipendenza personalizzata può essere utilizzata con qualsiasi origine. Potrebbe trattarsi di un database NoSQL, di un file system o relazionale, di qualsiasi connettore o servizio web. In questo modo, è possibile rendere gli elementi convalidati in base alle proprie esigenze flessibili. Abbiamo implementato questa dipendenza con Cosmos DB. Abbiamo quindi implementato la sincronizzazione di NCache con Cosmos DB. Se stai utilizzando NCache Oltre a Cosmos DB, è possibile utilizzare dipendenze personalizzate e credo di aver tenuto anche un webinar su questo argomento.
Gestione dei dati relazionali. Quindi, i dati relazionali hanno relazioni. Gli elementi nella cache sono coppie chiave-valore, quindi è possibile creare relazioni tra elementi diversi, cosa che non è disponibile su Redis lato. Quindi, dovresti trattare gli elementi in base al loro merito separato. Mentre, con NCache È possibile combinare gli elementi in gruppi uno-a-uno, uno-a-molti o molti-a-molti. L'elemento padre subisce una modifica, mentre l'elemento figlio può essere automaticamente invalidato o ricaricato, a seconda delle necessità.
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 funzionalità. E ancora una volta, questo è vero per Azure Redis che è comunque molto limitato. L'open source Redis è leggermente più avanti ma è ancora limitato in termini di funzionalità. Anche il Redis Lab, la versione commerciale di Redis, che non è dotato di queste caratteristiche.
È disponibile la ricerca SQL. È possibile cercare elementi all'interno NCache In base ai loro attributi oggetto. Gli oggetti vengono aggiunti alla cache. È possibile definire indici per i loro attributi. Ad esempio, i prodotti possono essere indicizzati per ID, prezzo e categoria, e ora è possibile eseguire ricerche su tali prodotti utilizzando questi attributi. Un esempio tipico sarebbe "select product" dove "product dot category" è qualcosa oppure "product dot price" è maggiore di 10 e "product dot price" è minore di 100. NCache Eseguirebbe la ricerca in memoria su tutti gli elementi, su tutti i server, consoliderebbe i risultati e restituirebbe il set di risultati. Quindi, non dovrete più occuparvi delle chiavi. Recuperate i dati in base a un criterio.
Sono disponibili anche le ricerche LINQ. Abbiamo app .NET e .NET Core. Se stai usando, sai, la ricerca LINQ, puoi eseguire la ricerca LINQ su 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 delle raccolte al loro interno NCache. Non è disponibile in Redis e puoi recuperare, aggiornare e rimuovere i dati in base a tali gruppi.
È possibile attribuire tag e tag denominati. Ad esempio, è possibile utilizzare parole chiave da associare ai propri articoli. Un esempio tipico è quello di poter etichettare tutti i clienti con un tag cliente. A tutti gli ordini con un tag ordine e agli ordini di un determinato cliente è possibile associare un ID cliente come tag. Quando si hanno bisogno di ordini, basta specificare "Ottieni tramite tag" e fornire gli ordini come tag, in modo da ottenere tutti gli ordini. Quando si hanno bisogno di ordini di un determinato cliente, è sufficiente specificare "Ottieni tramite qualsiasi tag" o "Ottieni tramite tag" e fornire l'ID cliente, in modo da ottenere tutti gli ordini, ma solo per quell'ID cliente. Questa è la flessibilità di utilizzo di tag e tag denominati che si ha con NCache. Redis non li supporta.
Codice .NET lato server
Abbiamo già detto che in genere utilizziamo il modello cache-aside, in cui prima si controllano i dati nella cache, se vengono trovati si ritorna, se non si trovano dati nella cache si va al database backend dell'applicazione, si recuperano i dati e li si carica nella cache. Quindi, se c'è un valore null, si recupera il valore null e si va al database. È possibile automatizzare questa operazione con l'aiuto del gestore Read-Thru. Si tratta di codice lato server che viene eseguito sul server. NCache Server. Anche il nostro servizio gestito avrebbe questa funzionalità. Quindi, si implementa questa interfaccia che consente di connettersi a qualsiasi sorgente dati. Potrebbe essere un servizio web, una sorgente dati relazionale o non relazionale, e ci sono una serie di metodi che verrebbero chiamati non appena viene trovato un valore null nella cache.
Quindi, si chiama il metodo Cache.Get, abilitando il flag Read-Thru. Se l'elemento non è nella cache, la chiamata viene passata al gestore Read-Thru e, di conseguenza, si recuperano i dati dal database backend passando attraverso il codice di quel gestore. Che è il codice utente in esecuzione su NCache lato server. Quindi, senza soluzione di continuità puoi passare attraverso NCache e ottieni i dati di cui hai bisogno.
Il write-through è l'opposto di questo, che è anche supportato e Redis non ha queste funzionalità con cui è possibile aggiornare qualcosa nella cache e ora si desidera aggiornare il database, è possibile aggiornare il database chiamando il gestore write-through. Si implementa e si registra questo gestore write-through e NCache lo chiamerei per aggiornare il database backend e write-behind è l'opposto. Qualsiasi aggiornamento sulla cache, l'applicazione client restituisce e NCache aggiornerebbe il database backend in modo asincrono dietro le quinte. Quindi, NCache può persino migliorare le 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 questa è una libreria di classi .NET e .NET Core puramente nativa che puoi implementare e registrare come interfacce di lettura e scrittura, cosa possibile con NCache.
Un'altra funzionalità è il Cache Loader. Con esso è possibile pre-popolare la cache implementando un'interfaccia e registrandosi con NCacheQuindi, ogni volta che riavvii la cache, carichi automaticamente alcuni dei tuoi dati importanti al suo interno NCache E funziona su tutti i server contemporaneamente. Quindi è superveloce. Puoi precompilare tutti i tuoi dati senza dover mai più accedere al database. Troveresti 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 principale per cui non è possibile utilizzare queste funzionalità. Innanzitutto, Redis non ha queste funzionalità, i moduli non sono supportati in Azure Redis o anche in open source RedisIl 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 prima a questo con NCache Al momento, su un modello VM, hai pieno accesso a dove distribuirlo, come controllarlo e come gestirlo. Quindi, hai il pieno controllo. Non è una scatola nera come Redis è.
Replicazione WAN per multi-datacenter
Ancora qualche dettaglio e poi concluderò. La replicazione WAN è un altro aspetto.
Attivo-passivo è supportato su Redis, dove è possibile trasferire l'intero data center, la cache da un data center all'altro. In NCacheAbbiamo un modello attivo-passivo. Quindi, una transizione unidirezionale dei dati da un data center all'altro. Abbiamo anche un modello attivo-attivo, che è un caso d'uso molto urgente e importante in cui entrambi i siti potrebbero essere attivi. Sono necessari gli aggiornamenti del sito uno sul sito due e viceversa. Quindi, questa non è una capacità 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 i dati vengono aggiornati su entrambi i siti, e questo è possibile anche tramite le nostre sessioni multi-sito. Quindi, questo è un altro spazio in cui NCache è un chiaro vincitore.
Topologie della cache
Poi altri dettagli. Topologie di caching. Abbiamo un elenco enorme di topologie di caching rispetto a Redis.
Quindi, in base ai diversi casi d'uso abbiamo Mirrored, Replicated, Partitioned e poi Partition Replica e poi abbiamo già discusso, abbiamo discusso su come NCache il clustering è migliore in generale e abbiamo molte più opzioni rispetto a Redis offerte.
Strumenti GUI - Amministrazione e monitoraggio della cache
Poi abbiamo gli strumenti GUI. Ecco un confronto. Gestore, monitor.
Considerando che abbiamo strumenti PowerShell, abbiamo strumenti di dump e reload, amministrazione completa, gli aspetti di monitoraggio sono integrati. Considerando che, Redis è limitato anche su quel fronte e come parte di ciò vi ho mostrato alcuni dettagli e questo è vero sia per Windows che per le distribuzioni Linux di NCache.
Funzionalità specifiche di ASP.NET
Alcune funzionalità di memorizzazione nella cache specifiche di ASP.NET.
Sessioni, abbiamo sessioni multi-sito, la condivisione di sessioni da ASP.NET ad ASP.NET Core è in arrivo. Sessioni multi-sito ASP.NET e ASP.NET Core sono disponibili. Stato della vista, caching dell'output. Redis ha solo sessioni, il che è molto basilare rispetto a NCacheIl blocco della sessione, la condivisione della sessione è parte di NCacheLa memorizzazione nella cache dell'output è supportata su entrambi i lati e, in aggiunta, disponiamo di SignalR Backplane e della memorizzazione nella cache delle risposte di ASP.NET Core. Tutto ciò costituisce un set completo di funzionalità per le vostre specifiche esigenze di caching web. Potete quindi esaminare 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 RedisHo un webinar separato sulla nostra messaggistica Pub/Sub. Quindi, vi consiglio vivamente di consultarlo in caso di domande. Quindi, credo che concluderò qui.
Integrazioni di terze parti
Infine, integrazioni di terze parti.
Disponiamo anche di NHibernate ed Entity Framework. AppFabric è disponibile l'involucro. Memcached wrapper è disponibile. Quindi, se stai passando da quei 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 concludere. Quindi, la prima cosa è che in qualsiasi momento, in qualsiasi momento, potete andare su www.alachisoft.com e scaricare una versione aziendale di NCache e ti mostreremo personalmente come funziona nel tuo ambiente. Quindi, ti invitiamo ad andare direttamente al sito web e a provare la versione Enterprise gratuita di 30 giorni. Sarà un piacere programmare una demo. Inoltre, metteremo a tua disposizione la registrazione di questo webinar. Quindi, tieni d'occhio le tue email e i social media quando te lo pubblicheremo. Se non abbiamo risposto alle tue domande oggi e so che ne abbiamo molte altre in arrivo e siamo proprio al limite, ti preghiamo di contattarci via email. support@alachisoft.com.
Se hai domande tecniche, avremo una risposta per te e se sei interessato a procedere e candidarti NCache nel tuo ambiente puoi contattare solo tu sales@alachisoft.com come pure.