Redis vs NCache
Webinaire enregistré
Par Ron Hussain et Zack Khan
NCache est un cache distribué natif .NET Open Source qui est très populaire parmi les transactions .NET élevées, .NET Core et applications Java. Redis est développé par Redis Labs et est actuellement utilisé par Microsoft dans Azure. Dans ce webinaire, découvrez comment NCache ainsi que Redis comparer les uns avec les autres. L'objectif de ce webinaire est de faciliter et d'accélérer votre tâche de comparaison des deux produits, en particulier sur les aspects qualitatifs tels que les fonctionnalités, les performances, l'évolutivité, la haute disponibilité, la fiabilité des données et l'administration.
Voici ce que couvre ce webinaire :
- Performances et évolutivité
- Élasticité du cache (haute disponibilité)
- Topologies de cache
- SQL & LINQ Recherche dans le cache
- Intégrations tierces (EF, EF Core, NHibernate, etc.)
Aujourd'hui, nous avons pour sujet de comparer deux produits très similaires mais également différents à bien des égards. Nous avons donc NCache qui est notre principal produit de mise en cache distribuée pour .NET et .NET Core applications, puis nous comparerons du point de vue des fonctionnalités avec Redis. Donc, nous avons beaucoup à couvrir là-dedans. Je vais passer en revue de nombreux détails techniques à partir de la plate-forme et de la pile technologique. Ensuite, nous parlerons du regroupement. Comment ces deux produits se comparent en ce qui concerne le clustering de cache et quels sont les différents avantages que vous tirez de l'utilisation de ces produits et en comparaison, comment NCache est mieux et ensuite je parlerai des différentes fonctionnalités. Nous irons comparaison fonctionnalité par fonctionnalité en ce qui concerne les différents cas d'utilisation dans lesquels vous pouvez utiliser ces produits, puis comment ces deux produits se comparent du point de vue de la comparaison des fonctionnalités.
Pour ce webinaire, j'ai choisi NCache Enterprise 5.0.2, dans la mesure où Redis est concerné, nous nous concentrerons principalement sur Azure Redis. C'est open source Redis 4.0.1.4. Mais, je voudrais aussi vous donner des détails sur la Redis projet open source, ainsi que, Redis laboratoire qui est la variante commerciale de Redis. Alors, on va comparer NCache avec toutes ces saveurs, mais notre objectif principal serait Microsoft Azure Redis, le modèle hébergé de Redis que vous pouvez obtenir dans Microsoft Azure.
Le problème de l'évolutivité
Donc, avant de commencer, je vais principalement passer en revue les détails d'introduction sur ces deux produits. Alors, pourquoi avez-vous exactement besoin d'une solution de mise en cache distribuée ?
Donc, et après cela, vous iriez de l'avant et compareriez différents produits. Ainsi, c'est généralement le défi d'évolutivité et de performances que vous pouvez rencontrer au sein de votre application. Il se peut que votre application reçoive beaucoup de données et bien que votre niveau d'application soit très évolutif, vous pouvez toujours créer une batterie de serveurs Web, vous pouvez ajouter plus de ressources au niveau de l'application, mais toutes ces instances d'application doivent revenir en arrière et se parler. -sources de données finales. Et, lorsque vous devez revenir en arrière et parler à ces sources de données, c'est là que vous rencontrez des problèmes de performances car les bases de données, généralement les bases de données relationnelles, sont lentes en termes de gestion de la charge transactionnelle.
Il y a un problème de performances qui leur est associé, puis en termes de mise à l'échelle, par exemple, si vous avez besoin d'une grande capacité de traitement des demandes ou d'exigences autour desquelles nous devons gérer un grand nombre de demandes et que vos applications génèrent beaucoup de charge utilisateur, la base de données n'est pas conçue pour gérer cette charge transactionnelle extrême. C'est très bon pour le stockage où vous pouvez stocker beaucoup de données, mais avoir une charge transactionnelle sur ces données est quelque chose pour lequel la base de données ne serait pas un très bon candidat. Il peut s'étouffer. Cela vous donnerait de la lenteur et l'expérience de l'utilisateur final pourrait être dégradée.
Ainsi, vous pouvez avoir un impact sur les performances et vous n'avez pas la possibilité d'augmenter la capacité au sein de l'architecture de l'application.
La solution : cache distribué en mémoire (NCache)
La solution est très simple, que vous utilisez un système de mise en cache distribué en mémoire comme NCache qui est ultra-rapide car c'est en mémoire. Ainsi, par rapport à une base de données relationnelle ou à un système de fichiers ou à toute autre source de données qui n'est pas basée sur la mémoire, si cela provient d'un disque par rapport au stockage de vos données sur la mémoire, en mémoire, cela le rendra super- vite. Ainsi, le premier avantage que vous en retirez est que vous obtenez des performances ultra-rapides NCache.
Le deuxième avantage est qu'il s'agit d'un cluster de cache. Ce n'est pas qu'une source unique. Vous pouvez commencer avec un serveur, mais généralement, nous vous recommandons d'avoir au moins deux serveurs et de créer un cluster de cache et dès que vous créez ce cluster de cache, cela s'améliorerait, si nous distribuons simplement la charge sur tous les serveurs et que vous continuez ajouter plus de serveurs au moment de l'exécution.
Ainsi, vous pouvez faire évoluer votre capacité, vous pouvez, vous le savez, augmenter la capacité au moment de l'exécution en ajoutant plus de serveurs et vous l'utilisez également en combinaison avec vos bases de données relationnelles principales. Ce n'est pas un remplacement de vos bases de données relationnelles conventionnelles et nous parlerons de certains cas d'utilisation plus tard.
Déploiement de cache distribué (NCache)
Voici un déploiement typique.
j'utilise NCache à titre d'exemple pour l'instant, mais plus loin dans cette présentation, nous comparerons comment Redis est déployé et comment NCache est déployé et quelles sont les flexibilités disponibles dans ces produits.
Donc pour NCache, c'est très souple. Vous pouvez choisir de le déployer sur Windows ainsi que sur un environnement Linux. Il est disponible sur site et pris en charge dans les environnements cloud. Il est disponible dans Azure ainsi que AWS marketplaces. Ainsi, vous pouvez simplement obtenir une image préconfigurée de NCache et commencez avec ça. Des conteneurs Docker pour Windows ainsi que pour Linux sont disponibles, que vous pouvez utiliser sur n'importe quelle plate-forme, où vous en avez besoin.
En règle générale, vos applications, qu'elles soient hébergées sur site ou dans le cloud, peuvent être un service d'application, il peut s'agir d'un Cloud service, il peut s'agir d'un microservice, d'un site Web Azure, tout type d'application peut s'y connecter dans le modèle client-serveur et il se situe entre votre application et votre base de données principale et c'est le modèle d'utilisation typique. L'idée ici est que vous stockeriez des données à l'intérieur NCache et par conséquent, vous économiseriez des déplacements coûteux vers la base de données principale. Vous économiseriez autant que possible les déplacements vers la base de données et chaque fois que vous auriez besoin d'aller dans la base de données, vous iriez toujours dans la base de données, récupéreriez des données et les mettriez dans le cache afin que la prochaine fois que les données existent et que vous n'ayez pas pour aller dans la base de données. Et, par conséquent, les performances et l'évolutivité globale de vos applications sont améliorées car vous disposez désormais d'un accès en mémoire qui améliore les performances. Vous avez plusieurs serveurs qui hébergent et servent vos demandes, vos demandes de données. Donc, c'est plus évolutif en comparaison. Et puis, il y a des fonctionnalités de haute disponibilité et de fiabilité des données qui sont également intégrées dans NCache protocole.
NCache peuvent être hébergés sur les mêmes boîtes, où vos applications sont en cours d'exécution. Ou il pourrait simplement s'agir d'un niveau distinct. Dans le cloud, l'approche préférée consisterait à utiliser un niveau de cache dédié distinct, puis vos applications, les instances d'application s'exécutent sur leur niveau respectif. Mais, les deux modèles sont pris en charge dans la mesure où NCache est concerné.
Quelques chiffres d'évolutivité. Nous avons récemment effectué ces tests dans notre laboratoire AWS, où nous avons simulé la charge des demandes de lecture et d'écriture et nous avons continué à augmenter la charge et après un certain point, lorsque nous avons vu que les serveurs étaient maximisés, nous avons augmenté le nombre de serveurs dans le cluster de cache. Ainsi, de 2 à 3 serveurs puis de 3 à 4, nous avons pu atteindre 2 millions de requêtes par seconde avec seulement 5 NCache serveurs et ce n'est pas, ce n'était pas une donnée touch-and-go. Il s'agissait de données d'application réelles mais simulées dans notre laboratoire AWS au sein de nos applications. Et, le facteur de latence a également été très optimisé. Nous avons pu réaliser tout cela avec une latence d'une microseconde. Ainsi, les performances des requêtes individuelles n'ont pas été dégradées, lorsque nous avons pu atteindre toute cette charge.
Cas d'utilisation courants : cache distribué
Certains cas d'utilisation et c'est quelque chose qui est commun pour Redis aussi mais je vais parler de la façon dont NCache comparerait.
Mise en cache des données d'application
Où vous cachez presque tout ce que vous récupérez normalement de la base de données principale et les données existent dans votre base de données et maintenant vous voulez le mettre en cache. Ainsi, vous économisez des déplacements coûteux vers la base de données et nous avons déjà établi que la base de données est lente et qu'elle n'est donc pas très optimale en termes de gestion de la charge des transactions. Nous avons beaucoup de fonctionnalités de synchronisation de base de données sur cette ligne, mais vous vous connectez simplement à NCache et utiliser essentiellement nos API pour établir une connexion, vous savez, faire des appels de données à NCache. Ainsi, vous pouvez mettre en cache presque n'importe quoi. Il peut s'agir d'objets de votre domaine, de collections, d'ensembles de données, d'images, de tout type de données liées à l'application pouvant être mises en cache à l'aide de notre modèle de mise en cache des données.
ASP.NET/ASP.NET Core Cache haute performance
Ensuite, nous avons notre ASP.NET et ASP.NET Core cache spécifique. C'est encore un cas d'utilisation technique, où vous pouvez l'utiliser pour ASP.NET ou ASP.NET Core mise en cache de l'état de la session. ASP.NET ou ASP.NET Core SignalR Backplane. NCache peut être branché en tant que fond de panier. Pour ASP.NET Core vous pouvez également l'utiliser pour la mise en cache des réponses. Interface IDistributedCache et sessions via IDistributedCache interface, ces deux fonctionnalités sont également prises en charge avec NCache et pour les applications héritées, vous pouvez également l'utiliser pour l'état d'affichage et la mise en cache de sortie. Je voulais vous poser une question rapide Ron.
Nous sommes entrés, la question est de savoir si NCache et Azure prennent-ils en charge un modèle de programmation sans serveur ?
Absolument. C'est quelque chose qu'en termes de déploiement Azure, vous pouvez soit déployer vos applications sur des serveurs, soit votre application, en ce qui concerne votre partie application, il peut également s'agir d'applications sans serveur. Vous pouvez simplement inclure nos packages NuGet dans votre application et ces applications peuvent simplement faire NCache appelle dès qu'ils en ont besoin. Ils n'ont même pas besoin d'avoir une installation de NCache ou avoir une configuration de serveur en ce qui concerne les ressources d'application. Mais, dans la mesure où, NCache le déploiement côté serveur lui-même est concerné car NCache est la source de données, elle doit donc avoir une machine virtuelle ou un ensemble de machines virtuelles, où vos applications se connectent, récupèrent et ajoutent des données.
Ainsi, depuis les serveurs, NCache du point de vue du serveur de cache, en tant que source dont vous avez besoin NCache serveurs, mais en ce qui concerne vos applications, celles-ci peuvent être strictement sans serveur et il n'y a aucun problème. Même l'architecture des microservices. C'est un exemple très courant, où les microservices, il y a beaucoup de microservices. Il pourrait y avoir une fonction Azure, qui ne fait que s'exécuter et qui traite beaucoup de données et ces données peuvent provenir de NCache. Alors, tu traites NCache comme source de données. Alors que vos applications peuvent être sans serveur et NCache est entièrement compatible avec ce modèle.
Pub / Sub Messagerie et événements
Ensuite, un autre cas d'utilisation est autour Messagerie Pub/Sub et cela tourne autour des microservices car c'est l'un des cas d'utilisation impressionnants où vous pouvez utiliser la messagerie pour les applications sans serveur. Les microservices sont des applications sans serveur faiblement couplées et établir une communication entre eux est un grand défi. Ainsi, vous pouvez utiliser notre plate-forme de messagerie Pub/Sub, où vous pouvez utiliser notre mécanisme de propagation d'événements asynchrones piloté par les événements. Lorsque plusieurs applications peuvent publier des messages sur NCache et les abonnés peuvent recevoir ces messages.
Étant donné qu'il s'agit d'un mécanisme basé sur des événements asynchrones, les applications de l'éditeur n'ont pas à attendre l'accusé de réception ou la livraison des messages et, de même, les abonnés n'ont pas à attendre ou à recevoir les messages. Ils sont avertis via des rappels lors des notifications. Donc, c'est très flexible et c'est un autre cas d'utilisation où vous pouvez utiliser NCache en tant que plateforme de messagerie Pub/Sub pour vos applications.
NCache HISTOIRE
Quelques détails supplémentaires, puis nous parlerons des différences entre NCache ainsi que Redis. NCache a été lancé en 2005. Il est sur le marché depuis plus de 15 ans maintenant. Version actuelle de NCache est 5.0, 15e version. Nous avons beaucoup, beaucoup de clients. NCache est également disponible en édition Open Source. Que vous pouvez télécharger depuis notre site Web ainsi que depuis le référentiel GitHub.
Aperçu NCache Clients
Certains de nos clients. Vous pouvez également obtenir une liste détaillée.
Plate-forme et technologie
Ensuite, nous parlerons de la façon dont NCache se compare à Redis et le premier segment est construit sur quelques détails d'introduction sur la technologie en général. Il s'agira d'informations sur la technologie de mise en cache distribuée. Maintenant, nous allons nous concentrer directement sur la façon dont NCache se compare à Redis et j'ai quelques segments que j'ai formulés.
Donc, la première section que nous avons définie est la plate-forme et la technologie et j'ai d'abord mentionné que nous ciblons NCache 5.0.2. Alors, NCache 5.0 SP2 est la version principale sur NCache site et de Redis point de vue nous allons utiliser Azure Redis à titre de comparaison et nous parlerons également de l'Open Source et Redis Lab dans le cadre de cela. La plupart de ces détails sont communs à différentes saveurs de Redis.
Cache .NET natif
Donc, venant d'un arrière-plan Azure, si vous envisagez de choisir un produit, la première chose serait la compatibilité avec la plate-forme.
Alors, NCache lui-même est écrit en 100% .NET. C'est un .NET natif ou.NET Core produit, en ce qui concerne vos applications, à droite. Donc, fondamentalement, il est écrit en .NET et principalement pour les applications .NET et il est déployé sur Windows Server 2016, 2019, voire 2012. Uniquement prérequis pour NCache is .NET framework or .NET Core d'ailleurs. Alors que, pour Redis, il est écrit en C++. NCache est écrit en .NET. Il est développé à 100 %, en fait C # est le principal langage technologique que nous utilisons et il est 100 % natif .NET et .NET Core. Alors que Redis est une solution basée sur C++ Linux.
Donc, du point de vue de Windows, de l'arrière-plan Windows et si vos applications sont écrites en .NET, le choix naturel serait d'utiliser un produit également écrit en .NET afin que vous soyez sur la même pile technologique. Vous n'avez pas besoin d'avoir beaucoup de variations dans la pile de développement d'applications. C'est donc un problème ou une différence entre ces deux produits.
Le deuxième aspect est Windows par rapport à Linux et vous savez alors ce qui est disponible dans NCache et ce qui est disponible sur Redis côté. Windows, d'un point de vue NCache déploiement, c'est un déploiement préféré mais nous avons également un déploiement Linux disponible avec l'aide de notre .NET Core Version du serveur. Nous sommes donc entièrement compatibles avec Windows 2012, 2016, 2019. Nos images Docker sont également disponibles pour la variante Windows. Une variante de NCache. Ainsi, vous pouvez simplement télécharger notre image Docker et simplement faire tourner l'image Windows de NCache selon les besoins et nous le soutenons entièrement dans l'environnement de production. C'est un soutien officiel de notre part. Alors que si vous comparez Redis même dans Microsoft Azure le Redis est hébergé sur Linux. L'approche préférée, le modèle de déploiement préféré est Linux pour Redis. La variante Windows est un projet tiers. Microsoft Open Tech en a une version portée. Il n'y a pas de soutien officiel de Redis lui-même. Le projet lui-même est abandonné. C'est buggé, instable et même l'Azure Redis, comme indiqué précédemment, utilise la version Linux et le gros problème avec cela est que vous n'avez pas de support officiel de la part de Redis, Les responsables de Redis ou d'un point de vue, si vous voulez utiliser le projet open source et que vous voulez le déployer chez vous, c'est là que vous verriez beaucoup de problèmes.
Dans ce cadre, je voudrais également souligner un autre aspect, si vous utilisez NCache sur site et que vous souhaitez maintenant migrer depuis sur site et que vous souhaitez utiliser dans Azure, le même logiciel fonctionne tel quel. Ainsi, aucun changement n'est nécessaire après le déménagement NCache de sur site à Azure. De même, au sein des fournisseurs de cloud, si vous prévoyez d'utiliser NCache sur Azure, vous pouvez simplement migrer vers AWS, si vous en avez besoin. Parce que le même logiciel est disponible à tous les niveaux sur toutes les plateformes. Alors que, dans la mesure où, Redis est concerné, Azure Redis est un modèle hébergé qui est déployé sur Linux en ce qui concerne le déploiement backend, mais vous n'avez pas la même variante disponible sur site. Donc, vous devez faire face à l'open source Redis ou un fournisseur tiers. Même vous devez opter pour une variante commerciale, qui est un produit complètement différent.
Donc, le point principal que je voudrais souligner ici est que Redis sur site qui est open source ou une version commerciale par rapport Redis en azur ou Redis dans AWS qui est Elastic Cache. Ce sont des produits complètement séparés. Donc, il y a une transition, il y a beaucoup de changement. Vous ne pouvez pas porter Redis d'un environnement à un autre sans passer par quelques changements. Certains ensembles de fonctionnalités sont manquants. Certaines API sont différentes. Le modèle de déploiement est complètement modifié entre ces produits. Donc, il n'y a aucun changement si vous gardez NCache sur site sur Windows ou Linux et maintenant vous voulez migrer et aller vers Azure, ce serait exactement le même produit et maintenant vous voulez le changer d'Azure à AWS, vous voulez changer de fournisseur de cloud, c'est plus flexible en comparaison pour Redis. Alors, NCache est beaucoup plus souple.
Prise en charge de Linux, NCache est entièrement compatible, officiellement pris en charge. Même les performances sont testées et les performances de Linux sont ultra-rapides, à égalité avec NCache sur Windows. Nous avons des images Docker disponibles. Entièrement pris en charge en production et nous avons des outils de surveillance et de gestion entièrement intégrés que vous pouvez, ce sont outils de gestion et de surveillance Web auquel vous pouvez accéder de n'importe où. Ainsi, même vos déploiements Linux peuvent être gérés et surveillés comme vous le feriez pour déployer, gérer et surveiller vos déploiements Windows avec NCache. Linux est également pris en charge sur Redis. Ainsi, son support de production disponible par Redis Laboratoire. Azur Redis est également hébergé sur la version Linux. Il est donc pris en charge par le fournisseur lui-même.
Le deuxième aspect après la plate-forme est encore le .NET et .NET Core, la pile technologique. Nous avons un client officiel disponible. Nous l'avons mis en œuvre. Nous le soutenons pleinement et s'il existe des ensembles de fonctionnalités et c'est pourquoi NCache est compatible à tous les niveaux. Ainsi, si vous choisissez des environnements sur site ou Azure ou AWS, vous aurez la même saveur de NCache et son client disponible à tous les niveaux. Et, s'il y a des changements qui doivent être apportés, nous fournirons ces changements officiellement parce que nous possédons tout ainsi que le projet concerné. Alors que, pour Redis c'est un tiers. Ainsi, pour différentes langues, le support provenant de différentes langues provient également de différents fournisseurs. Donc, il pourrait y avoir une différence d'ensemble de fonctionnalités. Il pourrait y avoir une différence de cycle de publication. Ainsi, vous devez vous fier à des clients tiers en ce qui concerne la technologie en ce qui concerne les exigences des clients.
Donc, je veux souligner certains aspects autour NCache étant natif .NET et .NET Core NCache est entièrement pris en charge sur Windows, ainsi que sur Linux. Alors que, Redis n'est pas très stable sous Windows. C'est la version portée par un tiers et le support Linux est disponible et c'est le cas, vous devez donc compter sur le support Linux dans la mesure où Redis est concerné. Donc, venant d'un milieu technologique Microsoft, c'est quelque chose sur lequel vous devez compter.
Performances et évolutivité du cache
Le deuxième aspect est la performance de notre cache. C'est aussi un aspect très important.
Les deux produits sont très rapides et c'est l'idée ici que le principal avantage de NCache ainsi que Redis, la principale raison pour laquelle vous choisiriez un tel produit est l'aspect amélioration des performances. Nous avons déjà établi que les bases de données sont lentes et peu évolutives. Ces produits sont rapides et très évolutifs en comparaison. Donc, je n'enlèverai rien à Redis. Seule la version Windows n'est pas stable et il y a des problèmes de performances, mais si vous avez la version Linux, c'est aussi très rapide et évolutif et c'est extrêmement rapide et NCache est également très rapide. C'est très évolutif. Nous avons notre propre protocole de clustering basé sur TCP/IP, qui est très optimisé et très robuste en termes de performances.
Cependant, il y a aussi quelques différences ici. Dans NCache nous avons beaucoup de fonctionnalités d'amélioration des performances. Nous avons également récemment organisé un webinaire, où nous avons abordé six façons différentes d'améliorer NCache performance. Si vous configurez NCache par défaut, cela vous donnera de très bonnes performances mais en plus, en fonction de vos cas d'utilisation, vous pouvez activer différentes fonctionnalités et vous pouvez encore améliorer les performances et l'une de ces fonctionnalités est notre cache client.
NCache: Cache client (près du cache)
Le cache client est une fonctionnalité unique à NCache. Redis n'a pas cette fonctionnalité.
Il s'agit d'un cache local côté client, ce qui est à nouveau possible même pour les applications sans serveur, où vous pouvez avoir une copie InProc dans votre processus d'application et/ou pour, vous savez, les applications basées sur un serveur, vous pouvez utiliser un cache client hors processus . L'idée ici est que cela permettrait d'économiser des déplacements coûteux sur le réseau vers votre cluster de cache. Ce cache épargnait déjà les déplacements vers les sources de données principales. Maintenant, vous pouvez avoir un cache entre les deux et supposer que vous avez 100 éléments dans le cache, si vous avez alimenté certains éléments du côté de l'application, vous savez, disons 10 éléments, ces 10 éléments seraient automatiquement ramenés dans le cache client et la prochaine fois votre application trouverait ces données plus près de votre application et, par conséquent, elle économiserait des déplacements coûteux sur le réseau.
Et, c'est un cache client synchronisé. La synchronisation est gérée par NCache. Tout changement dans le cache client est propagé sur le cache du serveur autant parce que c'est la copie maîtresse. Il s'agit d'un sous-ensemble des données et cette modification est également propagée aux autres caches clients. Si vous avez un scénario de données de référence. Si vous avez beaucoup de lectures puis d'écritures, nous vous recommandons fortement d'activer le cache client et cela vous donnerait de très bonnes performances par rapport à un cache qui s'exécute sur notre base de données.
Nous avons récemment fait un POC avec l'un de nos clients, l'un de nos plus gros clients. Où ils avaient un flux de travail, qui prenait environ 46 secondes avec les configurations par défaut. Ils faisaient un tas de NCache appels et récupération de données. Il s'agissait donc principalement d'un cas d'utilisation intensive en lecture. Nous avons activé le cache client hors processus, d'ailleurs il y a deux saveurs, vous pouvez le garder hors processus, ce qui signifie qu'un processus de cache séparé s'exécute sur la boîte d'application ou vous pouvez avoir InProc où le cache client s'exécute dans votre processus d'application. InProc n'a pas de sérialisation ou de processus pour traiter la surcharge de communication. Donc, c'est extrêmement rapide. Même en comparaison avec OutProc, c'est plus rapide. Ainsi, avec ce client, le flux de travail prenait environ 46 secondes pour démarrer. Ensuite, nous avons activé le cache client hors processus, cela l'a ramené à 3 à 4 secondes, puis nous l'avons encore activé pour activer le cache client InProc et nous avons pu réaliser tout cela en 400 à 500 millisecondes. De 46 secondes à 400 à 500 millisecondes, c'est le genre d'amélioration dont nous parlons et cette fonctionnalité est complètement indisponible dans tout autre produit ou même toute autre saveur de Redis, dont Redis Labs, y compris projet open source et Azure Redis.
Ainsi, vous pouvez ajuster les performances en utilisant notre cache client et c'est un travail sans changement de code. C'est juste une configuration que vous activez.
Les opérations en bloc sont prises en charge des deux côtés, mais avec NCache c'est que nos opérations en bloc fonctionnent sur l'ensemble du cluster de cache, ce qui signifie que si vous avez dix serveurs et que vous avez des données entièrement distribuées, un appel en bloc récupère les données de tous ces serveurs et le résultat consolidé est récupéré. Ainsi, tous ceux-ci travaillent en combinaison les uns avec les autres pour formuler un résultat, puis vous obtenez un résultat de nature complète. Alors que Redis les opérations en bloc sont au niveau des fragments. Vous devez donc gérer des données sur un fragment donné. Donc, c'est la limite. Si vous avez, disons, plusieurs nœuds dans le cluster de cache et que vous avez des fragments maîtres disponibles, vous pourrez donc effectuer des opérations en bloc sur un fragment donné.
Donc, c'est la limitation. Sinon, il s'agit d'une bonne fonctionnalité d'amélioration des performances où, au lieu d'aller et venir pour des demandes individuelles, vous envoyez une grosse demande et obtenez toutes les données en même temps et, par conséquent, vous prouvez vos performances.
La sérialisation, c'est une autre fonctionnalité et il y a un autre aspect car la plupart de votre temps serait consacré à la sérialisation et à la désérialisation des données et c'est vrai pour NCache ainsi que pour Redis. Par défaut, les deux produits seraient sérialisés et désérialisés, mais avec NCache il existe un moyen d'améliorer vos frais généraux de sérialisation et de désérialisation. Nous avons une sérialisation rapide-complexe, qui optimiserait votre temps de sérialisation, ce que prendrait normalement votre application. Vos objets deviennent complexes. Ainsi, sans aucun changement de code, vous pouvez les définir comme des types compacts et NCache garantirait qu'il exécute une sérialisation compacte sur eux au moment de l'exécution et cela améliorerait votre surcharge de sérialisation et de désérialisation.
Enfin, nous avons également une fonction de compression. La compression est effectuée côté client. En règle générale, si vous avez affaire à des objets plus gros, disons 2 Mo, 3 Mo ou disons 500 kilo-octets, c'est un objet plus gros. Donc, généralement, nous vous recommandons de traiter des objets plus petits, mais si vous avez des objets plus gros, il y a beaucoup d'utilisation du réseau et les performances se dégradent également. Avec NCache vous pouvez activer la compression. Il s'agit d'une option sans changement de code, qui n'est pas disponible sur le Redis côté et il compresserait automatiquement les éléments lors de l'ajout dans le cache. Ainsi, un objet plus petit est ajouté et transféré entre, se déplace entre votre application et le cache et, de la même manière, le même objet plus petit est également récupéré du côté de l'application. Traiter avec une charge utile plus petite améliore les performances de vos applications. Ainsi, les performances globales de l'application seraient améliorées si la compression était activée.
Donc, nous recommandons tout objet supérieur à, disons, 100 kilo-octets, vous devez absolument activer la compression et il y a un seuil que vous pouvez activer et seuls les objets plus gros sont compressés, les objets plus petits sont laissés tels quels.
Ainsi, toutes ces fonctionnalités d'amélioration des performances, le cache client, les opérations en bloc, la sérialisation compacte, la compression, ne sont pas disponibles ou Redis. Par exemple, le cache client n'est pas disponible. Les opérations en masse sont disponibles mais elles sont limitées. Il n'y a pas d'options d'optimisation de la sérialisation et la compression est quelque chose qui n'est pas disponible. Donc, c'est là que vous avez une nette différence entre NCache ainsi que Redis, Où NCache est un package complet dans lequel nous avons intégré de nombreuses fonctionnalités centrées sur les performances.
Haute Disponibilité
Le segment suivant est la haute disponibilité et c'est là que vous verrez une énorme différence de fonctionnalités entre NCache ainsi que Redis. La haute disponibilité est un autre aspect où ces pièces peuvent être comparées. Pour les applications critiques, c'est un aspect très important que vous avez besoin d'une source. Maintenant, vous apportez vos données qui sont normalement dans la base de données et dans la base de données, vous auriez une sorte de miroir, une sorte de sauvegarde, n'est-ce pas ?
Ainsi, avec les données déplacées dans un produit qui est un cache distribué, bien que cela améliore vos performances, il est très évolutif mais la haute disponibilité est un aspect très important. Pour les applications critiques, tout temps d'arrêt n'est pas acceptable. Cela aurait un impact sur votre entreprise et l'expérience utilisateur pourrait en être affectée. Donc, ce n'est pas abordable. Il est donc très important que votre application soit toujours en mesure d'obtenir une réponse du cache où les données existent. Donc, nous avons ici un énorme ensemble de différences de fonctionnalités.
Cluster de cache
NCache est un cluster de cache 100% peer-to-peer architectured.
C'est dynamique et auto-guérissant et je parlerai de comment, vous savez, ça marche mais en comparaison Redis utilise maître / esclave. Donc, étant une architecture peer-to-peer NCache vous permet d'ajouter et de supprimer automatiquement des serveurs et il est transparent pour vos applications. Vous pouvez continuer et ajouter autant de serveurs que nécessaire. Par exemple, vous avez commencé avec 2 serveurs. Maintenant que vous voulez ajouter un 3ème serveur, vous pouvez le faire à la volée. Vous n'avez pas besoin d'arrêter le cache ou les applications clientes qui sont connectées à ce cache. Une expérience homogène est observée. Ainsi, vos applications peuvent continuer à fonctionner sans interruption ni perte de données grâce à nos fonctionnalités de haute disponibilité et de fiabilité des données. Alors que, dans Redis vous ne pouvez pas ajouter automatiquement de nouvelles partitions. Parce qu'il n'y a pas de rééquilibrage automatique des données. C'est le cœur de la nature dynamique de notre cluster de cache. Dans NCache, il rééquilibre automatiquement les données si vous souhaitez ajouter de nouveaux serveurs.
Donc, il y a deux scénarios. L'un où vous ajoutez un nouveau serveur pour apporter de la capacité, pour apporter plus d'évolutivité et l'autre scénario est que vous arrêtez un serveur.
Alors, abordons d'abord le scénario d'ajout de nœud. Un nouveau nœud est rejoint. Avec NCache, vos données seraient automatiquement distribuées.
Par exemple, de 2 à 3 serveurs, si vous en ajoutez 2 de plus, vous aviez 6 éléments ici et que vous ajoutez un autre serveur vers lequel les données existantes seraient transmises, elles seront rééquilibrées vers le serveur nouvellement ajouté. Ainsi, ce serveur prendrait une partie des données des serveurs existants et cela se fera automatiquement. Il est de nature dynamique. Il y a donc un rééquilibrage automatique des données qui se produit. Avec Redis, c'est un rééquilibrage manuel des données et c'est vrai pour Azure Redis car il existe différents ensembles de niveaux disponibles dans Azure. Il y a un niveau de base, il y a un niveau intermédiaire et il y a un niveau avancé. Le clustering n'entre en jeu qu'avec avancé ici, ce qui est également coûteux et en plus, ils ont besoin d'au moins au moins 3 serveurs, ce qui est encore une fois une limitation.
Avec NCache vous pouvez même avoir un clustering entièrement opérationnel avec seulement 2 serveurs et en plus, l'ajout d'un nouveau serveur nécessite un rééquilibrage manuel des données. C'est un gros problème. Ainsi, vous auriez une sorte de limitation sur l'application et lorsque vous envisagez d'ajouter de la capacité. Alors qu'avec NCache vous pouvez y parvenir lors de l'exécution. Vous pouvez ajouter plus de serveurs à la volée.
Le deuxième aspect est un serveur qui tombe en panne. Ainsi, nous avons, à l'intérieur Redis nous avons un concept de maître et d'esclave. Un maître réplique les données vers l'esclave. Il y a un fragment d'esclave. Ainsi, le maître doit répliquer les données et cela peut être de manière synchrone ou asynchrone. Dans Redis, si un fragment esclave tombe en panne, le maître lui-même s'arrête, le cluster devient inutilisable. Donc, c'est un gros problème et cela peut arriver tout le temps. Strictement sur les déploiements sur site où vous avez une source ouverte ou Redis Déploiement en laboratoire de Redis. Dans ce cas, si un serveur tombait en panne et qu'il se trouvait être l'esclave d'un fragment maître, le cluster lui-même deviendrait inutilisable. Vous devez donc vous impliquer et effectuer une intervention manuelle pour vous remettre de ce scénario. Alors qu'à l'intérieur NCache c'est automatique. Ainsi, n'importe quel serveur peut tomber en panne, le nœud survivant et il peut être actif ou de sauvegarde.
Par exemple, ce serveur tombe en panne, c'est une partition active, il a aussi une partition de sauvegarde. Si tout ce serveur tombe en panne, la sauvegarde promeut l'actif. La partition de sauvegarde est promue active et vous obtenez toutes les données du nœud survivant et il y a un basculement de connexion qui y est intégré. Tout serveur tombant en panne, les clients le détecteraient au moment de l'exécution et ils décideraient et basculeraient vers les nœuds survivants et ici, je voudrais renforcer ce concept qu'avec le Redis vous avez besoin d'au moins 3 serveurs. C'est le concept de la règle de la majorité. Le coordinateur du cluster doit gagner une élection. Ce n'est pas le cas avec NCache. Vous pouvez démarrer un cluster de cache entièrement fonctionnel avec seulement 2 nœuds et vous offrira des fonctionnalités de haute disponibilité complètes. Tout serveur en panne, un nœud survivant est parfaitement capable de fonctionner sans aucun problème et ce n'est pas le cas avec Redis.
Configurations dynamiques. Vous pouvez modifier les configurations de cluster au moment de l'exécution, ce qui implique l'ajout de nouveaux serveurs, la suppression de serveurs ou la modification de certains paramètres sur le cluster de cache. C'est quelque chose que vous pouvez appliquer sur un cluster de plantage entier au moment de l'exécution sans l'arrêter. Alors que pour Redis, c'est limité. Vous devez appliquer manuellement de nombreuses configurations, puis de nombreux événements de santé de cluster disponibles sur NCache côté, auquel vous pouvez vous abonner. Vous pouvez utiliser des outils de surveillance et de gestion en plus. Alors que, Redis n'a pas ces fonctionnalités.
C'est donc une notion très importante. Permettez-moi de résumer pour vous. Ajouter et supprimer un serveur dans Redis est quelque chose qui vous poserait beaucoup de problèmes. Car l'ajout de données ne serait pas automatiquement rééquilibré. Donc, ce n'est pas une architecture peer-to-peer à cent pour cent. Ainsi, le cluster de cache est limité dans sa capacité. De même, si un fragment esclave tombe en panne, le cluster lui-même devient inutilisable. Parce qu'il y a un problème de distribution que vous devez maintenant gérer manuellement. Le basculement est également manuel, n'est-ce pas ? Ainsi, si un serveur tombe en panne, vous devez basculer manuellement et commencer à utiliser les nœuds survivants. Si vous ajoutez de nouveaux serveurs, il devra passer manuellement aux serveurs nouvellement ajoutés.
Donc, ce sont toutes les limitations que vous auriez et vous savez, je serais surpris de voir utiliser un déploiement de production d'une telle nature et maintenant vous devez apporter de la capacité ou vous devez arrêter les serveurs pour la maintenance. Donc, ce serait très difficile avec un produit comme Redis. Tandis que, NCache vous offre une expérience fluide. Où vous pouvez ajouter ou supprimer des serveurs à la volée sans rien affecter.
Partitions/fragments dynamiques
Maintenant, un autre concept à l'intérieur, vous savez, le cluster est le mécanisme d'auto-guérison.
NCache a des partitions dynamiques. Vous ajoutez plus de serveurs, les données obtiennent redistributaires, de nouvelles partitions sont formulées au moment de l'exécution. De même, vous arrêtez un serveur, le cluster rendrait la sauvegarde disponible et il se réparerait et formulerait un cluster de cache sain à 2 nœuds si vous le réduisiez de 3 à 2, puis l'aspect fiabilité. Il a des partitions de réplication à droite, qui sont également disponibles sur Redis sous la forme d'esclaves, mais leur haute disponibilité dépend de la réplication. Ils n'ont pas avec Redis vous n'auriez pas une haute disponibilité si vous n'avez pas configuré de partitions esclaves. Donc, vous devez avoir des fragments d'esclaves disponibles. Alors qu'avec la NCache, nous avons des topologies.
Par exemple, le cache partitionné, où nous avons des fragments maîtres, des partitions maîtres. Si ce serveur tombe en panne, vous avez toujours une haute disponibilité car les clients le détecteraient et ils basculeraient et commenceraient à utiliser le nœud de survie. Ils auraient une perte de données et c'est vrai pour Redis aussi bien. Perte de données car il n'y a pas de réplication mais elles sont toujours hautement disponibles et nous avons ensuite une amélioration à cela, où nous avons également un support de réplication. Si ce serveur tombe en panne, non seulement la sauvegarde du serveur est mise à disposition des clients automatiquement en cas de basculement. Alors, Redis est limité. Sa haute disponibilité dépend de la réplication. Il n'est pas hautement disponible, si la réplication n'est pas activée, ce qui est également un facteur limitant.
Et puis le mécanisme d'auto-guérison, bien qu'aucune intervention manuelle ne soit nécessaire.
Si vous commencez avec 3 serveurs, vous arrêtez un serveur, vous utilisez une partition active, un maître, puis vous perdez également un esclave d'un autre serveur. Donc, dans ce cas, la sauvegarde du serveur 3 était sur le serveur 1, donc, cela devient activé. Il se joint aux partitions actives lors de l'exécution. Aucune intervention n'est nécessaire. Un travail manuel est nécessaire, puis le serveur de partition 2 formulerait une partition saine sur le serveur 1. Ainsi, le cluster se guérirait automatiquement et c'est la nature dynamique de NCache en comparaison à Redis. Où pour Redis, les partitions ne peuvent pas être réajustées lors de l'exécution. Le cluster s'arrête si le fragment esclave tombe en panne. Les données redisLa contribution n'est pas dynamique. La haute disponibilité dépend de la réplication, ce qui n'est pas le cas avec NCache. NCache vous offre une haute disponibilité même sans réplication.
Donc, tous ces avantages que vous retirez de NCache, en fait un produit beaucoup plus supérieur car il manque complètement ou des fonctionnalités limitées dans Redis et c'est vrai pour Azure Redis. C'est aussi vrai pour l'open source car ce sont des produits très comparables et c'est aussi vrai pour Redis Labs Redis offre également.
NCache Démo
Je vais maintenant passer un peu de temps, vous savez, à montrer le produit réel en action afin que vous ayez un aperçu de la façon dont NCache est configuré. Voici donc notre environnement de démonstration. J'ai travaillé avec. Donc, je vais juste créer un nouveau cache. Il s'agit de notre outil de gestion Web qui est installé avec NCache. Le mode de sérialisation peut être binaire ou JSON. Cela dépend entièrement de vous. Je nommerai simplement le cache et je vous montrerai comment créer un cluster de cache, connecter une application cliente, le surveiller et le gérer également.
Donc, je vais garder tout simple parce que l'objectif principal de ce webinaire est d'environ NCache vs. Redis, donc, je vais garder tous les détails simples. Réplique partitionnée, c'est notre topologie la plus recommandée. Réplication asynchrone entre actif et sauvegarde. Ainsi, vous pouvez choisir Sync. Async est plus rapide donc, je vais y aller. Taille du cluster de cache. Ensuite, je vais spécifier ces nœuds de serveur où NCache est déjà installé. Port TCP. NCache est un protocole de communication de base TCP/IP. Donc, je vais garder tout simple et sur ce point, j'activerai simplement l'expulsion pour que ce cache soit plein. Ainsi, il supprime automatiquement certains éléments du cache et, par conséquent, fait de la place pour les éléments les plus récents. Commencez ce cache et terminez. Démarrez automatiquement ceci au démarrage du service, donc, chaque fois que mon serveur est redémarré, il rejoint automatiquement le cluster de cache et c'est tout. C'est aussi simple que cela de configurer un cluster de cache, puis de l'utiliser, ce que je vais vous montrer ensuite.
Prise en charge du cloud (Azure et AWS)
Donc, notre modèle de service géré arrive. Notre prochaine version se concentre sur ce qui est, je pense, dans deux à trois semaines. Ainsi, nous aurons un système entièrement géré NCache logiciel en tant que modèle de service dans Azure ainsi que dans AWS.
Pour le moment, ce sera soit le modèle VM. Si vous avez sur site, vous pouvez utiliser des boîtiers physiques ou VM. Si vous choisissez Azure, vous devez soit configurer votre machine virtuelle via le marché, soit simplement configurer une machine virtuelle, puis installer NCache logiciel en le téléchargeant à partir de notre site Web. Et puis nous avons aussi un environnement conteneurisé. Nous avons des images Docker et nous sommes entièrement pris en charge sur Azure Kubernetes Service, EKS - Elastic Kubernetes Service et tout autre, par exemple, la plateforme OpenShift Kubernetes, NCache est déjà entièrement intégré et entièrement pris en charge sur ces plates-formes. En ce qui concerne l'aspect géré, c'est quelque chose qui se prépare. Ainsi, dans deux à trois semaines, il serait entièrement disponible.
Donc, je vais vous montrer la fenêtre de statistiques, qui est un compteur de performances et au fait, ces options de surveillance sont disponibles pour NCache, en terme de NCache sur Windows ainsi que sur l'environnement Linux, n'est-ce pas ?
Donc, je vais exécuter un outil de test de stress. Je pense qu'il y en a déjà un en cours d'exécution pour un autre cache. Donc, je vais continuer et en exécuter un de plus et cela simulerait notre, une charge fictive sur notre cluster de cache. Vous n'avez qu'à spécifier le nom et il découvre automatiquement les serveurs en utilisant les fichiers de configuration et il s'y connecte simplement.
Ainsi, nous avons l'état du cluster entièrement connecté, les requêtes par seconde indiquant le débit, la latence par microseconde moyenne par opération de cache, les ajouts, les récupérations, les mises à jour, les suppressions, la taille du cache, le processeur, la mémoire. Ainsi, vous obtenez une vue de surveillance centralisée. Vous pouvez utiliser cet outil. Vous pouvez également utiliser Windows perfmon.
Pour Linux, nous avons notre surveillance personnalisée. Ainsi, vous pouvez également utiliser notre outil de surveillance directement pour les serveurs Linux et vous pouvez également utiliser n'importe quel outil tiers pour la surveillance NCache aussi bien. Donc, c'était un aperçu rapide de notre processus de création de cache. Quelques aspects de suivi et de gestion.
Alors, revenant. Puisque nous discutons de certains détails. La prochaine chose dont je voudrais discuter est l'offre cloud / le support cloud. À présent Redis lui-même, vous pouvez choisir un cache non géré, vous pouvez également choisir un cache géré, puis un service hébergé est disponible et l'option de gestion provient de fournisseurs tiers. L'option hébergée provient d'Azure Redis, où vous pouvez avoir une variante open source de Redis personnalisé par Microsoft et disponible en tant que modèle hébergé. Alors que, sur le NCache côté, nous avons le modèle de serveur de cache, le modèle de VM. J'ai déjà parlé de l'approche conteneur. Il est entièrement compatible avec Windows ainsi qu'avec les conteneurs Linux. Nous avons des démonstrations vidéo disponibles pour Azure Service Fabric pour les conteneurs Windows, les détails de l'architecture des microservices. Nous avons Azure Kubernetes Service qui utilise des conteneurs Linux. EKS – Elastic Kubernetes Service, puis je pense que nous avons également créé des conteneurs Red Hat OpenShift via Kubernetes.
Donc, ce sont toutes les options de déploiement de conteneurs disponibles et c'est flexible, sa plate-forme, vous savez, ce n'est pas spécifique à une plate-forme. Ainsi, vous pouvez le déployer sur n'importe quel type de plate-forme conteneurisée sans aucun problème. Le service géré arrive, nous en avons donc déjà discuté. Donc, c'est quelque chose où NCache aurait géré le service, mais c'est dans notre prochaine version.
Un aspect important est l'avantage d'utiliser un modèle de VM, bien que vous deviez vous connecter à une VM au lieu d'un service, mais vous contrôlez tout. Vous pouvez exécuter du code côté serveur que je couvrirai ensuite, mais l'aspect le plus important est l'aspect performance. Nous avons déjà expliqué qu'il existe de nombreuses fonctionnalités de performance dans NCache, qui manquent dans Redis. Si vous choisissez Azure Redis, vous devrez vous connecter à l'infrastructure Azure. Donc, ce sont des machines virtuelles, celles-ci s'exécutent dans un réseau virtuel séparé. Ceux-ci sont situés à proximité mais encore une fois ils sont loin. C'est différent de votre propre réseau virtuel que vous avez dans Microsoft Azure et où vous avez tous vos déploiements d'applications.
Avec NCache vous pouvez choisir notre NCache déploiement sur le même réseau virtuel que vos réseaux virtuels applicatifs. Par exemple, votre service d'application, votre site Web Azure, vos microservices Azure, ils s'exécutent sur un réseau virtuel Azure. Vous pouvez choisir de déployer des machines virtuelles Azure sur le même réseau virtuel et d'améliorer les performances de votre application. Sur la base de nos propres tests au sein de notre laboratoire, NCache était quatre à cinq fois plus rapide que le modèle SaaS de Redis que vous obtenez normalement dans Microsoft Azure. C'est donc un aspect très important que je voudrais souligner.
En plus de cela, vous obtenez beaucoup de contrôle sur votre machine virtuelle. Vous avez un contrôle total sur le démarrage d'un cache, en augmentant la taille, vous obtenez la pleine capacité. Il n'y a pas de limite sur les unités de demande, il n'y a pas de limite sur la taille, il n'y a pas d'empreinte d'utilisation et vous n'êtes pas facturé dans le cadre de cela. Vous apportez votre propre licence et cela pourrait aussi être perpétuel, cela pourrait aussi être une licence d'abonnement, cela pourrait être très flexible en termes de licence. En plus de cela, vous pouvez exécuter du code côté serveur sur votre NCache les serveurs. Vous pouvez entièrement gérer cela. Vous pouvez pleinement l'optimiser. Vous pouvez écrire beaucoup d'interfaces. Tels que la lecture, l'écriture, l'écriture derrière, le chargeur de cache et certaines fonctionnalités de grille de calcul telles que MapReduce, Aggregator, les processeurs d'entrée et cela n'est possible qu'avec NCache. Même notre modèle SaaS qui serait un modèle hébergé qui aurait toutes ces offres disponibles, ce qui ne sera pas le cas avec Redis. Donc, c'est notre plate-forme.
Garder le cache à jour
Prochain segment, les 15 prochaines minutes que je consacrerais à la comparaison des niveaux de fonctionnalités et pour cela, j'ai défini certains segments. Donc, je vais commencer si vous avez besoin de garder le cache à jour et c'est très important, il devrait y avoir un webinaire séparé juste à ce sujet, comment garder le cache à jour spécifiquement en ce qui concerne les sources de données back-end, en ce qui concerne l'utilisation de votre application cas.
Ainsi, par rapport à Redis, vous savez, NCache a également beaucoup de fonctionnalités de ce côté.
Nous avons l'expiration de la base de temps, qui est absolue et glissante, mais nous avons également un mécanisme de rechargement automatique disponible pour cela. Redis n'a qu'une expiration absolue et glissante sans aucun mécanisme de rechargement. Pour le rechargement, nous vous permettons d'implémenter une interface, appelée gestionnaire de lecture, qui est un code côté serveur. Encore une fois, c'est possible parce que NCache vous permet de donner, d'avoir un accès complet à vos VM où NCache est hébergé. Ainsi, vous pouvez déployer du code côté serveur par-dessus NCache et utilise NCache puissance de calcul pour le sauvegarder.
Vous pouvez synchroniser votre cache avec la base de données. NCache est très fort sur la synchronisation de la base de données. Nous avons une dépendance SQL. Nous avons une dépendance DB qui n'est conforme qu'à DB. Nous avons des procédures stockées .NET CLR. Ainsi, toutes ces fonctionnalités vous permettent de synchroniser votre cache avec la base de données. Et l'idée ici est que s'il y a un changement dans la base de données, un enregistrement dans la base de données change et que vous aviez cet enregistrement en cache, ces deux sources peuvent être désynchronisées. Donc avec NCache, s'il y a un changement dans la base de données, vous pouvez automatiquement invalider ou recharger ces données dans NCache lors de l'exécution. Il s'agit d'une caractéristique unique à NCache. Aucun autre produit n'a cette fonctionnalité. Ainsi, vous pouvez avoir un cache entièrement synchronisé avec votre base de données principale et cela n'est pas seulement vrai pour les bases de données relationnelles, nous avons également des fonctionnalités du côté des sources de données non relationnelles.
La dépendance de fichier est une autre fonctionnalité qui vous permet de rendre les éléments dépendants du fichier. Contenu du fichier, si le contenu change, vous obtenez des éléments supprimés ou rechargés automatiquement. Et la dépendance personnalisée, vous pouvez l'utiliser avec n'importe quelle source. Cela pourrait être un NoSQL database, il peut s'agir d'un système de fichiers ou relationnel, de n'importe quel connecteur, de n'importe quel service Web. Ainsi, vous pouvez valider les articles en fonction de vos exigences flexibles. Nous avons donné une implémentation de cette dépendance avec Cosmos DB. Nous avons donc implémenté la synchronisation de NCache avec CosmosDB. Si vous utilisez NCache aux côtés de cosmos DB, vous pouvez utiliser une dépendance personnalisée et je pense avoir également organisé un webinaire à ce sujet.
Manipulation de données relationnelles. Ainsi, les données relationnelles ont des relations. Les éléments du cache sont des paires de valeurs clés afin que vous puissiez établir des relations entre différents éléments et c'est quelque chose qui n'est pas disponible sur Redis côté. Ainsi, vous auriez à traiter les éléments sur leur mérite distinct. Alors qu'avec NCache vous pouvez combiner des éléments dans des groupes un-à-un, un-à-plusieurs ou plusieurs-à-plusieurs. L'élément parent subit une modification, l'élément enfant peut être automatiquement invalidé ou rechargé, selon les besoins.
Regroupement de données, recherche SQL et LINQ
Un autre aspect est le regroupement et la recherche de données, où NCache est très fort & Redis n'a aucune fonctionnalité. Et encore une fois, c'est vrai pour Azure Redis ce qui est quand même très limité. L'open-source Redis est un peu en avance mais reste limité en termes de fonctionnalités. Même le Redis Lab, la version commerciale de Redis, qui n'est pas équipé de ces fonctions.
La recherche SQL est disponible. Vous pouvez rechercher des éléments dans NCache en fonction de leurs attributs d'objet. Les objets sont ajoutés dans le cache. Vous pouvez définir des index pour leurs attributs. Par exemple, les produits peuvent être indexés pour leur ID, leur prix, leurs catégories et maintenant vous pouvez lancer une recherche sur ces produits en utilisant ces attributs. Un exemple typique serait de sélectionner un produit où la catégorie de point de produit est quelque chose ou le prix de point de produit est supérieur à 10 et le prix de point de produit est inférieur à 100 et NCache exécuterait une recherche en mémoire sur tous les éléments, sur tous les serveurs, consoliderait les résultats et vous ramènerait l'ensemble de résultats. Ainsi, vous n'avez plus à vous soucier des clés. Vous récupérez des données en fonction d'un critère.
Les recherches LINQ sont également disponibles. Nous avons .NET et .NET Core applications. Si vous utilisez, vous savez, la recherche LINQ, vous pouvez exécuter la recherche LINQ sur NCache aussi bien. C'est donc une caractéristique unique pour NCache De Redis n'a aucun soutien. Redis n'importe, toutes les saveurs de Redis, n'ont pas ce support.
Vous pouvez avoir des groupes, des sous-groupes. Vous pouvez logiquement faire des collectes à l'intérieur NCache. Ce n'est pas disponible dans Redis et vous pouvez récupérer, mettre à jour et supprimer des données en fonction de ces groupes.
Des balises et des balises nommées peuvent être attribuées. Par exemple, vous pouvez utiliser des mots-clés qui peuvent être attachés à vos articles. Un exemple typique serait que vous pouvez marquer tous les clients avec une balise client. Toutes les commandes avec une étiquette de commande et les commandes d'un certain client peuvent également avoir un identifiant client attaché comme étiquette. Lorsque vous avez besoin de commandes, il vous suffit de dire obtenir par étiquette et de fournir les commandes sous forme d'étiquette, afin que vous obteniez toutes les commandes. Lorsque vous avez besoin des commandes d'un certain client, vous dites passer par n'importe quelle étiquette ou obtenir par étiquette et donner l'identifiant client, cela vous permettrait d'obtenir toutes les commandes, mais uniquement pour cet identifiant client. Donc, c'est la flexibilité d'utiliser des balises et des balises nommées que vous avez avec NCache. Redis ne les supporte pas.
Code .NET côté serveur
Nous avons déjà expliqué que nous utilisons généralement un modèle de mise en cache, où vous vérifiez d'abord les données dans le cache, si elles s'y trouvent, vous revenez, si vous ne trouvez pas de données dans le cache, vous iriez à la base de données principale de votre application puis récupérez ces données et mettez-les dans le cache. Donc, il y a un null, vous récupérez null puis vous allez dans la base de données. Vous pouvez automatiser cela à l'aide du gestionnaire Read-Thru. C'est un code côté serveur qui s'exécute sur votre NCache les serveurs. Notre service géré aurait également cette fonctionnalité. Ainsi, vous implémentez cette interface qui vous permet de vous connecter à n'importe quelle source de données. Il peut s'agir d'un service Web, d'une source de données relationnelle ou d'une source de données non relationnelle et il existe un tas de méthodes qui seraient appelées dès qu'il y aurait un null trouvé dans le cache.
Ainsi, vous appelez la méthode Cache.Get, activez l'indicateur Read-Thru. Si l'élément n'est pas dans le cache, l'appel est transmis à votre gestionnaire de lecture et, par conséquent, vous récupérez les données de la base de données principale en passant par ce code de gestionnaire. Sur quel code utilisateur s'exécute-t-il ? NCache du côté serveur. Ainsi, en toute transparence, vous pouvez passer par NCache et obtenez les données dont vous avez besoin.
L'écriture directe est opposée à celle-ci, qui est également prise en charge et Redis n'a pas ces fonctionnalités où vous pouvez mettre à jour quelque chose dans le cache et maintenant vous voulez mettre à jour la base de données, vous pouvez mettre à jour la base de données en appelant votre gestionnaire d'écriture. Vous implémentez et enregistrez ce gestionnaire d'écriture immédiate et NCache l'appellerait pour mettre à jour la base de données principale et l'écriture différée est à l'opposé de celle-ci. Toute mise à jour sur le cache, l'application cliente revient et NCache mettrait à jour la base de données principale de manière asynchrone dans les coulisses. Alors, NCache peut même améliorer vos performances pour les opérations d'écriture sur la base de données, ce qui n'est pas possible avec Redis ou tout autre produit, si vous n'avez pas la possibilité d'exécuter du code côté serveur. Et c'est un .NET purement natif et .NET Core bibliothèques de classes que vous pouvez implémenter et enregistrer en tant qu'interfaces de lecture et d'écriture, ce qui est possible avec NCache.
Le chargeur de cache est une autre fonctionnalité. Où vous pouvez pré-remplir le cache en implémentant une interface et en vous inscrivant à NCache. Ainsi, chaque fois que vous redémarrez votre cache, vous chargez automatiquement certaines de vos données importantes à l'intérieur NCache et cela fonctionne sur tous les serveurs simultanément. Donc, c'est ultra-rapide. Ainsi, vous pouvez pré-remplir toutes vos données et vous n'aurez plus jamais à consulter la base de données. Vous trouverez toujours ces données parce que vous les avez préchargées.
Dépendance personnalisée, processeur d'entrée, ce sont encore des fonctionnalités qui ne sont uniques qu'à NCache et la raison principale pour laquelle vous ne pouvez pas utiliser ces fonctionnalités. D'abord, Redis ne dispose pas de ces fonctionnalités, les modules ne sont pas pris en charge dans Azure Redis ou même en open source Redis. Côté serveur, le code n'est pas possible avec Azure Redis. Principalement, parce que vous n'avez aucun accès aux machines virtuelles sous-jacentes et c'est la principale raison pour laquelle je faisais référence plus tôt à cela avec NCache sur un modèle de machine virtuelle pour le moment, vous avez un accès complet à l'endroit où vous le déployez, comment vous le contrôlez, comment vous le gérez. Ainsi, vous avez le plein contrôle. Ce n'est pas une boîte noire comme Redis est.
Réplication WAN pour plusieurs centres de données
Quelques détails supplémentaires et je conclurai cela. La réplication WAN est un autre aspect.
Actif-passif est pris en charge sur Redis, où vous pouvez transférer tout le centre de données, cache d'un centre de données à l'autre. Dans NCache, nous avons actif-passif. Donc, transition unidirectionnelle des données d'un centre de données à l'autre. Nous avons également actif-actif, ce qui est un cas d'utilisation très urgent et très important où vous pouvez avoir les deux sites actifs. Vous avez besoin des mises à jour du site un sur le site deux et vice versa. Donc, ce n'est pas une capacité sur Redis côté. Vous n'avez pas cette capacité, vous ne pouvez donc pas exécuter de sites actifs-actifs avec Redis. Avec NCache cela est vrai pour le cas d'utilisation de la mise en cache des données de votre application où vous avez des données sur les deux sites en cours de mise à jour et cela est également possible grâce à nos sessions multi-sites. Donc, c'est un autre espace où NCache est un gagnant clair.
Topologies de cache
Puis d'autres détails. Mise en cache des topologies. Nous avons une énorme liste de topologies de mise en cache par rapport à Redis.
Ainsi, sur la base de différents cas d'utilisation, nous avons mis en miroir, répliqué, partitionné, puis partition réplique, puis nous avons déjà débattu, nous avons discuté de la façon dont NCache le regroupement est meilleur en général et nous avons beaucoup plus d'options par rapport à Redis Offres.
Outils GUI - Administration et surveillance du cache
Ensuite, nous avons des outils graphiques. Voici une comparaison. Gestionnaire, moniteur.
Alors que nous avons des outils PowerShell, nous avons des outils de vidage et de rechargement, une administration complète, les aspects de surveillance y sont intégrés. Alors que, Redis est également limité sur ce front et dans le cadre de cela, je vous ai montré quelques détails et cela est vrai pour Windows ainsi que pour les déploiements Linux de NCache.
Fonctionnalités spécifiques à ASP.NET
Certaines fonctionnalités de mise en cache spécifiques à ASP.NET.
Sessions, nous avons des sessions multi-sites, ASP.NET à ASP.NET Core le partage de session arrive. ASP.NET et ASP multi-sites.NET Core des séances sont disponibles. État d'affichage, mise en cache de sortie. Redis n'a que des sessions, ce qui est très basique par rapport à NCache. Verrouillage de session, le partage de session fait partie de NCache. La mise en cache de sortie est prise en charge aux deux extrémités et nous avons en outre SignalR Backplane, ASP.NET Core mise en cache des réponses. Ainsi, tout cela constitue un ensemble complet de fonctionnalités pour vos besoins de mise en cache spécifiques au Web. Ainsi, vous pouvez examiner en détail l'ensemble des fonctionnalités.
Partage de données d'exécution avec des événements
Et puis nous avons la messagerie Pub/Sub.
Nous avons des événements au niveau des articles et nous avons également un système de notification d'événements basé sur des critères, qui est bien supérieur par rapport à Redis. J'ai un webinaire séparé sur notre messagerie Pub/Sub. Donc, je vous recommande fortement de consulter cela si vous avez des questions. Donc, je pense que je vais conclure à ce stade.
Intégrations tierces
Enfin, les intégrations tierces.
Nous avons également NHibernate et Entity Framework. AppFabric l'emballage est disponible. Memcached l'emballage est disponible. Ainsi, si vous passez de ces produits, vous pouvez passer en toute transparence à NCache en comparaison à Redis.
Sécurité et Cryptage
Quelques détails sur cryptage de sécurité et je pense que nous sommes déjà à l'heure.
Conclusion
C'est donc le bon moment pour le conclure. Donc, la première chose est que n'importe quand vous les gars, n'importe quand vous voulez, vous pouvez aller sur www.alachisoft.com et vous pouvez télécharger une version entreprise de NCache et nous vous montrerons personnellement comment cela fonctionne dans votre environnement. Nous vous encourageons donc à vous rendre directement sur le site Web et à bénéficier de cet essai gratuit de 30 jours d'entreprise. Planifier une démo va être notre plaisir. En plus de cela, nous aurons à votre disposition un enregistrement de ce webinaire. Alors, gardez un œil sur vos e-mails et sur les réseaux sociaux lorsque nous vous en informons. Si nous n'avons pas répondu à vos questions aujourd'hui et que je sais que nous en avons beaucoup d'autres à venir et que nous sommes juste au bord, s'il vous plaît, envoyez simplement un e-mail support@alachisoft.com.
Si vous avez des questions techniques, nous aurons une réponse pour vous et si vous souhaitez avancer et postuler NCache dans votre environnement, vous pouvez contacter sales@alachisoft.com également.