Redis vs NCache
Webinaire enregistré
Par Ron Hussain et Zack Khan
NCache est un cache distribué open source natif .NET très populaire parmi les applications .NET, .NET Core et Java à fort volume de transactions. Redis est développé par Redis Labs et est actuellement utilisé par Microsoft dans Azure. Dans ce webinaire, découvrez comment NCache et 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 allons comparer deux produits très similaires, mais aussi différents à bien des égards. NCache qui est notre principal produit de mise en cache distribuée pour les applications .NET et .NET Core, et nous le comparerons ensuite du point de vue des fonctionnalités avec RedisNous avons beaucoup à aborder. Je vais aborder de nombreux détails techniques, en commençant par la plateforme et la pile technologique. Nous aborderons ensuite le clustering. Comment ces deux produits se comparent-ils en termes de clustering de cache ? Quels sont les différents avantages de ces produits ? NCache est meilleur, puis 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 en ce qui concerne, 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 le Redis projet open source, ainsi que, Redis laboratoire qui est la variante commerciale de Redis. Alors, nous allons 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é
Avant de commencer, je vais d'abord aborder les détails de ces deux produits. Alors, pourquoi avez-vous besoin d'une solution de mise en cache distribuée ?
Ensuite, vous comparez différents produits. Généralement, votre application rencontre des problèmes d'évolutivité et de performances. Elle peut recevoir une charge de données importante et, malgré sa grande évolutivité, vous pouvez créer une ferme web et y ajouter des ressources. Cependant, toutes ces instances doivent communiquer avec les sources de données back-end. C'est lors de ces échanges avec ces sources de données que les performances se font sentir, car les bases de données, généralement relationnelles, sont lentes à gérer la charge transactionnelle.
Elles posent un problème de performance. En termes de scalabilité, par exemple, si vous avez besoin d'une capacité de traitement des requêtes importante ou si vos applications génèrent une charge utilisateur importante, la base de données n'est pas conçue pour gérer une charge transactionnelle aussi importante. Elle est idéale pour le stockage, car elle permet de stocker de grandes quantités de données, mais gérer une charge transactionnelle sur ces données est une solution peu adaptée. Elle risque de s'engorger, d'entraîner des ralentissements et de dégrader l'expérience utilisateur.
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 : vous utilisez un système de mise en cache distribué en mémoire comme NCache Ce qui est ultra-rapide car il est en mémoire. Ainsi, par rapport à une base de données relationnelle, un système de fichiers ou toute autre source de données non basée sur la mémoire, si les données proviennent d'un disque, elles sont ultra-rapides. Le premier avantage est que vous obtenez des performances ultra-rapides. NCache.
Le deuxième avantage est qu'il s'agit d'un cluster de cache. Il ne s'agit pas d'une source unique. Vous pouvez commencer avec un seul serveur, mais nous recommandons généralement d'en avoir au moins deux et de créer un cluster de cache. Dès sa création, la performance s'améliorera si vous répartissez la charge sur tous les serveurs et ajoutez des serveurs supplémentaires au fur et à mesure de l'exécution.
Vous pouvez donc faire évoluer votre capacité, l'augmenter en temps réel en ajoutant des serveurs et l'utiliser en combinaison avec vos bases de données relationnelles back-end. Il ne s'agit pas d'un remplacement des bases de données relationnelles classiques ; nous aborderons quelques cas d'utilisation ultérieurement.
Déploiement de cache distribué (NCache)
Voici un déploiement typique.
j'utilise NCache à titre d'exemple pour l'instant, mais plus tard 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, il est très flexible. Vous pouvez le déployer sur Windows comme sur Linux. Il est disponible sur site et pris en charge dans les environnements cloud. Il est disponible sur Azure et sur les marketplaces AWS. Vous pouvez donc obtenir une image préconfigurée de NCache et commencez à l'utiliser. Des conteneurs Docker pour Windows et Linux sont disponibles, utilisables sur toutes les plateformes où vous en avez besoin.
Généralement, vos applications, qu'elles soient hébergées sur site ou dans le cloud, peuvent être des services d'application, des services cloud, des microservices ou des sites web Azure. N'importe quelle application peut s'y connecter selon le modèle client-serveur. L'application s'intercale entre votre application et votre base de données back-end. C'est le modèle d'utilisation typique. L'idée est de stocker les données à l'intérieur. NCache Vous économiserez ainsi des déplacements coûteux vers la base de données principale. Vous réduirez ainsi au maximum les déplacements vers la base de données et, chaque fois que vous aurez besoin d'y accéder, vous y accéderez systématiquement, récupérerez les données et les placerez dans le cache. Ainsi, la prochaine fois que ces données seront disponibles, vous n'aurez plus besoin d'y accéder. De plus, les performances et l'évolutivité globale de vos applications seront améliorées grâce à l'accès en mémoire, ce qui optimise les performances. Plusieurs serveurs hébergent et traitent vos requêtes, vos demandes de données. L'évolutivité est donc plus importante. Enfin, des fonctionnalités de haute disponibilité et de fiabilité des données sont également intégrées. NCache protocole.
NCache Les applications peuvent être hébergées sur les mêmes serveurs que ceux où elles sont exécutées. Il peut également s'agir d'un niveau distinct. Dans le cloud, l'approche privilégiée consiste à utiliser un niveau de cache dédié distinct, puis à exécuter les applications et les instances sur leur niveau respectif. Cependant, les deux modèles sont pris en charge. NCache est concerné.
Quelques chiffres sur l'évolutivité. Nous avons récemment réalisé ces tests dans notre laboratoire AWS. Nous avons simulé la charge des requêtes en lecture et en écriture, puis nous avons continué à augmenter la charge. Après un certain temps, lorsque nous avons constaté que les serveurs atteignaient leur limite, 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 un débit de 2 millions de requêtes par seconde avec seulement 5 serveurs. NCache Les données des serveurs ne sont pas aléatoires. Il s'agit de données d'application réelles, simulées dans notre laboratoire AWS. De plus, le facteur de latence a été optimisé. Nous avons pu réaliser tout cela avec une latence de quelques microsecondes. Ainsi, les performances des requêtes individuelles n'ont pas été dégradées, même lorsque nous avons pu gérer toute cette charge.
Cas d'utilisation courants : cache distribué
Certains cas d'utilisation et c'est quelque chose qui est commun pour Redis mais je vais parler de la façon dont NCache je comparerais.
Mise en cache des données d'application
Vous mettez en cache presque tout ce que vous récupérez habituellement depuis la base de données principale. Les données existent déjà dans votre base de données et vous souhaitez maintenant les mettre en cache. Cela vous évite de coûteux déplacements vers la base de données. Or, nous avons déjà constaté que la base de données est lente et n'est pas optimale en termes de gestion de la charge des transactions. Cette ligne propose de nombreuses fonctionnalités de synchronisation de base de données, mais il suffit de se connecter à NCache et utiliser essentiellement nos API pour établir des connexions, vous savez, effectuer des appels de données vers NCacheVous pouvez donc mettre en cache presque tout : objets de votre domaine, collections, jeux de données, images, etc., et tout type de données applicatives peut être mis en cache grâce à notre modèle de mise en cache.
Mise en cache ASP.NET / ASP.NET Core
Nous avons ensuite notre système de cache spécifique à ASP.NET et ASP.NET Core. Il s'agit là encore d'un cas d'utilisation technique, permettant la mise en cache de l'état de session pour ASP.NET ou ASP.NET Core, ainsi que pour le backplane SignalR d'ASP.NET ou ASP.NET Core. NCache Peut être utilisé comme carte mère. Pour ASP.NET Core, il peut également servir à la mise en cache des réponses. Interface IDistributedCache et gestion des 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 te poser une question rapide, Ron.
Nous sommes entrés, la question est de savoir si NCache et Azure prend en charge un modèle de programmation sans serveur ?
Absolument. Concernant le déploiement Azure, vos applications peuvent être déployées sur des serveurs ou, pour la partie applicative, sur des applications sans serveur. Il suffit d'inclure nos packages NuGet dans votre application, et ces applications peuvent être créées. NCache appellent quand ils en ont besoin. Ils n'ont même pas besoin d'installer quoi que ce soit NCache ou avoir un serveur configuré pour les ressources applicatives. Mais, en ce qui concerne… NCache le déploiement côté serveur lui-même est concerné car NCache est la source de données, elle doit donc disposer d'une machine virtuelle ou d'un ensemble de machines virtuelles, où vos applications se connectent, récupèrent et ajoutent des données.
Donc, à partir des serveurs, NCache du point de vue du serveur de cache, en tant que source dont vous avez besoin NCache Des serveurs, mais pour vos applications, ils pourraient être strictement sans serveur et ne poser aucun problème. Même une architecture de microservices est un exemple très courant : il existe de nombreux microservices. Il pourrait s'agir d'une fonction Azure, qui se contente d'exécuter des tâches et qui traite un volume important de données, provenant de sources diverses. NCache. Alors, vous traitez NCache comme source de données. Vos applications peuvent être sans serveur et NCache est entièrement compatible avec ce modèle.
Messagerie et événements Pub/Sub
Ensuite, un autre cas d’utilisation se présente Messagerie Pub/Sub Cela s'articule autour des microservices, car c'est l'un des cas d'utilisation les plus intéressants pour la messagerie d'applications sans serveur. Les microservices sont des applications sans serveur faiblement couplées, et établir une communication entre elles représente un défi majeur. Vous pouvez donc utiliser notre plateforme de messagerie Pub/Sub, qui exploite notre mécanisme de propagation asynchrone d'événements piloté par événements. Plusieurs applications peuvent ainsi publier des messages. NCache et les abonnés peuvent recevoir ces messages.
Grâce à son mécanisme asynchrone piloté par événements, les applications d'édition n'ont pas besoin d'attendre l'accusé de réception ou la livraison des messages, et les abonnés n'ont pas besoin d'attendre ni de s'abonner aux messages. Ils sont notifiés par des rappels lors de la réception des notifications. Sa grande flexibilité en fait un autre cas d'utilisation intéressant. NCache en tant que plateforme de messagerie Pub/Sub pour vos applications.
NCache Histoire
Quelques détails supplémentaires et nous parlerons ensuite des différences entre NCache et Redis. NCache a été lancé en 2005. Il est sur le marché depuis plus de 15 ans maintenant. Version actuelle de NCache Il s'agit de la version 5.0, 15e. Nous avons de très nombreux clients. NCache est également disponible en version Open Source. Vous pouvez la télécharger depuis notre site web et depuis le dépôt GitHub.
Aperçu NCache Clients
Quelques-uns de nos clients. Vous pouvez également consulter la liste détaillée.
Plateforme et technologie
Ensuite, nous parlerons de la façon dont NCache se compare à Redis Le premier segment s'appuie sur quelques informations générales concernant la technologie. Il s'agira d'informations sur la technologie de mise en cache distribuée. Nous allons maintenant nous concentrer sur la manière 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 plateforme et la technologie et j'ai initialement mentionné que nous ciblons NCache 5.0.2. Alors, NCache 5.0 SP2 est la version principale sur NCache site et de Redis Du point de vue de la sécurité, nous utiliserons Azure Redis à titre de comparaison et nous parlerons également de l'Open Source et Redis Le laboratoire en fait partie. La plupart de ces détails sont communs à différentes saveurs de Redis.
Cache .NET natif
Donc, venant d’un environnement Azure, si vous envisagez de choisir un produit, la première chose serait la compatibilité avec la plateforme.
Alors, NCache Il est entièrement écrit en .NET. C'est un produit .NET ou .NET Core natif, pour vos applications. En résumé, il est conçu en .NET et principalement pour les applications .NET, et il est déployé sur Windows Server 2016, 2019, voire 2012. Seule condition préalable : NCache Il s'agit du framework .NET ou de .NET Core. En revanche, pour Redis, c'est écrit en C++. NCache est écrit en .NET. Il est développé à 100 %, plus précisément en C#, le langage technologique principal utilisé, et il est 100 % natif .NET et .NET Core. Redis est une solution basée sur C++ Linux.
Du point de vue de Windows, et si vos applications sont écrites en .NET, le choix naturel serait d'utiliser un produit également écrit en .NET afin d'utiliser la même pile technologique. Il n'est pas nécessaire d'avoir beaucoup de variations au sein de la pile de développement applicatif. C'est donc un problème, une différence entre ces deux produits.
Le deuxième aspect est celui de Windows par rapport à Linux et ensuite vous savez ce qui est disponible dans NCache et ce qui est disponible sur Redis côté. Windows, du point de vue de NCache Nous proposons un déploiement Linux, qui est notre déploiement privilégié, mais nous proposons également un déploiement Linux grâce à notre version de .NET Core Server. Nous sommes donc entièrement compatibles avec Windows 2012, 2016 et 2019. Nos images Docker sont également disponibles pour Windows. NCache. Vous pouvez donc simplement télécharger notre image Docker et faire tourner l'image Windows de NCache selon les besoins et nous le prenons entièrement en charge en production. Il s'agit d'un support officiel de notre part. En revanche, si vous comparez Redis même dans Microsoft Azure, le Redis est hébergé sur Linux. L'approche et le modèle de déploiement privilégiés sont Linux pour RedisLa variante Windows est un projet tiers. Microsoft Open Tech en propose une version portée. Elle ne bénéficie pas du support officiel. Redis Le projet lui-même est abandonné. Il est bogué, instable et même 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 du Redis, Les responsables de Redis ou d'un point de vue, si vous souhaitez utiliser le projet open source et que vous souhaitez le déployer sur vos propres locaux, c'est là que vous verrez beaucoup de problèmes.
Dans ce cadre, je voudrais également souligner un autre aspect : si vous utilisez NCache Vous utilisez votre environnement local et souhaitez maintenant migrer vers Azure. Le logiciel reste le même. Aucune modification n'est donc nécessaire. NCache de votre infrastructure sur site vers Azure. De même, chez les fournisseurs de cloud, si vous envisagez d'utiliser NCache Sur Azure, vous pouvez simplement migrer vers AWS, si besoin. En effet, le même logiciel est disponible sur toutes les plateformes. En revanche, Redis est concerné, Azure Redis Il s'agit d'un modèle hébergé déployé sous Linux pour le back-end, mais dont la version locale n'est pas identique. Il faut donc gérer l'open source. Redis ou un fournisseur tiers. Vous devrez même opter pour une version 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 dans Azure ou Redis Dans AWS, il s'agit d'Elastic Cache. Ce sont des produits complètement distincts. Il y a donc une transition, beaucoup de changements. Impossible de les porter. Redis D'un environnement à l'autre, sans modification. Certaines fonctionnalités sont manquantes. Certaines API sont différentes. Le modèle de déploiement est complètement différent d'un produit à l'autre. Il n'y a donc aucun changement si vous conservez NCache sur site sur Windows ou Linux et maintenant vous souhaitez migrer vers Azure, ce serait exactement le même produit et maintenant vous voulez le changer d'Azure vers AWS, vous voulez changer de fournisseur de cloud, c'est plus flexible par rapport à Redis. Alors, NCache est beaucoup plus flexible.
Prise en charge de Linux, NCache est entièrement compatible et officiellement pris en charge. Les performances sont également testées et Linux est ultra-rapide, comparable à NCache Sous Windows. Nous proposons des images Docker entièrement prises en charge en production et des outils de surveillance et de gestion entièrement intégrés. outils de gestion et de surveillance Web accessible depuis n'importe où. Ainsi, même vos déploiements Linux peuvent être gérés et surveillés comme vous le feriez avec vos déploiements Windows. NCache. Linux est également pris en charge sur Redis. Ainsi, son support de production est disponible par Redis Labo. Azure 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 plateforme, concerne à nouveau la pile technologique .NET et .NET Core. Nous disposons d'un client officiel, que nous avons implémenté et que nous prenons entièrement en charge. Voici pourquoi nous vous proposons différentes fonctionnalités. NCache est compatible avec tous les environnements. Ainsi, que vous choisissiez un environnement sur site, Azure ou AWS, vous bénéficierez des mêmes avantages. NCache et son client sont disponibles à tous les niveaux. Et si des modifications doivent être apportées, nous les communiquerons officiellement, car nous sommes responsables de tout, y compris du projet. En revanche, Redis Il s'agit d'un logiciel tiers. Ainsi, pour différentes langues, le support provient également de différents fournisseurs. Il peut donc y avoir des différences dans les fonctionnalités et les cycles de publication. Il faut donc s'appuyer sur des clients tiers pour la technologie et les besoins des clients.
Je voudrais donc souligner certains aspects autour NCache étant un produit natif .NET et .NET Core. NCache est entièrement pris en charge sous Windows, ainsi que sous Linux. Considérant que, Redis n'est pas très stable sous Windows. C'est une version tierce portée et le support Linux est disponible, donc vous devez vous fier au support Linux pour le moment. Redis Donc, venant du monde des technologies Microsoft, c'est un élément sur lequel il faut compter.
Performances et évolutivité du cache
Le deuxième aspect concerne les performances de notre cache. C'est également un aspect très important.
Les deux produits sont très rapides et c'est l'idée ici qui constitue le principal avantage de NCache et RedisLa principale raison de choisir un tel produit est l'amélioration des performances. Nous avons déjà constaté que les bases de données sont lentes et peu évolutives. Ces produits sont rapides et très évolutifs en comparaison. Je n'y vois donc aucun inconvénient. Redis. Seule la version Windows n'est pas stable et présente des problèmes de performances, mais si vous avez la version Linux, elle est également très rapide et évolutive et elle est extrêmement rapide et NCache Il est également très rapide et très évolutif. Nous disposons de notre propre protocole de clustering basé sur TCP/IP, très optimisé et très performant.
Cependant, il existe ici aussi quelques différences. NCache Nous proposons de nombreuses fonctionnalités d'amélioration des performances. Nous avons récemment organisé un webinaire où nous avons abordé six pistes d'amélioration. NCache performances. Si vous configurez NCache par défaut, il vous offrira de très bonnes performances, mais en plus, en fonction de vos cas d'utilisation, vous pouvez activer différentes fonctionnalités et améliorer encore les performances et l'une de ces fonctionnalités est notre cache client.
NCache: Cache client (cache proche)
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 possible même pour les applications sans serveur, où vous pouvez avoir une copie InProc au sein de votre processus applicatif, et/ou, pour les applications serveur, utiliser un cache client hors processus. L'idée est d'éviter de coûteux déplacements sur le réseau vers votre cluster de cache. Ce cache évitait déjà les déplacements vers les sources de données back-end. Imaginez maintenant un cache intermédiaire : si vous avez 100 éléments dans le cache, si vous alimentez certains éléments côté application, par exemple 10 éléments, ces 10 éléments seront automatiquement réintroduits dans le cache client. La prochaine fois, votre application trouvera ces données plus proches de vous, évitant ainsi de coûteux déplacements réseau.
Il s'agit d'un cache client synchronisé. La synchronisation est gérée par NCache. Tout changement dans la cache client Les modifications sont propagées sur le cache du serveur, car il s'agit de la copie principale. Il s'agit d'un sous-ensemble de données, et cette modification est également propagée aux autres caches clients. Dans le cas de données de référence, si vous avez beaucoup de lectures et d'écritures, nous vous recommandons vivement d'activer le cache client. Cela vous offrira de très bonnes performances par rapport à un cache exécuté sur notre base de données.
Nous avons récemment réalisé une démonstration de faisabilité avec l'un de nos plus gros clients. Leur workflow prenait environ 46 secondes avec les configurations par défaut. Ils réalisaient de nombreuses tâches. NCache Appels et récupération de données. Il s'agissait donc principalement d'un cas d'utilisation intensif en lecture. Nous avons activé le cache client hors processus. Il existe deux options : soit le laisser hors processus, ce qui signifie qu'un processus de cache distinct s'exécute sur l'application, soit utiliser InProc, où le cache client s'exécute au sein du processus applicatif. InProc ne nécessite ni sérialisation ni communication entre processus. Il est donc extrêmement rapide, même comparé à OutProc. Avec ce client, le workflow prenait environ 46 secondes au démarrage. Ensuite, nous avons activé le cache client hors processus, ce qui a ramené ce délai à 3 ou 4 secondes, puis nous avons activé le cache client InProc, et nous avons pu réaliser tout cela en 400 à 500 millisecondes. De 46 secondes à 400 millisecondes, c'est le type d'amélioration dont nous parlons, et cette fonctionnalité est totalement indisponible dans d'autres produits, ni même dans d'autres versions de Redis, dont des Redis Laboratoires, y compris les projets open source et Azure Redis.
Vous pouvez donc optimiser les performances grâce à notre cache client, sans modification de code. Il suffit d'activer une configuration.
Les opérations en masse sont prises en charge des deux côtés, mais avec NCache Nos opérations groupées fonctionnent sur l'ensemble du cluster de cache. Ainsi, si vous disposez de dix serveurs et de données entièrement distribuées, un appel groupé récupérerait les données de tous ces serveurs et récupérerait le résultat consolidé. Ainsi, tous ces éléments fonctionnent en synergie pour formuler un résultat complet. En revanche, Redis Les opérations en masse s'effectuent au niveau des fragments. Vous devez donc traiter les données sur un fragment donné. C'est là la limite. Si vous avez, par exemple, plusieurs nœuds dans le cluster de cache et des fragments maîtres disponibles, vous pourrez effectuer des opérations en masse sur un fragment donné.
Voilà donc la limite. Autrement, il s'agit d'une fonctionnalité intéressante pour améliorer les performances : au lieu d'effectuer des allers-retours pour des requêtes individuelles, vous envoyez une requête volumineuse et obtenez toutes les données en une seule fois, ce qui vous permet de prouver 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 se sérialiseraient et se désérialiseraient, mais avec NCache Il existe un moyen d'améliorer vos coûts de sérialisation et de désérialisation. Notre sérialisation rapide et complexe optimise le temps de sérialisation, normalement requis par votre application. Vos objets deviennent complexes. Ainsi, sans aucune modification de code, vous pouvez les définir comme des types compacts. NCache cela 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 disposons également d'une fonction de compression. La compression est effectuée côté client. Généralement, des objets volumineux, disons 2 Mo, 3 Mo ou 500 Ko, représentent un objet plus volumineux. Nous recommandons donc généralement de traiter des objets plus petits, mais avec des objets plus volumineux, l'utilisation du réseau est importante et les performances se dégradent. NCache Vous pouvez activer la compression. Cette option ne nécessite aucun changement de code et n'est pas disponible sur le Redis Les éléments sont automatiquement compressés lors de leur ajout au cache. Ainsi, les objets plus petits sont ajoutés et transférés entre l'application et le cache, et de la même manière, ces mêmes objets plus petits sont récupérés côté application. La gestion de charges utiles plus petites améliore les performances de vos applications. Ainsi, les performances globales de l'application sont améliorées si la compression est activée.
Nous recommandons donc que pour tout objet supérieur à, disons, 100 kilo-octets, vous activiez la compression et qu'il existe un seuil que vous pouvez activer et que seuls les objets plus gros soient compressés, les objets plus petits restent tels quels.
Donc, toutes ces fonctionnalités d'amélioration des performances, le cache client, les opérations en masse, la sérialisation compacte, la compression, ne sont pas disponibles ou RedisPar exemple, le cache client n'est pas disponible. Les opérations groupées sont disponibles, mais limitées. Il n'existe aucune option d'optimisation de la sérialisation et la compression n'est pas disponible. C'est là que se situe la différence nette entre NCache et Redis, Où NCache il s'agit d'un package complet dans lequel nous avons intégré de nombreuses fonctionnalités axées sur les performances.
Haute Disponibilité
Le segment suivant est celui de la haute disponibilité et c'est là que vous verrez une énorme différence de fonctionnalités entre NCache et RedisLa haute disponibilité est un autre aspect de comparaison entre ces éléments. Pour les applications critiques, il est essentiel de disposer d'une source. Vous transférez vos données, qui se trouvent normalement dans la base de données, et cette dernière dispose d'une mise en miroir et de sauvegardes, n'est-ce pas ?
Ainsi, le transfert de données vers un produit utilisant un cache distribué améliore les performances et offre une grande évolutivité, mais la haute disponibilité est un aspect crucial. Pour les applications critiques, toute interruption de service est inacceptable. Elle impacterait votre activité et l'expérience utilisateur. Ce n'est donc pas abordable. Il est donc crucial que votre application puisse toujours recevoir une réponse du cache où se trouvent les données. Il existe donc de nombreuses différences de fonctionnalités.
Cluster de cache
NCache est un cluster de cache à architecture 100% peer-to-peer.
C'est dynamique et auto-réparateur et je vais parler de la façon dont cela fonctionne, mais en comparaison Redis utilise un système maître/esclave. Il s'agit donc d'une architecture pair à pair. NCache Vous permet d'ajouter et de supprimer automatiquement des serveurs, en toute transparence pour vos applications. Vous pouvez ajouter autant de serveurs que nécessaire. Par exemple, vous avez démarré avec deux serveurs. Si vous souhaitez maintenant ajouter un troisième serveur, vous pouvez le faire instantanément. Vous n'avez pas besoin d'arrêter le cache ni les applications clientes qui y sont connectées. L'expérience est fluide. Vos applications peuvent ainsi continuer à fonctionner sans interruption ni perte de données grâce à nos fonctionnalités de haute disponibilité et de fiabilité des données. Redis Vous ne pouvez pas ajouter automatiquement de nouveaux fragments, car il n'y a pas de rééquilibrage automatique des données. C'est là le cœur de la nature dynamique de notre cluster de cache. NCache, il rééquilibre automatiquement les données si vous souhaitez ajouter de nouveaux serveurs.
Il existe donc deux scénarios : l'un consiste à ajouter un nouveau serveur pour augmenter la capacité et l'évolutivité, et l'autre à mettre un serveur hors service.
Commençons par le scénario d'ajout d'un nœud. Un nouveau nœud est ajouté. NCache, vos données seraient automatiquement distribuées.
Par exemple, si vous ajoutez deux serveurs supplémentaires (2 éléments), vous passerez de deux à trois serveurs. Si vous ajoutez un autre serveur, les données existantes seront transmises et rééquilibrées vers le nouveau serveur. Ce serveur récupérera alors une partie des données des serveurs existants, et ce, automatiquement. C'est un processus dynamique. Un rééquilibrage automatique des données est donc en place. Redis, c'est un rééquilibrage manuel des données et cela est vrai pour Azure Redis Azure propose différents niveaux de services : un niveau de base, un niveau intermédiaire et un niveau avancé. Le clustering n'est disponible qu'avec le niveau avancé, qui est également coûteux. De plus, il nécessite au moins trois serveurs, ce qui constitue une autre limitation.
Avec NCache Vous pouvez même mettre en place un clustering complet avec seulement deux serveurs, et en plus, l'ajout d'un nouveau serveur nécessite un rééquilibrage manuel des données. C'est un problème majeur. Vous seriez donc limité(e) par l'application et par la planification de l'augmentation de capacité. En revanche, avec NCache Vous pouvez réaliser cela à l'exécution. Vous pouvez ajouter des serveurs à la volée.
Le deuxième aspect est la panne d'un serveur. Donc, nous avons, dans Redis Nous avons un concept maître-esclave. Un maître réplique les données vers un esclave. Il existe un fragment esclave. Le maître doit donc répliquer les données, de manière synchronisée ou asynchrone. RedisSi un fragment esclave tombe en panne, le maître s'arrête et le cluster devient inutilisable. C'est donc un problème majeur, qui peut survenir fréquemment. Il est strictement réservé aux déploiements sur site avec une architecture open source ou Redis Déploiement en laboratoire de RedisDans ce cas, si un serveur tombe en panne et qu'il s'agit de l'esclave d'un fragment maître, le cluster lui-même devient inutilisable. Il faut donc intervenir manuellement pour se remettre de ce scénario. Alors qu'à l'intérieur NCache C'est automatique. Ainsi, n'importe quel serveur peut tomber en panne, même le nœud survivant peut être actif ou de secours.
Par exemple, si ce serveur tombe en panne, il s'agit d'une partition active, qui possède également une partition de sauvegarde. Si ce serveur tombe en panne, la sauvegarde active est promue. La partition de sauvegarde devient active et vous récupérez toutes les données du nœud survivant, avec un basculement de connexion intégré. En cas de panne du serveur, les clients le détecteraient à l'exécution et décideraient de basculer vers les nœuds survivants. J'aimerais ici insister sur ce point. Redis Il faut au moins trois serveurs. C'est le principe de la règle de la majorité. Le coordinateur de cluster doit remporter une élection. Ce n'est pas le cas avec NCacheVous pouvez démarrer un cluster de cache pleinement opérationnel avec seulement deux nœuds et bénéficier de toutes les fonctionnalités de haute disponibilité. En cas de panne d'un serveur, un nœud survivant peut fonctionner sans problème, ce qui n'est pas le cas avec Redis.
Configurations dynamiques. Vous pouvez modifier les configurations du cluster lors de l'exécution, ce qui implique l'ajout ou la suppression de nouveaux serveurs, ou la modification de certains paramètres du cluster de cache. Cette fonctionnalité peut être appliquée à l'ensemble d'un cluster de crash lors de l'exécution, sans l'interrompre. Redis, c'est limité. Il y a beaucoup de configuration à appliquer manuellement, et de nombreux événements d'intégrité du cluster sont disponibles sur NCache côté, auquel vous pouvez vous abonner. Vous pouvez utiliser des outils de surveillance et de gestion en complément. Tandis que, Redis n'a pas ces caractéristiques.
Il s'agit d'un concept très important. Laissez-moi vous le résumer. Ajouter et supprimer un serveur dans Redis Cela pourrait poser de nombreux problèmes. L'ajout de données ne serait pas automatiquement rééquilibré. Il ne s'agit donc pas d'une architecture pair-à-pair à 100 %. La capacité du cluster de cache est donc limitée. De même, si un fragment esclave tombe en panne, le cluster lui-même devient inutilisable. Cela pose un problème de distribution qu'il faut désormais gérer manuellement. Le basculement est également manuel, n'est-ce pas ? Ainsi, si un serveur tombe en panne, vous devez effectuer un basculement manuel et utiliser les nœuds survivants. Si vous ajoutez de nouveaux serveurs, le basculement vers les nouveaux serveurs devra être effectué manuellement.
Voilà donc toutes les limitations auxquelles vous pourriez être confronté. Je serais surpris de voir un déploiement de production de cette nature nécessiter d'augmenter la capacité ou de mettre les serveurs hors service pour maintenance. Ce serait donc très difficile avec un produit comme celui-ci. Redis. Tandis que, NCache Vous offre une expérience fluide. Vous pouvez ajouter ou supprimer des serveurs à la volée, sans impact sur quoi que ce soit.
Partitions/fragments dynamiques
Maintenant, un autre concept au sein du cluster est le mécanisme d’auto-guérison.
NCache Il possède des partitions dynamiques. L'ajout de serveurs permet la redistribution des données et la création de nouvelles partitions à l'exécution. De même, lors de la mise hors service d'un serveur, le cluster rend la sauvegarde disponible et se régénère automatiquement pour créer un cluster de cache à deux nœuds en bon état si vous le ramenez de trois à deux nœuds, ce qui améliore la fiabilité. Il dispose de partitions de réplication, disponibles également sur Redis sous forme d'esclaves, mais leur haute disponibilité dépend de la réplication. Ils n'ont pas Redis Vous ne bénéficierez pas d'une haute disponibilité sans partitions esclaves configurées. Il est donc nécessaire d'avoir des partitions esclaves disponibles. En revanche, avec NCache, nous avons des topologies.
Par exemple, le cache partitionné, où nous avons des partitions et des fragments maîtres, assure une haute disponibilité. Si ce serveur tombe en panne, les clients le détecteront et basculeront vers le nœud de survie. Ils subiront une perte de données, et c'est le cas pour Redis Également. Perte de données due à l'absence de réplication, mais haute disponibilité. Nous avons également amélioré ce système grâce à la prise en charge de la réplication. En cas de panne du serveur, non seulement la sauvegarde du serveur est disponible, mais les clients basculent automatiquement. Donc, Redis est limitée. Sa haute disponibilité dépend de la réplication. Sa haute disponibilité n'est pas garantie si la réplication n'est pas activée, ce qui constitue également un facteur limitant.
Et puis le mécanisme d’auto-guérison, bien qu’aucune intervention manuelle ne soit nécessaire.
Si vous démarrez avec trois serveurs, si vous en arrêtez un, vous utiliserez la partition active, un maître, puis vous perdrez également un esclave d'un autre serveur. Dans ce cas, la sauvegarde du serveur 3 se trouvait sur le serveur 3 ; celui-ci est alors activé. Il se connecte aux partitions actives lors de l'exécution. Aucune intervention n'est nécessaire. Une intervention manuelle est nécessaire, puis le serveur de partition 1 créera une partition saine sur le serveur 2. Le cluster se réparera alors automatiquement, ce qui explique la nature dynamique du cluster. NCache en comparaison à Redis. Où pour RedisLes partitions ne peuvent pas être réajustées à l'exécution. Le cluster s'arrête si la partition esclave tombe en panne. La redistribution des données 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 obtenez NCache, en fait un produit bien supérieur car ces fonctionnalités sont totalement absentes ou limitées Redis et cela est vrai pour Azure Redis. Ceci est également vrai pour l'open source car ce sont des produits très comparables et cela est également vrai pour Redis Laboratoires Redis offrande également.
NCache Demo
Je vais maintenant passer un peu de temps à vous montrer le produit réel en action afin que vous ayez un aperçu de la façon dont il fonctionne. NCache est configuré. Voici notre environnement de démonstration. Je l'utilise. Je vais donc créer un nouveau cache. Voici notre outil de gestion web, fourni avec NCacheLe mode de sérialisation peut être binaire ou JSON. C'est à vous de choisir. Je vais simplement nommer le cache et vous montrer comment créer un cluster de cache, connecter une application cliente, le surveiller et le gérer.
Alors, je vais garder les choses simples car l'objectif principal de ce webinaire est NCache vs. RedisJe vais donc simplifier les détails. Réplique partitionnée : c'est notre topologie la plus recommandée. Réplication asynchrone entre la machine active et la machine de secours. Vous pouvez donc choisir la synchronisation. L'asynchrone est plus rapide, donc je vais l'utiliser. Taille du cluster de cache. Ensuite, je vais spécifier les nœuds de serveur où NCache est déjà installé. Port TCP. NCache Il s'agit d'un protocole de communication basé sur TCP/IP. Je vais donc simplifier les choses : j'active simplement l'éviction pour que le cache soit plein. Certains éléments sont alors automatiquement supprimés du cache, libérant ainsi de la place pour les nouveaux. Démarrez ce cache et terminez. Démarrez automatiquement au démarrage du service : à chaque redémarrage du serveur, il rejoint automatiquement le cluster de cache, et c'est tout. Configurer un cluster de cache est aussi simple que ça, comme je vais vous le montrer.
Support Cloud (Azure et AWS)
Notre modèle de services gérés arrive bientôt. Notre prochaine version sera axée sur ce point, et je pense qu'elle sera disponible dans deux à trois semaines. Nous disposerons donc d'une solution entièrement gérée. NCache modèle de logiciel en tant que service dans Azure ainsi que dans AWS.
Pour l'instant, le modèle VM est le même. Si vous êtes sur site, vous pouvez utiliser des machines virtuelles physiques ou des machines virtuelles. Si vous choisissez Azure, vous devrez configurer votre machine virtuelle via la marketplace ou simplement la configurer et l'installer. NCache Logiciels téléchargeables depuis notre site web. Nous proposons également un environnement conteneurisé. Nous utilisons des images Docker et sommes entièrement compatibles avec Azure Kubernetes Service, EKS (Elastic Kubernetes Service) et toute autre plateforme Kubernetes, par exemple OpenShift. NCache La solution est déjà entièrement intégrée et prise en charge sur ces plateformes. Quant à la gestion, elle est prévue prochainement. Elle sera donc entièrement disponible d'ici deux à trois semaines.
Alors, je vais vous montrer la fenêtre de statistiques, qui est un compteur de performances et d'ailleurs ces options de surveillance sont disponibles pour NCache, en terme de NCache sur Windows comme sur Linux, n'est-ce pas ?
Je vais donc exécuter un outil de test de stress. Je crois qu'il en existe déjà un pour un autre cache. J'en lance donc un autre, qui simulera une charge fictive sur notre cluster de cache. Il suffit de spécifier le nom, et l'outil détecte automatiquement les serveurs grâce aux fichiers de configuration et s'y connecte.
Nous disposons donc de l'état du cluster entièrement connecté, des requêtes par seconde indiquant le débit, de la latence moyenne en microsecondes par opération de cache, des ajouts, des récupérations, des mises à jour, des suppressions, de la taille du cache, du processeur et de la mémoire. Vous disposez ainsi d'une vue de surveillance centralisée. Vous pouvez utiliser cet outil. Vous pouvez également utiliser Windows Perfmon.
Pour les serveurs Linux, nous proposons une surveillance personnalisée. Vous pouvez donc utiliser notre outil de surveillance directement pour les serveurs Linux, ainsi que tout outil tiers. NCache Voilà donc un aperçu rapide de notre processus de création de cache. Quelques aspects de surveillance et de gestion.
Bon, revenons-en à nos moutons. Puisque nous avons abordé quelques détails, j'aimerais maintenant aborder l'offre et le support cloud. Redis Vous pouvez choisir un cache non géré ou géré, ainsi qu'un service hébergé proposé par des fournisseurs tiers. L'option hébergée est proposée par Azure. Redis, où vous pouvez avoir une variante open source de Redis personnalisé par Microsoft et disponible en modèle hébergé. Tandis que, sur le NCache Nous avons également un modèle de serveur de cache et un modèle de machine virtuelle. J'ai déjà évoqué l'approche par conteneurs. Elle est entièrement compatible avec les conteneurs Windows et Linux. Nous proposons des démonstrations vidéo pour Azure Service Fabric pour conteneurs Windows, ainsi que des détails sur l'architecture des microservices. Nous utilisons Azure Kubernetes Service, qui utilise des conteneurs Linux. EKS (Elastic Kubernetes Service), et je crois que nous avons également développé des conteneurs Red Hat OpenShift via Kubernetes.
Voilà donc toutes les options de déploiement de conteneurs disponibles. C'est flexible, et sa plateforme n'est pas spécifique à une plateforme. Vous pouvez donc le déployer sur n'importe quelle plateforme conteneurisée sans problème. Le service géré arrive bientôt, nous en avons déjà parlé. C'est donc un domaine où NCache j'aurais réussi le service mais c'est dans notre prochaine version.
Un aspect important réside dans l'avantage d'utiliser un modèle de machine virtuelle : même si vous devez vous connecter à une machine virtuelle plutôt qu'à un service, vous contrôlez tout. Vous pouvez exécuter du code côté serveur, ce que je détaillerai plus loin, mais l'aspect le plus important est la performance. Nous avons déjà évoqué les nombreuses fonctionnalités de performance intégrées. NCache, qui manquent dans Redis. Si vous choisissez d'avoir Azure RedisVous devrez vous connecter à l'infrastructure Azure. Il s'agit de machines virtuelles exécutées sur un réseau virtuel distinct. Elles sont situées à proximité, mais aussi éloignées. C'est différent de votre propre réseau virtuel Microsoft Azure, sur lequel sont déployés 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 d'application. Par exemple, votre service d'application, votre site web Azure et vos microservices Azure 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 ainsi améliorer les performances de vos applications. D'après nos propres tests en laboratoire, NCache était quatre à cinq fois plus rapide que le modèle SaaS de Redis que l'on trouve habituellement dans Microsoft Azure. C'est donc un aspect très important que je voudrais souligner.
De plus, vous bénéficiez d'un contrôle total sur votre VM. Vous avez un contrôle total sur le démarrage et l'augmentation du cache, et vous exploitez pleinement sa capacité. Il n'y a aucune limite d'unités de requête, aucune limite de taille, aucune empreinte d'utilisation et aucun coût n'est facturé. Vous possédez votre propre licence, qu'elle soit perpétuelle ou par abonnement, avec une grande flexibilité en termes de licences. De plus, vous pouvez exécuter du code côté serveur sur votre machine virtuelle. NCache Serveurs. Vous pouvez gérer et optimiser entièrement ces fonctionnalités. Vous pouvez écrire de nombreuses interfaces, telles que la lecture directe, l'écriture directe, l'écriture différée, le chargeur de cache et certaines fonctionnalités de grille de calcul comme MapReduce, l'agrégateur et les processeurs d'entrée. Ceci 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 RedisVoilà donc notre plateforme.
Garder le cache à jour
Prochain segment, les 15 prochaines minutes seront consacrées à la comparaison des fonctionnalités. Pour cela, j'ai défini quelques segments. Je vais commencer si vous avez besoin de maintenir le cache à jour, ce qui est très important. Un webinaire dédié devrait être consacré à ce sujet : comment maintenir le cache à jour, notamment pour les sources de données back-end et les cas d'utilisation de vos applications.
Donc, en comparaison avec Redis, Vous savez, NCache a également de nombreuses fonctionnalités de ce côté.
Nous avons une base de temps d'expiration, qui est absolue et glissante, mais nous avons également un mécanisme de rechargement automatique disponible pour cela. Redis Il n'y a qu'une expiration absolue et glissante, sans 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. Là encore, cela est possible car NCache vous permet de donner, d'avoir un accès complet à vos machines virtuelles où NCache est hébergé. Vous pouvez donc déployer du code côté serveur sur NCache et utilise NCache puissance de calcul pour le soutenir.
Vous pouvez synchroniser votre cache avec la base de données. NCache La synchronisation des bases de données est très performante. Nous avons une dépendance SQL, une dépendance DB, compatible uniquement avec la base de données, et des procédures stockées .NET CLR. Toutes ces fonctionnalités permettent de synchroniser le cache avec la base de données. L'idée est que si un changement survient dans la base de données, qu'un enregistrement est mis en cache et que cet enregistrement est mis en cache, ces deux sources peuvent être désynchronisées. NCache, s'il y a un changement dans la base de données, vous pouvez automatiquement invalider ou recharger ces données dans NCache à l'exécution. Il s'agit d'une fonctionnalité unique à NCacheAucun autre produit ne propose cette fonctionnalité. Vous pouvez ainsi synchroniser entièrement votre cache avec votre base de données principale, et ce, non seulement pour les bases de données relationnelles, mais aussi pour les sources de données non relationnelles.
La dépendance de fichiers est une autre fonctionnalité permettant de rendre des éléments dépendants d'un fichier. Si le contenu d'un fichier est modifié, les éléments sont automatiquement supprimés ou rechargés. La dépendance personnalisée, quant à elle, peut être utilisée avec n'importe quelle source : base de données NoSQL, système de fichiers, base de données relationnelle, connecteur ou service web. Vous pouvez ainsi valider les éléments selon vos besoins spécifiques. Nous avons implémenté cette dépendance avec Cosmos DB, et notamment la synchronisation. NCache avec Cosmos DB. Si vous utilisez NCache en plus de cosmos DB, vous pouvez utiliser une dépendance personnalisée et je pense que j'ai également fait un webinaire à ce sujet.
Gestion des données relationnelles. Ces données ont des relations. Les éléments du cache sont des paires clé-valeur, ce qui permet d'établir des relations entre différents éléments, ce qui n'est pas disponible sur Redis côté. Il faudrait donc traiter les éléments individuellement. 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, tandis que 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 et Redis ne possède aucune fonctionnalité. Et encore une fois, c'est vrai pour Azure. Redis qui est de toute façon très limité. L'open source Redis est légèrement en avance, mais ses fonctionnalités restent limitées. Même le Redis Lab, la version commerciale de Redis, qui n'est pas équipé de ces fonctionnalités.
La recherche SQL est disponible. Vous pouvez rechercher des éléments dans NCache En fonction de leurs attributs. Les objets sont ajoutés au cache. Vous pouvez définir des index pour leurs attributs. Par exemple, les produits peuvent être indexés pour leur identifiant, leur prix et leur catégorie. Vous pouvez désormais effectuer une recherche sur ces produits en utilisant ces attributs. Par exemple, sélectionnez un produit dont la catégorie de point est « quelque chose » ou dont le prix de point est supérieur à 10 et inférieur à 100. NCache La recherche en mémoire s'effectuerait sur tous les éléments et sur tous les serveurs, consoliderait les résultats et vous fournirait l'ensemble de résultats. Ainsi, vous n'avez plus besoin de gérer de clés. Vous récupérez les données selon des critères.
Les recherches LINQ sont également disponibles. Nous proposons des applications .NET et .NET Core. Si vous utilisez la recherche LINQ, vous pouvez l'exécuter sur… NCache C'est donc une fonctionnalité unique NCache où Redis n'a aucun support. Redis toutes les saveurs de Redis, n'ont pas ce support.
Vous pouvez créer des groupes et des sous-groupes. Vous pouvez créer des collections logiques à 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.
Les tags et les tags nommés peuvent être attribués. Par exemple, vous pouvez utiliser des mots-clés pour vos articles. Par exemple, vous pouvez étiqueter tous les clients avec un tag client. Toutes les commandes avec un tag de commande et les commandes d'un client spécifique peuvent également être associées à un identifiant client. Pour obtenir des commandes, il vous suffit de saisir les commandes par tag et de les indiquer comme identifiant, afin d'obtenir toutes les commandes. Pour obtenir les commandes d'un client spécifique, il vous suffit de saisir n'importe quel tag ou de saisir l'identifiant client et d'obtenir toutes les commandes, mais uniquement pour ce client. Voilà la flexibilité offerte par les tags et les tags nommés. NCache. Redis ne les prend pas en charge.
Code .NET côté serveur
Nous avons déjà expliqué que nous utilisons généralement le modèle « cache-aside ». Vous vérifiez d'abord les données dans le cache. Si elles y sont trouvées, vous les retournez. Si vous ne trouvez pas de données dans le cache, vous accédez à la base de données backend de votre application, puis vous les récupérez et les mettez en cache. Ainsi, en cas de valeur nulle, vous récupérez cette valeur, puis vous accédez à la base de données. Vous pouvez automatiser cela grâce au gestionnaire Read-Thru. Il s'agit d'un code côté serveur exécuté sur votre application. NCache Serveurs. Notre service géré disposerait également de cette fonctionnalité. Vous implémentez donc 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 non relationnelle. Plusieurs méthodes sont appelées dès qu'une valeur nulle est trouvée dans le cache.
Vous appelez donc la méthode Cache.Get et activez l'indicateur Read-Thru. Si l'élément n'est pas dans le cache, l'appel est transmis à votre gestionnaire Read-Thru, ce qui vous permet de récupérer les données de la base de données principale en passant par ce code de gestionnaire. Quel est votre code utilisateur exécuté sur ? NCache côté serveur. Vous pouvez ainsi parcourir en toute transparence NCache et obtenez les données dont vous avez besoin.
L'écriture directe est l'opposé de celle-ci, qui est également prise en charge et Redis Ne disposant pas de ces fonctionnalités, vous pouvez mettre à jour un élément du cache. Si vous souhaitez mettre à jour la base de données, vous pouvez la mettre à jour en appelant votre gestionnaire d'écriture directe. Implémentez et enregistrez ce gestionnaire d'écriture directe, puis NCache L'appel à cette fonction permet de mettre à jour la base de données principale, et l'écriture différée est son contraire. Pour toute mise à jour du cache, l'application cliente renvoie NCache mettrait à jour la base de données principale de manière asynchrone, en arrière-plan. Donc, 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. Il s'agit de bibliothèques de classes .NET et .NET Core natives que vous pouvez implémenter et enregistrer en tant qu'interfaces de lecture et d'écriture directes, ce qui est possible avec NCache.
Le chargeur de cache est une autre fonctionnalité. Vous pouvez pré-remplir le cache en implémentant une interface et en vous enregistrant auprès de 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 simultanément sur tous les serveurs. C'est donc ultra-rapide. Vous pouvez pré-remplir toutes vos données et n'aurez plus jamais besoin de consulter la base de données. Vous retrouverez toujours ces données, car vous les avez pré-chargées.
Dépendance personnalisée, processeur d'entrée, ce sont encore des fonctionnalités qui sont uniques à NCache et la raison principale pour laquelle ces fonctionnalités ne sont pas utilisables. Tout d'abord, Redis ne possède pas 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'était la principale raison à laquelle je faisais référence plus tôt. NCache Actuellement, avec un modèle de machine virtuelle, vous avez un accès complet à l'endroit où vous la déployez, à son contrôle et à sa gestion. Vous avez donc un contrôle total. Ce n'est pas une boîte noire. Redis est.
Réplication WAN pour plusieurs centres de données
Encore quelques détails et je conclurai. La réplication WAN est un autre aspect.
Le mode actif-passif est pris en charge sur Redis, où vous pouvez transférer l'intégralité du cache d'un centre de données à un autre. NCacheNous avons une architecture active-passive. Il s'agit d'une transition unidirectionnelle des données d'un centre de données à l'autre. Nous avons également une architecture active-active, un cas d'utilisation très urgent et crucial où les deux sites peuvent être actifs. Les mises à jour du site 1 doivent être transmises au site 2, et inversement. Cette fonctionnalité n'est donc pas disponible. Redis côté. Vous n'avez pas cette possibilité, donc vous ne pouvez pas exécuter de sites actifs-actifs avec Redis. Avec NCache Ceci est valable pour la mise en cache des données de votre application, où les données sont mises à jour sur les deux sites, et cela est également possible grâce à nos sessions multisites. C'est donc un autre domaine où NCache est un gagnant clair.
Topologies de cache
Voici quelques détails supplémentaires : les topologies de mise en cache. Nous disposons d'une longue liste de topologies de mise en cache, comparées à Redis.
Donc, en fonction des différents cas d'utilisation, nous avons mis en miroir, répliqué, partitionné, puis répliqué la partition, puis nous avons déjà débattu, nous avons discuté de la manière dont NCache Le clustering est meilleur en général et nous avons beaucoup plus d'options par rapport à Redis Offres.
Outils d'interface graphique - Administration et surveillance du cache
Ensuite, nous avons les outils d'interface utilisateur graphique. Voici une comparaison : gestionnaire, moniteur.
Nous disposons d'outils PowerShell, de vidage et de rechargement, ainsi que d'une administration et d'une surveillance complètes. Redis est également limité sur ce front et dans ce cadre, 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 proposons des sessions multisites et le partage de sessions ASP.NET vers ASP.NET Core est en cours de déploiement. Les sessions multisites ASP.NET et ASP.NET Core sont disponibles. Affichage de l’état et mise en cache de la sortie. Redis n'a que des sessions, ce qui est très basique par rapport à NCacheLe verrouillage de session et le partage de session font partie de NCacheLa mise en cache des sorties est prise en charge côté serveur et côté client. De plus, nous proposons SignalR Backplane et la mise en cache des réponses ASP.NET Core. L'ensemble de ces fonctionnalités répond ainsi parfaitement à vos besoins spécifiques en matière de mise en cache web. Vous pouvez consulter la liste détaillée 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 objets et nous avons également un système de notification d'événements basé sur des critères, ce qui est bien supérieur par rapport à RedisJ'ai un webinaire dédié à notre messagerie Pub/Sub. Je vous recommande donc vivement de le consulter si vous avez des questions. Je pense donc conclure ici.
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 remplacez ces produits, vous pouvez facilement passer à NCache en comparaison à Redis.
Sécurité et Cryptage
Quelques détails sur cryptage de sécurité et je pense que nous sommes déjà sur la bonne voie.
Conclusion
C'est donc le moment idéal pour conclure. Tout d'abord, vous pouvez à tout moment vous rendre sur www.alachisoft.com et télécharger une version entreprise de NCache Nous vous montrerons personnellement comment cela fonctionne dans votre environnement. Nous vous encourageons donc à consulter directement notre site web et à bénéficier de 30 jours d'essai gratuit d'Enterprise. Nous serons ravis de planifier une démonstration. De plus, nous mettrons à votre disposition un enregistrement de ce webinaire. Consultez régulièrement nos e-mails et nos réseaux sociaux pour le recevoir. Si nous n'avons pas répondu à vos questions aujourd'hui, et je sais que nous en avons beaucoup d'autres à venir, n'hésitez pas à nous contacter par e-mail. support@alachisoft.com.
Si vous avez des questions techniques, nous aurons une réponse pour vous et si vous êtes intéressé à avancer et à postuler NCache dans votre environnement, vous seul pouvez contacter sales@alachisoft.com également.