Conférence au Live 360 Orlando 2016
Mise à l'échelle des applications .NET avec la mise en cache distribuée
Par Iqbal Khan
Président et évangéliste de la technologie
Vos applications .NET peuvent rencontrer des goulots d'étranglement de base de données ou de stockage en raison de la croissance de la charge des transactions. Découvrez comment supprimer les goulots d'étranglement et faire évoluer vos applications .NET à l'aide de la mise en cache distribuée. Cette conversation porte sur :
- Aperçu rapide des goulots d'étranglement d'évolutivité dans les applications .NET
- Description de la mise en cache distribuée et comment elle résout les problèmes de performances
- Où pouvez-vous utiliser la mise en cache distribuée dans vos applications
- Quelques fonctionnalités importantes dans un cache distribué
- Exemples pratiques utilisant un cache distribué
Qu'est-ce que l'évolutivité
Alors, commençons par quelques définitions. Je suis sûr que la plupart d'entre vous le savent déjà, mais nous allons simplement le parcourir à des fins d'exhaustivité. La première définition est l'évolutivité. Alors, qu'est-ce que l'évolutivité ? Les gens confondent souvent évolutivité et performances. Les performances sont un temps de réponse très rapide par application, mais cela pourrait être avec cinq utilisateurs seulement et si vous passez de cinq utilisateurs à cinq mille ou 50,000 XNUMX utilisateurs et que les performances restent bonnes, votre application est évolutive. C'est le résumé de ce que nous essayons de réaliser.
Quelle que soit l'application dont vous disposez, si vous pouvez obtenir les mêmes performances qu'avec cinq utilisateurs ou une charge de transaction très faible, si vous pouvez obtenir les mêmes performances avec une charge de transaction élevée, vous êtes évolutif. Si vous n'avez pas de bonnes performances avec cinq utilisateurs, vous avez d'autres problèmes.
Évolutivité linéaire
L'évolutivité linéaire est plus une définition d'infrastructure, c'est-à-dire que si votre application est conçue de manière à ajouter plus de serveurs au déploiement, qu'il s'agisse d'ajouter plus de serveurs d'applications ou de serveurs de bases de données ou quoi que ce soit, si cela peut augmenter la capacité de transaction de manière linéaire mode, vous disposez alors d'une architecture d'application linéairement évolutive.
Cependant, si vous n'êtes pas en mesure de le faire, si l'ajout de plus de serveurs n'ajoute aucune valeur, il y a quelque chose de fondamentalement faux et vous n'êtes pas en mesure de faire évoluer l'application de manière linéaire. Le but ici est, bien sûr, de pouvoir évoluer de manière linéaire.
Évolutivité non linéaire
Non linéaire serait là où, à mesure que vous ajoutez plus de serveurs, vous voyez augmenter mais à un certain moment après cela, il n'y a plus d'augmentation, en fait, il y a une baisse des performances même si vous ajoutez plus de serveurs car l'architecture de l'application et le déploiement il y a des goulots d'étranglement que vous n'êtes tout simplement pas en mesure de surmonter.
Quelles applications ont besoin d'évolutivité ?
Ce sont généralement des applications Web.
Donc, ce sont les gens ASP.NET pour .NET, les services Web, le back-end pour l'Internet des objets qui est un espace émergent très fort et le traitement de données volumineuses. Le traitement de données volumineuses est plus courant du côté Java. Peu de gens le font du côté .NET, mais le traitement des mégadonnées est également un autre domaine. Et, toute autre application serveur, cela pourrait être votre application de traitement par lots. Vous êtes peut-être une société de services financiers et vous avez des millions de clients et ils appellent et changent d'adresse ou peut-être transfèrent-ils des fonds d'un compte à l'autre et comme vous avez certaines exigences de conformité qu'au milieu de la nuit ou quelque chose que vous avez pour terminer ces traitements et il y a un traitement par lots qui se passe dans le backend, dans un flux de travail, d'une manière. Ainsi, toutes les autres applications serveur qui sont soumises à des contraintes de temps pour effectuer un certain nombre de transactions ont besoin d'évolutivité.
Problème d'évolutivité
Alors, où est le problème d'évolutivité ? Nous avons parlé d'évolutivité linéaire et non linéaire. Ainsi, le problème d'évolutivité est que le niveau d'application évolue de manière très linéaire. Si vous avez une application Web ou des services Web, votre niveau d'application, vous ajoutez simplement plus de serveurs, pas de problème. C'est le stockage des données qui est le goulot d'étranglement. Et, quand je dis le mot stockage de données, je veux dire les bases de données relationnelles et les données héritées du mainframe. je ne veux pas dire NoSQL database. NoSQL databasesont super. Nous avons aussi un NoSQL produit appelé NosDB mais aucune base de données SQL n'est pas toujours la réponse. Ils sont une réponse si vous pouvez déplacer plus de données que vous déplacez vers NoSQL database est le plus d'une solution d'évolutivité que vous obtenez. Mais le problème est que vous ne pouvez pas déplacer toutes les données vers NoSQL. De nombreuses données doivent rester relationnelles pour des raisons à la fois techniques et commerciales.
Ainsi, les bases de données relationnelles sont là pour rester. Ils ne vont nulle part en ce qui concerne ce problème. Donc, vous devez contourner cette réalité ou travailler avec cette réalité que vous allez travailler avec des bases de données relationnelles et vous devez toujours résoudre ce problème. Et la raison pour laquelle vous devez résoudre ce problème est que vous avez toutes ces applications que j'ai mentionnées qui ont besoin d'évolutivité.
Déploiement de cache distribué
Et, bien sûr, la réponse est d'avoir un cache distribué branché entre le niveau application et le niveau base de données.
Ainsi, un cache distribué est, essentiellement, un concept très puissant et pourtant très simple. Vous avez deux ou plusieurs serveurs à faible coût et ils sont regroupés et ce cluster regroupe la mémoire et les ressources CPU de tous les serveurs en une seule capacité logique. le goulot d'étranglement et l'évolutivité se déclinent en trois domaines. Le premier est la mémoire, le second le CPU, le troisième la carte réseau.
Donc, si vous avez, disons, un serveur de base de données ici et que vous avez 20 boîtes de niveau d'application qu'un serveur de base de données, vous pouvez prendre en charge en termes de puissance matérielle, vous pouvez ajouter plus de mémoire, beaucoup plus de processeurs, mais il y a une limite à cela. Donc, la réponse est, pour pouvoir avoir de plus en plus de serveurs qui ne sont pas très haut de gamme, en fait, ils ne devraient pas être haut de gamme par définition. Et, ce que nous avons vu au cours des 10 dernières années ou plus, c'est que la configuration la plus courante est un type quadricœur à double processeur d'un équivalent. Donc, disons, une boîte à 8 cœurs et une boîte à 16 cœurs est en fait une configuration assez haut de gamme pour un serveur de mise en cache. 8 cœurs est à peu près le commun.
La mémoire, bien sûr, vous avez besoin de beaucoup de mémoire parce que la mémoire est bon marché, donc ce n'est pas un facteur important. Vous avez besoin de beaucoup de mémoire, pourquoi parce que le cache est un magasin en mémoire donc il stocke tout en mémoire et, une configuration typique serait d'environ 16 à 32 Go de mémoire dans chaque serveur de cache et 2 serveurs de cache est le minimum que vous devriez avoir à des fins de redondance. Ainsi, en ayant cette architecture, vous vous trouvez maintenant dans une situation où vous ajoutez plus de serveurs au niveau application. Vous ajoutez plus de serveurs proportionnellement dans le niveau de mise en cache. Donc, généralement, c'est un rapport de 4 à 1 ou 5 à 1, c'est ce que nous avons vu comme le plus pratique. Dans certains cas, vous pouvez aller bien plus que 5 à 1. Cela signifie 5 serveurs d'applications pour 1 serveur de mise en cache, mais il n'y a pas de limite au nombre de serveurs que vous pouvez avoir. Vous pouvez en avoir 2, vous pouvez avoir 4, 10, 20, 30 serveurs mais pour que vous ayez 20 serveurs ici, vous avez probablement besoin d'une centaine de serveurs dans l'environnement de l'équilibreur de charge.
Donc, à un moment donné, cela devient à peu près le haut de gamme de toute application que nous avons vue sur le Web ou le commerce électronique sur le scénario commercial en ligne. Ainsi, en ajoutant plus de serveurs ici, ce n'est plus le goulot d'étranglement. Ainsi, la mise en cache distribuée devient en fait une pratique exemplaire. Si vous avez l'évolutivité comme besoin. Parce que maintenant, non seulement vous avez une base de données qui est là pour son propre usage, vous avez besoin d'une persistance permanente du magasin de données pour toutes les données d'application, mais vous avez également cette infrastructure vraiment très rapide et évolutive qui fait maintenant partie de votre architecture d'application. Ainsi, lorsque vous programmez, vous ne programmez plus seulement pour la base de données. Vous pensez toujours à un cache, car le cache s'assurera désormais que votre application ne ralentit jamais, même en cas de pics de charge. Même si la base de données n'a pas été conçue pour évoluer de la même manière. Donc, c'est une image typique.
Environ 80% du trafic sera piégé ou sera 80% du temps où vous irez au cache, 20% du temps vous irez à la base de données et que ces 20% sont principalement des mises à jour et bien sûr, quelques lectures parce que vous besoin d'obtenir des données dans le cache, mais vous pouvez également pré-remplir le cache et il existe de nombreuses autres façons de le faire. Mais, en réduisant le trafic de façon si spectaculaire au niveau de la base de données, c'est ainsi que vous obtenez performances et évolutivité.
C'est donc un peu le cas pour l'utilisation d'un cache distribué. Pourquoi vous devez conserver cela dans le cadre de votre architecture d'application.
Cas d’utilisation courants
Donc, maintenant que nous avons en quelque sorte plaidé en faveur de l'utilisation d'un cache distribué, la question suivante est de savoir comment l'utilisez-vous ? Où l'utilisez-vous? quel type d'utilisation devriez-vous avoir d'un cache distribué ?
Mise en cache des données d'application
Eh bien, l'utilisation la plus courante est la mise en cache des données d'application. C'est là que, comme je viens de le dire, quelles que soient les données que vous avez dans la base de données, vous les mettez en cache. Pour que vous n'ayez pas à aller dans la base de données. La chose à garder à l'esprit, et j'aborderai ce point plus en détail dans les diapositives suivantes, est que dans un cas d'utilisation de mise en cache des données d'application, les données existent à deux endroits. L'un est dans la base de données où il doit toujours être et le second est le cache. Ainsi, chaque fois que des données existent à deux endroits, quel est le premier problème qui vous vient à l'esprit ? Synchronisation ! Ouais.
Ainsi, tout cache qui ne peut pas gérer cette situation vous oblige à mettre en cache des données en lecture seule, des données dont vous savez qu'elles ne changeront jamais. En fait, la plupart des gens quand vous parlez de cache, la pensée instinctive qui leur vient à l'esprit est pourquoi c'est pour les données en lecture seule ? Je ne veux vraiment pas mettre en cache mes clients et mes comptes et les données qui changent toutes les 30 secondes. Mais, la recherche montre que la plus grande utilisation d'un cache est dans les données transactionnelles et une fois que vous l'avez mis en cache, vous en aurez probablement besoin dans la minute ou les deux prochaines minutes, quelle que soit cette activité, quelle que soit la fenêtre mobile de votre utilisation. C'est alors que vous avez à nouveau besoin des mêmes données et si vous pouvez les obtenir à partir du cache, vous réduisez ces déplacements vers la base de données et multipliez cela par des millions de transactions qui se produisent dans votre application et cela devient un coup de pouce assez important. Donc, gardez ce problème à l'esprit au fur et à mesure que nous avançons que tout bon cache doit gérer cela très très efficacement.
Mise en cache spécifique à ASP.NET
Le deuxième cas d'utilisation est que si vous avez une application ASP.NET, il y a beaucoup de données transitoires. Transient signifie temporaire et que vous pouvez mettre dans le cache et que ces données n'appartiennent pas vraiment à la base de données. Par exemple, une base de données est là pour une permanence. C'est un magasin permanent. C'est votre dossier principal. Ainsi, un état de la session, vous n'avez probablement besoin de le conserver que tant que l'utilisateur est connecté, peut-être 20 minutes après, vous savez. Alors, pourquoi le garder dans la base de données ? La base de données n'est pas aussi rapide. Les bases de données relationnelles n'ont pas été conçues pour stocker des blobs et les sessions sont généralement stockées sous forme de blobs. Ainsi, il y a un gros impact sur les performances lorsque vous stockez des sessions dans la base de données. Ainsi, l'état de session est un très bon cas d'utilisation pour ASP.NET pour le placer dans le cache distribué.
Et, si vous n'utilisez pas le framework MVC, l'état d'affichage est également là, c'est-à-dire un morceau de données assez lourd qui circule du serveur Web vers le navigateur dans un seul but, revenir au navigateur lors d'une publication. Donc, c'est un voyage assez long, pour rien comme on dit. Donc, ce serait tellement mieux si vous le gardiez du côté serveur et envoyiez simplement une petite clé. Donc, c'est un très très bon cas d'utilisation pour la mise en cache.
Le troisième cas d'utilisation est la sortie de page, beaucoup de vos pages leur sortie ne change pas à chaque fois. Donc, si cela ne change pas, pourquoi exécuter la page car lorsque vous exécutez la page, vous consommez le processeur, la mémoire et toutes les autres ressources. Pourquoi ne pas simplement prendre la sortie de la dernière exécution et l'afficher. Ainsi, Microsoft ou ASP.NET dispose d'un framework de cache de sortie dans lequel vous pouvez brancher un cache distribué. Donc, maintenant dans ce cas d'utilisation, dans ces trois cas d'utilisation sous ASP.NET, la nature du problème a complètement changé. Il ne s'agit plus de synchronisation entre le cache et la base de données. Pourquoi? Parce qu'il n'y a pas de base de données. Le cache est la base de données.
La nature du problème est maintenant... donc le cache est en mémoire, d'accord ? C'est ainsi que vous obtenez toutes les performances. Ainsi, lorsque vous conservez des données en mémoire et que c'est le seul magasin, quelle est votre plus grande préoccupation ? Vous pourriez le perdre ! Et si cette box redémarre ? Windows est connu pour redémarrer ou recycler les processus de travail. Et si et je veux dire, même si une machine Linux devait redémarrer mais, et si votre machine redémarrait ? Êtes-vous prêt à perdre ces données ? Que se passe-t-il si vous êtes une compagnie aérienne et que ce client était dans cette dernière page de soumission d'un billet de vacances d'une valeur de 5,000 XNUMX $ avait ce billet de vacances en famille qu'il allait acheter pour Hawaï et que tout à coup il dit, désolé, vous devez tout recommencer ! Vous savez, ils ont effectué toutes sortes de recherches sur les vols et vérifié les heures, et ont également effectué des vols Google pour voir lesquels correspondaient et tous les autres éléments, donc ce n'est pas une bonne expérience.
En tant qu'entreprise, vous ne voulez pas perdre de client, le panier d'achat, vous ne voulez pas le perdre. Donc, la réponse à cela est un cache distribué. Vous ne devez y conserver des sessions ou toutes ces données transitoires que si elles peuvent garantir la fiabilité, si elles garantissent que vous ne perdrez jamais ces données, assurez-vous qu'elles effectuent la réplication. Ainsi, un bon cache distribué effectue une réplication des données sur plusieurs serveurs. Maintenant, la réplication est en fait une perte de temps, c'est une chose supplémentaire que l'on fait juste pour cette éventualité dont nous venons de parler. Ainsi, le côté négatif de la réplication est qu'elle a un impact sur les performances. Donc, si un cache ne le fait pas intelligemment et que beaucoup d'entre eux ne le font pas, vous constaterez une baisse des performances lorsque vous activez la réplication.
Partage de données d'exécution via des événements
Donc, gardez ces deux points à l'esprit et le troisième cas d'utilisation est ce que la plupart des gens ne savent pas en fait qu'un cache distribué, une fois que vous avez cette infrastructure dans votre environnement, c'est une plate-forme de partage de données événementielle très puissante. Ainsi, vous pouvez avoir plusieurs applications qui doivent partager des données dans un flux de travail. Vous pouvez avoir une situation de type pub/sub, pour laquelle vous allez probablement utiliser un bus de messages, un bus de services d'entreprise ou une file d'attente de messages. Un cache distribué est une plate-forme très puissante pour cela. Puisque vous l'avez déjà en interne, il est en fait plus rapide et plus évolutif que les autres options car il a été conçu pour la performance alors que les autres applications ont été conçues davantage pour le partage uniquement.
Ainsi, le type pub/sub événementiel d'un partage entre plusieurs applications. Une application produit des données, les met dans le cache, déclenche un événement. Il existe d'autres applications qui ont manifesté leur intérêt pour cet événement, que je souhaite utiliser ces données chaque fois qu'elles sont disponibles pour moi. Ainsi, ils reçoivent l'événement et encore une application pourrait être ici, une application pourrait être ici, cela devient un moteur d'événement évolutif très puissant dans lequel ils peuvent tous puiser.
Donc, c'est un troisième cas d'utilisation. Même en l'occurrence, dans la fonction de partage de données d'exécution ou le cas d'utilisation, la plupart des données sont transitoires. Bien qu'il soit dérivé de données permanentes et qu'il pourrait probablement le recréer à partir de ces données permanentes, mais c'est beaucoup de travail à faire et ces données sont généralement dans ce temporaire, car la nature de cela utilise du temporaire. Ce n'est généralement pas le cas, il n'est pas nécessaire de l'enregistrer dans la base de données. Il suffit de le consommer. Donc, le cache est encore une fois le seul magasin qu'il sera et donc, tout comme les sessions et les autres, les problèmes sont les mêmes que la fiabilité doit entrer en jeu. Donc, ce sont les trois façons courantes d'utiliser un cache distribué.
Donc, la bonne chose à propos de ces trois cas d'utilisation est qu'aucune programmation n'est nécessaire pour le faire car l'ASP.NET framework vous permet de brancher un fournisseur tiers. Donc, pour les sessions par exemple, si vous deviez avoir, je vais juste vous montrer rapidement un exemple rapide où tout ce que vous faites est d'aller dans la configuration Web et bien sûr, dans l'ASP.NET core, ce paradigme va légèrement changer mais l'idée est la même.
Configuration de la mise en cache de session ASP.NET
Donc, si vous allez sur Web.config, il ne s'agit que d'une simple application ASP.NET. Vous allez sur Web.config, vous devez d'abord ajouter l'assemblage du cache que vous allez utiliser en cas de NCache, vous allez juste faire l'assemblage d'ajout sur le NCache fournisseur de magasin de session et vous venez de copier coller et la deuxième chose que vous devez vraiment faire est d'apporter des modifications ici.
Donc, il y a une balise d'état de session sur le Web qui configure où vous devez vous assurer que le mode est personnalisé et que le délai d'expiration est quel que soit votre délai d'expiration. Et, en cas de NCache, alors vous devez simplement ajouter cette ligne et là un tas d'autres paramètres que vous pouvez spécifier que je ne vais pas aborder mais l'un d'eux est juste le nom du cache. En cas de NCache, tous les caches sont nommés et je vais en fait vous en donner une démo aussi mais. Donc, il vous suffit de spécifier le nom du cache. Le cache est déjà créé. C'est comme une chaîne de connexion qui vous indique à quel cache vous connecter car vous pouvez avoir plusieurs caches, un pour les sessions, un pour les données d'application et c'est tout. Je veux dire que vous faites ce changement et que vous faites juste un test de cohérence, passez en revue tous les cas d'utilisation courants de votre application et votre application est soudainement prête à stocker des sessions dans un cache distribué comme NCache. Ainsi, le moyen le plus simple d'en bénéficier et le plus gros gain sont en fait les sessions.
C'est donc tout ce que vous avez à faire pour l'utilisation de l'état de session dans un cache distribué comme NCache ou tout autre et il en va de même pour le cache de sortie de l'état d'affichage. C'est tout le changement basé sur la configuration. Je ne vais pas entrer dans chacun d'eux. Je voulais juste vous montrer ceci à titre d'exemple.
Mise en cache des données d'application
Alors, venons-en au cœur d'un cache distribué et je dis cœur parce que c'est là que la plupart de votre temps va être passé. Si vous choisissez d'incorporer un cache distribué, vous consacrerez la majeure partie de votre temps à la mise en cache des données d'application. Alors, à quoi ressemble une API typique ?
Cache cache = NCache.InitializeCache("myCache");
cache.Dispose();Employee employee = (Employee) cache.Get("Employee:1000");
Employee employee = (Employee) cache["Employee:1000"];
bool isPresent = cache.Contains("Employee:1000");cache.Add("Employee:1000", employee);
cache.AddAsync("Employee:1000", employee);
cache.Insert("Employee:1000", employee);
cache.InsertAsync("Employee:1000", employee);
cache["Employee:1000"] = employee;
Employee employee = (Employee) cache.Remove("Employee:1000");
cache.RemoveAsync("Employee:1000");Si vous connaissez l'objet de cache ASP.NET, NCache essaie de l'imiter le plus possible bien que nous soyons un sur-ensemble donc il y a plus. Chaque cache a sa propre API. C'est ce qu'un NCache API ressemble. Vous vous connectez avec le cache, c'est un cache nommé. Vous obtenez un handle de cache, vous gardez ce handle de cache autour et dans l'application que vous gardez, faites juste Cache.Get. Obtenir, Contient, Ajouter, Insérer, Supprimer, il y a aussi ajouter Async, Insérer Async. Insérer signifie ajouter s'il n'existe pas ou mettre à jour s'il existe déjà. C'est la même terminologie que l'objet de cache ASP.NET que vous utilisez, c'est pourquoi nous l'avons également utilisé. Et, la méthode Async signifie essentiellement que vous n'avez pas à attendre que cette opération soit terminée. Vous pouvez en fait, il y a un troisième paramètre qui est que vous pouvez spécifier un rappel. Ainsi, votre rappel sera appelé en cas de problème, sinon vous pouvez à peu près supposer que tout s'est bien passé.
Gardez le cache frais
Ainsi, lorsque nous étions ici, nous avons parlé de la mise en cache des données d'application, la plus grande préoccupation est que vous devez garder le cache à jour. Ainsi, un bon cache distribué doit vous permettre de le faire, car si ce n'est pas le cas, il vous oblige à mettre en cache les données en lecture seule. Les données en lecture seule représentent environ 10 à 15 % de vos données, de toute façon. Alors, comment allez-vous vraiment tirer parti de ce cache si vous ne mettez en cache que 10 à 15 % de ce que vous devriez mettre en cache ? Donc, ce que vous voulez faire, c'est mettre en cache toutes les données, pratiquement toutes les données, très très peu de données seraient là où vous dites que cela n'a vraiment aucun sens de mettre en cache. Mais presque toutes les données. Certaines des données que vous mettrez en cache pendant une courte période. Ainsi, une fois que vous avez mis en cache ces données, il s'agit de toutes les données d'application, le cache le plus dur garantit que le cache est frais, les différentes façons dont il peut le faire sont les expirations.
Utilisation des expirations basées sur le temps
L'expiration est une expiration absolue et il y a une expiration glissante. Ils 2 ont des significations très différentes même s'ils sont tous les deux des expirations. L'expiration absolue est ce que vous devriez faire pour garder le cache à jour, car vous faites l'hypothèse que vous dites, je sauvegarde cet objet client dans le cache. Je pense qu'il est sûr de mettre en cache à cinq minutes. Vous faites juste une supposition basée sur, c'est une supposition éclairée mais c'est une supposition. Dans les cinq minutes, vous espérez que personne ne le modifiera dans la base de données, mais s'il le fait, votre cache sera incohérent avec la base de données. L'expiration glissante, en revanche, n'a rien à voir avec la synchronisation du cache. Cela a à voir avec l'éviction ou avec le nettoyage automatique du cache.
Ainsi, les sessions, vous dites que lorsque personne n'est connecté, après 20 minutes d'inactivité, supprimez la session. Donc, vous faites comme un nettoyage. Vous dites que la cache s'il vous plaît nettoyez-la, nettoyez-la pour moi. Je ne veux pas avoir à garder une trace de tout cela. Je l'ai mis dans le cache, j'ai spécifié combien de temps il doit rester dans le cache même si personne ne le touche, après cela, nettoyez-le. Donc, des objectifs très différents que vous avez entre l'expiration permanente et l'expiration absolue par rapport à l'expiration glissante. Ainsi, l'expiration glissante, vous l'utiliseriez pour les sessions pour les données transitoires. Expiration absolue, que vous utiliseriez pour les données permanentes.
Un autre terme que je souhaite utiliser est celui des données de référence par rapport aux données transactionnelles. Les données de référence sont des données qui ne changent pas très fréquemment, mais elles changent, ce n'est pas une lecture seule. c'est, c'est votre tableau de produits dont le prix peut changer tous les jours ou toutes les semaines ou quelque chose comme ça mais ce n'est pas aussi fréquent qu'un objet client ou qu'un objet d'activité ou quelque chose ou un objet de commande. Ainsi, les données transactionnelles sont ce que nous voulons mettre en cache. Bien sûr, les données de référence sont une donnée que nous voulons mettre en cache, mais les données transactionnelles sont également quelque chose où nous allons obtenir toutes les données. Donc, si l'expiration n'est pas suffisante pour garantir que votre cache restera frais, vous devez avoir plus de fonctionnalités.
Utilisation des dépendances de base de données
Ainsi, la fonctionnalité suivante, une fonctionnalité très puissante qu'un bon cache distribué doit avoir, est qu'il doit être capable de synchroniser le cache avec la base de données sans vous impliquer, sans que vous ne surveilliez les choses. Donc, vous devriez pouvoir dire au cache que je mets cet objet en cache. Ceci est lié à cet ensemble de données dans la base de données. Veuillez donc surveiller cet ensemble de données dans la base de données. Voyez s'il change, veuillez aller faire une ou deux choses, soit supprimer cet élément du cache, la suppression signifie que la prochaine fois que l'application le voudra, elle ne le trouvera pas dans le cache. Que se passe-t-il lorsque vous ne le trouvez pas dans le cache ? Vous l'obtenez de la base de données. Donc, c'est comme obtenir une nouvelle copie ou une seconde, il pourrait simplement recharger une nouvelle copie automatiquement. Le rechargement d'une nouvelle copie nécessite automatiquement une autre fonctionnalité appelée lecture dont je parlerai.
Donc, je reviendrai là-dessus, mais synchronisation de la base de données est une fonctionnalité très très puissante. C'est ce qui vous donne la tranquillité d'esprit pour vous assurer que votre cache restera fraîche. Que vous n'aurez pas à vous soucier des données que vous mettez en cache et qu'il existe différentes façons de synchroniser le cache avec la base de données. La plus courante est la dépendance SQL qui est en fait une fonctionnalité de serveur ADO.NET ou SQL qui NCache les usages.
Ainsi, par exemple, je vais vous montrer le code que j'étais censé montrer. Alors, laissez-moi rapidement... Je vais vous montrer rapidement à quoi ressemble le code. Où est-ce que ça va? Donc, si vous avez une application .NET, disons que c'est NCache, bien sûr, vous feriez référence à deux de NCache bibliothèques. NCache.Exécution et NCache.La toile. Donc, encore une fois, nous avons essayé de le nommer aussi proche de l'espace de noms d'objet de cache ASP.NET afin NCache.La toile. Lorsque nous sommes sortis en 2005, l'objet cache ASP.NET était le seul cache disponible, nous sommes donc les plus anciens de l'espace, c'est pourquoi nous avons choisi ce nom pour le rendre plus facile pour les gens. Ainsi, dans l'application, vous incluriez quelques NCache espaces de noms. Ensuite, vous vous connectez avec votre cache, vous obtenez un handle de cache et maintenant vous avez un handle de cache donc, disons, vous créez votre objet et vous voulez faire Cache.Add. Ainsi, Cache.Add prend une clé. Notez que la clé est en fait une chaîne, nous avons donc suivi cela. Eh bien, cela ne suit pas cette convention de dénomination, mais c'est généralement Customer:CustomerID: quel que soit l'ID de ce client, vous faites donc Cache.Add après et vous, dans ce cas, spécifiez une expiration absolue d'une minute. Comme dit, ne faites aucune expiration glissante et toutes les autres choses. Donc, c'est juste pour vous donner une idée de ce à quoi ressemble une cache.
API très facile à utiliser, très simple, beaucoup plus simple que de faire ADO.NET ou toute autre programmation.
À quoi ressemble une cache ?Laissez-moi juste en fait, laissez-moi vous montrer à quoi ressemble un cache mais avec un vrai cache. Donc, j'ai ces machines virtuelles et Azure. Donc, j'ai démo 1 et 2 deux. Ce sont deux serveurs de cache que je vais utiliser. Ce sont des VM de cache et j'aurai mon serveur d'application. Je vais juste l'appeler client de démonstration. Donc, mon application va s'exécuter sur un client de démonstration. D'accord! Donc, j'ai Remote Desktop dans ce domaine. je vais en cas de NCache Je vais exécuter cet outil appelé NCache gestionnaire, je l'ai en fait ici. Et, je vais aller de l'avant et créer. Permettez-moi de m'assurer rapidement qu'il n'y a pas déjà de cache portant ce nom. D'accord! Donc, je vais continuer et créer un nouveau cache. Je vais appeler mon cache cache démo. Je vais juste prendre tout le reste par défaut. Je choisirai une topologie de mise en cache. Je ne vais pas entrer dans les détails, mais cette topologie de mise en cache effectue à la fois le partitionnement et la réplication. Ainsi, lorsque vous faites cette topologie, votre cache ressemblera à ceci.
Donc, ce sont vos serveurs de cache. Donc, certaines des données, ce 1 2 3 4 sont les éléments de données. Ainsi, certaines données se trouvent dans la partition 1, certaines données se trouvent dans la partition 2 et chaque partition est sauvegardée sur un serveur différent. Donc, si vous aviez 3 serveurs ici.
Disons que vous auriez les partitions 1, 2 et 3, le serveur 2 a la réplique de la partition 1, le serveur 3 a une réplique de la partition 2 et le serveur 1 a la réplique d'une partition 3. Ainsi, le cache est en fait un serveur. Il s'agit en fait de plusieurs serveurs, qui se trouvent dans un cluster. Ils se connaissent et je vais rapidement vous y ramener. Donc, disons que j'ai choisi une topologie de réplique de partition. Je choisirai la démo 1 comme premier serveur de cache. Pourquoi est-ce si lent ? Demo 2 comme deuxième serveur de cache. Je pense que c'est probablement parce qu'Internet est lent, peut-être. Je ne sais pas. Donc, j'ai un cluster de cache à deux nœuds. Ainsi, la démo un et deux se connaissent maintenant. Donc, ils vont se parler sur ce port. Sur le port 7802 que je pourrais changer. Pourquoi est-ce si lent ? S'assurer.
D'accord! Donc, la prochaine fois, je vais spécifier la quantité de mémoire que le cache doit avoir. Donc, il y a un concert, vous aurez probablement, comme je l'ai dit, 13 concerts ou quelque chose comme ça. Et, ensuite, je vais spécifier la politique d'expulsion qui est la moins récemment utilisée. J'économiserai 15%... Je suis désolé d'expulser 5% du cache. C'est vraiment lent, je ne sais pas ce qui se passe. Toute cette boîte est lente, même un clic l'est, même le CPU ne l'est pas, ouais ! Ça y ressemble. Ouais c'est ça!
D'accord! Donc, fondamentalement, vous avez un cluster de serveurs qui s'appelle logiquement le cache et vous ne les connaissez que par un cache de démonstration. Sur votre boîtier, disons, votre boîtier de serveur d'application, disons NCache est installé ici. Vous allez avoir un fichier de configuration qui aura ce nom de cache et une liste de serveurs qui le représentent. Donc, ce n'est qu'un point de départ, mais encore une fois, vous saurez que le cluster entier n'est qu'un nom de cache et que vous vous y connectez, puis votre API client se connectera à tous les serveurs de cache de cette image. Dans le cas de répliques de partition, chaque client communique avec tous les serveurs afin qu'il puisse aller directement là où se trouvent les données, la partie partitionnement.
Je vais continuer et ajouter un client pour cela qui est mon client de démonstration. Je vais continuer et cliquer sur l'assistant de cache, en prenant beaucoup de temps pour cliquer, et je dirai démarrer le cache. Donc, juste en disant que le cache va démarrer sur ces deux boîtes. NCache est un cache basé sur Windows, il possède donc toutes les fonctionnalités faciles à utiliser d'un bon produit basé sur Windows. Ainsi, vous pouvez faire tout cela à partir d'un endroit central, tout cela que vous pouvez également faire via des scripts.
Synchronisation de base de données - DémoAlors, laissez-moi vous montrer à quoi ressemble la synchronisation de la base de données. Ainsi, par exemple, ce que vous faites est, encore une fois, c'est le même type d'application, vous avez le cache et lorsque vous essayez d'ajouter une donnée au cache, disons que vous faites Cache.Add ici et c'est bien sûr NCache code, vous spécifiez une dépendance de cache SQL qui est un NCache classe mais il mappe sur le back-end à la classe de dépendance SQL du serveur SQL. Et, vous lui passez une chaîne SQL qui est ensuite utilisée par NCache pour se connecter à la base de données et le serveur de cache devient alors un client de votre base de données. Ainsi, par exemple, si votre application est ici, disons que votre code s'exécute ici, vous venez de lancer cet appel. Oops désolé! Vous venez d'émettre cet appel de cache cette annonce et vous passez cette dépendance de cache SQL. Le client envoie tout cela au serveur de cache.
Donc, l'un des serveurs de cache ou plusieurs. Et, le serveur de cache ouvre maintenant une connexion à la base de données car vous avez également spécifié une chaîne de connexion ici. Et, cette force de connexion est bien sûr piscine. Alors. si vous spécifiez plusieurs fois la même chaîne de connexion, il existe un pool de connexions sur le back-end. Ainsi, un autre cache est maintenant devenu un client de votre base de données. Il surveillera votre base de données afin que la base de données avertisse le NCache serveur que ces données ont changé que vous m'avez demandé de surveiller et le NCache serveur à ce moment-là peut décider s'il doit supprimer cet élément du cache ou le recharger à partir de la base de données. Et, pour le recharger, vous devez réellement passer par la fonction de lecture.
D'accord! Donc, c'est une façon de le faire. C'est vraiment puissant. C'est piloté par les événements. Dès que le changement se produit, la base de données notifie le cache, le cache prend immédiatement l'action. Cependant, il y a une surcharge sur cette extrémité de serveur de base de données car chaque fois que vous créez une dépendance de cache SQL, une structure de données doit être créée dans le serveur SQL pour surveiller cet ensemble de données. Maintenant, si vous en aviez 1 million, je peux vous garantir que votre serveur SQL va planter. Encore une fois, puisque nous parlons d'évolutivité, vous devez penser en termes de très grands nombres. Donc, si vous en avez des milliers ou des dizaines de milliers, pas de problème. Mais si vous en avez des centaines de milliers ou des millions, une stratégie différente serait une meilleure stratégie.
Dépendance de la base de donnéesUne autre stratégie est appelée dépendance DB qui est la nôtre NCache fonctionnalité qui est une dépendance basée sur l'interrogation. Nous avons implémenté ceci où. Il y a une table spéciale et nous vous demandons de modifier les déclencheurs afin que vous puissiez mettre à jour l'indicateur dans cette table pour cette ligne correspondante, puis chaque fois que vous faites une dépendance DB à partir du cache, le cache crée une entrée dans cette table puis en une seule extraction , le cache peut récupérer des milliers de lignes où l'indicateur est vrai, la mise à jour a été effectuée. Donc, c'est comme notre propre façon de garder une trace. C'est basé sur les sondages donc ce n'est pas instantané. Par défaut, un délai d'environ 15 secondes, mais vous pouvez le reconfigurer. Vous ne voulez pas non plus tirer trop souvent. Donc, c'est l'autre mais même là, vous avez une limitation de, et si vous avez 1 million de lignes dans cette table avec un indicateur vrai et faux, l'index aurait l'air assez gros, non ? Il y a un vrai et un faux index, ce sont les deux nœuds d'un arbre. Ainsi, la dépendance DB est plus efficace que la dépendance SQL mais pas en temps réel, mais elle a même des limites.
Procédures CLRLe troisième est les procédures CLR où vous pouvez réellement appeler une procédure CLR à partir d'un déclencheur dans la base de données, donc chaque fois qu'un élément est ajouté, mis à jour ou supprimé, vous appelez la procédure. La procédure effectue un appel Async au cache. Il dit s'il vous plaît ajouter ou mettre à jour ou supprimer cet élément du cache. La raison pour laquelle Async est critique est que vous ne voulez pas retarder la transaction, la transaction de base de données. Il va commencer à chronométrer autrement. Ainsi, un appel Async reviendra immédiatement et au moins la transaction de base de données pourra être validée et le cache pourra être mis à jour. Ainsi, la synchronisation du cache avec la base de données est une fonctionnalité essentielle.
Synchroniser le cache avec non relationnel
Vous devez avoir cela et la même chose si vous avez des données non relationnelles ou si vous avez un ordinateur central ou hérité ou toute autre source de données, vous pouvez avoir une source de données cloud, vous pouvez effectuer des appels de méthode Web pour même vérifier si ces données est mis à jour ou non et NCache vous permet d'avoir cette fonctionnalité de dépendance personnalisée où c'est votre code qui peut surveiller NCache, appelle votre code à chaque petit intervalle, vous allez surveiller votre source de données pour voir si ces données ont changé, si elles vous ont notifié NCache ainsi que NCache supprimera ou rechargera de la même manière.
Traitement des données relationnelles
Il est donc essentiel de garder le cache à jour. Toute cache qui ne vous permet pas de faire cela limite votre capacité à en bénéficier. Je vais sauter le traitement des données relationnelles même si ce n'est pas le cas et quoi, permettez-moi de le dire rapidement, vous avez des relations un-à-plusieurs, des relations un-à-un. Donc, si vous avez un élément dans le cache et de nombreux éléments également dans le cache, lorsque vous supprimez logiquement un élément du cache, les nombreux éléments doivent également être supprimés, car que se passe-t-il si vous l'avez supprimé de la base de données. Ainsi, le cache devrait pouvoir garder une trace de tout cela. Vous pouvez le faire dans votre application, mais cela ne fait que compliquer le crédit de votre application car vous faites maintenant beaucoup de comptabilité pour le cache. C'est comme si vous construisiez une synchronisation de base de données ou un code d'intégrité des données dans l'application, ce qui n'est pas le travail de votre application. Vous ne faites pas cela pour la base de données. La base de données le fait pour vous, donc le cache devrait également le faire pour vous.
Lecture et écriture
Ainsi, la lecture et l'écriture sont une autre fonctionnalité très puissante que votre cache devrait avoir. La lecture est essentiellement, encore une fois, le concept est très simple.
Vous implémentez une interface, en cas de NCache vous implémentez une interface appelée fournisseur de lecture, ici. Vous pouvez la voir?
Ouais et il a trois méthodes. Il y a un Init qui est appelé lorsque le cache démarre afin que vous puissiez vous connecter à votre source de données. Il y a une disposition lorsque le cache s'arrête, vous pouvez faire votre nettoyage et la plupart du temps, vous appelez cette charge à partir de la source. Donc, il passe votre clé. La clé est votre clé pour savoir quel élément de votre source de données récupérer, puis vous le restituez, en cas de NCache un élément de cache de fournisseur. Et, vous pouvez spécifier des expirations et resynchroniser à l'expiration, toutes sortes de drapeaux ici, puis les transmettre à NCache. NCache le met en cache.
Alors, comment fonctionne la lecture continue ? La façon dont nous fonctionnons est que votre application demande toujours le cache. Il dit Cache.Get. Si le cache ne contient pas les données, au lieu de dire que je ne les ai pas, il les récupère dans la base de données. Ainsi, votre application devient soudainement beaucoup plus simple. Une grande partie du code de persistance que vous venez de retirer de votre application. Ainsi, l'un des avantages de la lecture est que vous avez en quelque sorte simplifié le code, vous avez tout encapsulé dans le niveau de mise en cache. Le niveau de mise en cache a maintenant de plus en plus de votre couche de persistance. Tout le code ne peut pas être lu par lecture, mais une grande partie peut l'être.
Recharger à l'expiration
Le deuxième avantage de la lecture est ce dont j'ai parlé plus tôt, à savoir la fonction de rechargement. Imaginez maintenant, si vous avez une application de commerce électronique et que vos prix changent et que chaque fois que les prix changent, ces éléments doivent être supprimés du cache et rechargés, mais le trafic est très important, donc pendant qu'ils sont supprimés, de nombreuses demandes de clients arriveront. la base de données. Le premier le récupèrera et le mettra dans le cache, mais jusqu'à ce moment-là, le cache aura soudainement beaucoup de trafic inutile et si cela continue, si vous en avez beaucoup, la base de données recevra beaucoup de visites inutiles que vous auriez pu éviter si vous disiez simplement recharger à l'expiration. Donc, recharger une expiration, ça fait quoi ? Il ne supprime pas l'élément à l'expiration. Il le recharge simplement pour que, lorsque l'expiration se produit, le cache appelle la lecture et aille le chercher à partir de votre source de données et se contente de le mettre à jour. Il n'y a donc qu'une opération de mise à jour en cours. Il n'y a pas d'opération de suppression et d'ajout et à cause de cela, les données ou l'élément sont toujours dans le cache. Ainsi, le cache devient soudainement. Il peut prendre soin de lui-même et il peut aller se recharger chaque fois que des données doivent être rechargées.
Ecriture
C'est donc une capacité de lecture vraiment puissante. Ainsi, lorsque vous combinez cela avec l'expiration, vous pouvez également le faire avec la synchronisation de la base de données. Lorsque la synchronisation de la base de données se produit, encore une fois, pourquoi la supprimer ? Rechargez simplement. L'autre fonctionnalité est l'écriture continue qui fonctionne exactement comme une lecture continue, sauf qu'elle écrit. Il y a encore une chose qu'il fait, il peut aussi faire de l'écriture en bloc. Et, la raison pour laquelle il écrit en masse, je vais l'expliquer un peu. Donc, de la même manière qu'il y a un Init, il y a une disposition et maintenant il y a une écriture dans les sources de données. L'écriture ne signifie pas seulement ajouter ou insérer. Il peut également être supprimé afin que l'écriture ait un type d'opération qui peut ensuite être ajouté, mis à jour ou supprimé. Et cela dépend de l'opération de cache. Et puis vous pouvez aussi le faire en vrac. Ainsi, l'écriture directe présente les mêmes avantages que la lecture continue en termes de simplification de votre code, mais présente à nouveau un avantage supplémentaire. Ainsi, la lecture a eu l'avantage de recharger l'écriture a l'avantage où vous pouvez écrire derrière.
Écriture derrière
Et, écrire derrière est une fonctionnalité très très puissante. Pourquoi? Parce que les mises à jour de la base de données sont un goulot d'étranglement. Encore une fois, la base de données est ce mal nécessaire avec lequel vous devez vivre. Vous ne pouvez pas vous en passer, mais cela provoque toutes sortes de goulots d'étranglement dans votre application. Ainsi, moins vous pouvez en dépendre, meilleure sera votre candidature. Le fait que vous ne pouvez pas vivre sans elle, vous devez toujours l'avoir. Alors, que fait une écriture différée ? Il dit que vous mettez à jour le cache qui est ultra-rapide, dix fois au moins plus rapide que la base de données sinon plus, puis le cache s'occupe de la mise à jour de la base de données. Donc, il y a une écriture immédiate asynchrone, c'est une écriture différée. Donc, vous irez mettre à jour le cache, revenez et vous continuez vos trucs et le cache va et met à jour la base de données.
Bien sûr, il y a beaucoup de problèmes que le cache doit résoudre. Dès que vous dites que le cache doit mettre à jour la base de données, que se passe-t-il si le serveur de cache plante ? Qu'advient-il de cette file d'attente ? Ainsi, en cas de NCache, la file d'attente elle-même est répliquée sur plusieurs serveurs si un serveur tombe en panne, vous ne perdez pas la file d'attente. Ensuite, il y a aussi des tentatives. Et si cette mise à jour échoue, vous pouvez réessayer. Vous pouvez également effectuer une mise à jour par lots. Donc, il y en a beaucoup que vous pouvez faire une mise à jour groupée. Ainsi, il peut encore optimiser les choses. Ainsi, l'écriture et la lecture sont des fonctionnalités très très puissantes. C'est ce qu'on appelle le code côté serveur. Ceci est votre code qui vit sur le cluster de cache. Il vit ici et garder ce code sur le serveur simplifie votre application. Ainsi, plus vous poussez de code, plus l'application devient simple.
Regroupement de données
D'accord! Maintenant que, disons, vous êtes convaincu que vous devez utiliser la mise en cache. Vous avez les différents cas d'utilisation où vous êtes maintenant sûr de mettre en cache beaucoup de données. Alors maintenant, le cache a commencé à ressembler à la base de données. ça commence à en avoir beaucoup, vous allez avoir des millions d'éléments dans le cache. Ainsi, lorsque vous avez des millions d'éléments dans le cache, est-il bon de simplement lire les choses en fonction d'une clé ? Non! si la seule façon de lire les éléments du cache en fonction de la clé, votre application serait très très difficile par rapport à si vous pouviez faire des choses, eh bien, donnez-moi toutes les choses en fonction de ces critères de recherche.
Ainsi, la recherche et le regroupement deviennent un besoin très très puissant ou un besoin très important d'un cache. Encore une fois, comme je l'ai dit, le but est que vous compreniez quels sont les avantages. L'avantage est que vous pouvez mettre en cache de plus en plus de données. Plus vous avez de données en cache, plus vous avez besoin de les voir ou d'avoir plus de fonctionnalités de type base de données. L'une de ces fonctionnalités est de pouvoir faire des métadonnées. Dans la base de données, vous pouvez avoir des index sur de nombreux attributs différents. Ici, vous pouvez faire des balises, des balises nommées et en fait lorsque vous cachez les objets, en cas de NCache il vous permet également de créer des index. Ainsi, vous pouvez indexer un objet. Supposons qu'un client puisse être indexé sur l'attribut de la ville car vous allez rechercher sur la ville, il doit donc être indexé. Si ce n'est pas indexé, cette recherche va être vraiment pénible. Imaginez des millions d'articles que vous devez d'abord désérialiser pour inspecter chaque objet juste pour savoir quels clients à Orlando. Pas une bonne image pas une jolie vue.
Donc, regrouper à nouveau les balises de sous-groupement et les balises de nom d'un point de vue de codage très simple. Je vais juste vous montrer ça rapidement. Du point de vue de l'enregistrement très facile à utiliser. Vous ajoutez un tas d'éléments et vous lui attribuez des balises et ensuite, je suis désolé ! groupe et sous-groupe, sous-groupe de groupe, puis vous dites obtenir les données du groupe ou vous pouvez également effectuer une recherche SQL et dire donnez-moi tous les objets du produit où le nom du groupe est électronique. Ainsi, les balises et les balises de groupement et de sous-groupement sont également quelque chose qui AppFabric à condition d'ailleurs AppFabric est interrompu en février. Nous avons plus de minutes, je vais accélérer.
Trouver des données
Encore une fois, la recherche de données est liée au regroupement de données que vous souhaitez pouvoir rechercher dans des données basées sur SQL, donc je pense que je… où est le langage de requête d'objet ? Le voilà. Donc, je pourrais, en gros, j'ai un tas de données et je pourrais émettre une instruction SQL et je peux spécifier plusieurs attributs et passer des paramètres et j'obtiendrai un jeu d'enregistrements en cas de NCache et tout comme SQL Server, bien que ce soit un sous-ensemble du SQL complet. Il ne fait pas de joints mais au lieu de faire des jointures, vous pouvez faire des regroupements et des tags et c'est ainsi que vous pouvez regrouper plusieurs objets ensemble.
Ainsi, en cas de LINQ, NCache a implémenté un fournisseur LINQ donc l'interface Iqueryable. Vous allez chercher cette collection de NCache puis vous faites une requête LINQ comme vous le faites sur n'importe quelle autre collection d'objets et cela va continuer et vous récupérer une collection de ces objets, les objets de produit. Donc, si LINQ est vraiment votre zone de confort en termes de recherche, utilisez LINQ pour rechercher. Lorsque vous émettez cette requête, vous allez au cluster que la même requête va être envoyée à tous les serveurs et les résultats vont venir et être fusionnés puis affichés. Donc, il se peut, bien que cela semble très simple ici, qu'en coulisses, il y ait beaucoup de travail effectué par NCache.
Donc, nous avons SQL et LINQ. Nous avons aussi du vrac et comme je l'ai dit, vous pouvez faire de l'indexation.
Partage de données d'exécution
Je vais juste très rapidement… il y a des événements basés sur des clés, il y a des événements au niveau du cache, il y a des événements de sous-publication, il y a une requête continue.
La requête continue est une fonctionnalité qui ressemble à une fonctionnalité de dépendance SQL, sauf qu'elle se trouve sur le cache. Vous demandez au cache de surveiller un ensemble de données pour vous. Donc, tout comme nous utilisions la dépendance SQL et demandions au serveur SQL de surveiller cet ensemble de données et disions que si cet ensemble de données change, veuillez m'en informer. Maintenant, tu demandes NCache, en disant s'il vous plaît, voici mon instruction SQL, sélectionnez les clients où Customer.City est égal à New York et vous dites que si un client correspondant à ces critères est ajouté, mis à jour ou supprimé du cache, veuillez m'en informer et cela pourrait être n'importe où sur le réseau, n'importe où sur le cluster de cache et vous pourriez être n'importe quel autre client. Vous serez averti. Donc, en ayant ces types de fonctionnalités maintenant, vous pouvez soudainement surveiller ce qui se passe dans le cache et être averti au lieu d'interroger les choses et c'est ce que je disais, le cache devient une plate-forme de partage de données d'exécution vraiment puissante.
Haute Disponibilité
D'accord! Je vais sauter ça aussi. Je veux dire que tout cache que vous utilisez doit avoir une dynamique. Il doit fournir une haute disponibilité qui, en cas de NCache, il a une architecture peer-to-peer.
Cache Client
Il y a une fonctionnalité que je veux que vous connaissiez et qui s'appelle cache client. Certaines personnes l'appellent près de la cache.
Il s'agit en fait d'un cache qui se trouve localement sur votre serveur d'applications. C'est comme un cache autonome sauf qu'il n'est pas autonome. Ainsi, il peut même s'agir d'InProc. Cela peut être dans votre processus d'application, ce qui signifie que vous récupérez en fait des choses comme sur votre tas d'objets. Votre tas contient des données sous forme d'objet. Rien ne vaut cette performance, n'est-ce pas? Si vous pouvez simplement obtenir ces données à partir du tas plutôt que d'aller dans une boîte locale de cache OutProc, car lorsque vous traversez des processus, il doit passer par IPC, il doit faire de la sérialisation, de la désérialisation, lorsque vous traversez le réseau, c'est encore plus, quand vous allez à la base de données, c'est phénoménalement cher, comparativement.
Il s'agit donc d'un cache local dans votre processus de candidature ou localement sur la boîte. Mais, il reste synchronisé. Vous ne faites aucune programmation d'API spéciale pour le cache client. Vous faites juste les appels au cache, en cas de NCache, il se branche simplement sur le changement de configuration et il intercepte les appels et tout ce que vous récupérez en conserve une copie localement. Ainsi, la prochaine fois que vous le récupérerez, il l'obtiendra automatiquement du cache local. Énorme augmentation des performances. C'est quelque chose qui ne fait que NCache a du côté .NET. Du côté Java, il existe d'autres produits qui ont un cache client mais sur le .NET dit que c'est seulement. C'est comme un cache au-dessus d'un cache et c'est la raison pour laquelle de nombreuses personnes, lorsqu'elles passent du cache InProc autonome à un cache distribué, se plaignent, mes performances ont en fait chuté, mon application est plus lente, je pensais que le cache distribué était censé augmenter mes performances et nous leur disons non, c'est censé augmenter l'évolutivité. Rien ne correspond à un cache InProc local, personne ne le peut. Je veux dire ce n'est pas quelque chose que nous pouvons inventer et faire quelque chose. Vous traversez des processus, c'est un coût qu'il faut.
Donc, nous disons bien, une façon de surmonter ce défi consiste à utiliser un cache client. Ainsi, un cache client est à nouveau un sous-ensemble. Habituellement, vous auriez 16 à 32 concerts dans chaque serveur de cache. Donc, si vous avez trois à quatre serveurs, vous avez potentiellement plus d'une centaine de Go de données en cache et le cache client peut-être un Go, peut-être deux Go, peut-être trois ou quatre Go, maximum chacun et dépend du nombre de processus de travail que vous avoir. Si vous n'avez qu'un seul processus de travail, faites-en quatre gig. Si vous avez huit processus de travail, ce que bon nombre de nos clients haut de gamme ont sur leur niveau Web, vous ne voulez pas en avoir quatre fois huit uniquement dans le cache client. Alors peut-être qu'il est bon d'avoir un cache de processus de quatre Go, ce qui est toujours mieux que d'aller au niveau de la mise en cache. C'est toujours plus rapide ou vous pouvez avoir un plus petit gig ou moins d'un gig cache qui est InProc. Maintenant, vous en avez huit copies, mais elles sont également synchronisées. Donc, un cache client est certainement quelque chose que vous devez envisager d'utiliser si vous souhaitez tirer parti d'un cache.
Maintenant, mon objectif et ce n'est pas de vous vendre des fonctionnalités de caches mais de dire ce qu'un bon cache doit avoir et bon nombre de ces fonctionnalités que vous trouverez du côté Java. Java est un marché beaucoup plus mature du côté de la mise en cache. Ils utilisent le mot grille de données en mémoire au lieu de cache distribué, mais quelle que soit la fonctionnalité que vous voyez avec NCache, vous en verrez beaucoup également du côté Java, mais du côté .NET NCache est le seul.
Réplication WAN
Une autre caractéristique est que si vous avez plusieurs centres de données, vous voudriez que votre base de données soit répliquée, alors pourquoi pas le cache ? Qu'est ce que tu vas faire? Allez-vous reconstruire tout le cache ? Qu'en est-il du panier ? Et les séances ? Ainsi, plusieurs centres de données sont une réalité et le cloud a rendu cela encore plus facile car il n'y a aucun effort de votre part. Vous dites simplement région un et région deux et vous avez deux centres de données, n'est-ce pas ? Mais le problème sous-jacent ne disparaît pas, c'est-à-dire que si vous utilisez un cache distribué qui ne prend pas en charge la réplication WAN, vous êtes bloqué. Vous ne pouvez pas avoir une solution multicentre de données active-active ou même active-passive sans que le cache ne soit répliqué, donc une fonctionnalité très importante.
NCache a bien sûr ceci. Je vous ai déjà donné la démo pratique. NCache est le plus ancien cache .NET du marché. Nous avons été lancés en 2005, bien avant.
NCache vs Redis
Donc, je vais passer rapidement NCache versus Redis, très très haut niveau et c'est parce que Redis est beaucoup de gens viennent nous demander comment vous comparez-vous avec Redis depuis que Microsoft les a choisis pour Azure.
Redis, est un excellent produit. C'est super rapide. Cela vient principalement du côté Linux. Il n'a pas beaucoup de fonctionnalités. Il ne gagne pas sur les fonctionnalités. Il gagne simplement sur le fait qu'il vient du côté Linux et que Microsoft voulait conquérir le marché AWS afin de ne pas pouvoir adopter une solution .NET. Ils ont dû adopter, multi-plateforme. Donc, leur version Linux est très stable, très bonne, mais le port Windows que Microsoft a fait lui-même est une sorte de port orphelin. Microsoft ne l'utilise pas lui-même. Lorsque vous êtes dans Azure et que vous utilisez Redis, vous n'utilisez pas le port Windows de Redis, vous utilisez la version Linux. Donc, si vous n'êtes pas sur azur et que vous allez utiliser le port Windows de Redis, il faut se méfier. Je veux dire que personne ne le possède. Redis labs, si vous allez sur leur site Web, ils n'ont même pas de téléchargement Windows. Je veux dire qu'ils n'ont que des téléchargements Linux qui est le créateur de Redis. Microsoft, comme je l'ai dit lui-même, n'a pas mis son argent là où il l'avait dit en termes d'utilisation de l'engagement.
Alors, NCache est la seule option viable pour vous et c'est open source donc si vous n'avez pas l'argent, optez pour la version open source gratuite. Si votre projet est important et que vous souhaitez une assistance et davantage de fonctionnalités, il s'agit des fonctionnalités d'entreprise. L'entreprise NCache est construit sur open source. Ce n'est pas comme une chose séparée. L'open source n'est pas orphelin. Je veux dire que nous le possédons, nous l'entretenons et l'entreprise est construite au-dessus. Donc, l'open source doit être stable, mais si vous voulez du support et plus de fonctionnalités, achetez simplement l'édition Enterprise.
Nous sommes natifs .NET. Nous avons développé en c-sharp et nous avons la certification Windows Server 2012 r2. Nous allons également recevoir le prochain prochainement. Donc, nous voulons dire que nous ne sommes pas au top du jeu en ce qui concerne Microsoft. Nous sommes à peu près .NET, c'est ce que nous sommes. Nous avons un client Java mais la quasi-totalité de nos utilisations Java par des clients qui achètent NCache pour .NET et puisqu'ils l'ont en interne, ils l'utilisent également à partir de Java. Donc, notre pain et notre beurre, toute notre survie est sur .NET. Donc, nous allons toujours être les plus récents et les meilleurs, les premiers et les plus faciles.