Comment faire évoluer les applications EF Core vers des performances extrêmes ?
Webinaire enregistré
Par Ron Hussain et Zack Khan
EF Core est de plus en plus utilisé dans les applications serveur .NET à transactions élevées (ASP.NET, services Web, microservices et autres applications serveur). De plus, ces applications sont confrontées à des goulots d'étranglement d'évolutivité provenant des bases de données qu'elles peuvent éliminer en utilisant la mise en cache distribuée dans EF Core.
- Introduction aux nouvelles fonctionnalités d'EF Core (modèle, requête, enregistrement de données)
- Comment le cache distribué résout les goulots d'étranglement de la base de données EF Core
- Différentes façons d'utiliser la mise en cache distribuée dans les applications EF Core
- Détails sur l'utilisation des méthodes d'extension EF Core pour la mise en cache
- Gestion de la mise en cache des collections et des relations de données
Entity Framework Core ou EF Core est le nouveau moteur de mappage relationnel d'objet multiplateforme et léger de Microsoft pour .NET qui élimine le besoin de la plupart du code d'accès aux données que les développeurs écrivent autrement. Semblable à .NET Core, EF Core est également multiplateforme, ce qui signifie que vous pouvez l'utiliser sur Windows, Linux, Mac et devient très populaire au sein de la communauté des développeurs.
Comment faire évoluer votre application pour atteindre des performances extrêmes ainsi qu'une croissance linéaire de la capacité de traitement des demandes ? Ainsi, vous pouvez faire évoluer votre application, l'application Entity Framework Core à l'aide de NCache méthodes d'extension. Nous en avons donc aligné quelques-uns que vous pouvez utiliser. Différents scénarios que je peindrai et ensuite sur la base de ceux-ci, je présenterai NCache méthodes d'extension ainsi que des fonctionnalités de mise en cache d'objets que vous pouvez utiliser dans une application Entity Framework Core typique de votre environnement.
Qu'est-ce qu'Entity Framework / EF Core ?
Tout d'abord, je parlerais d'Entity Framework et d'Entity Framework Core en général. Je suis presque sûr que tout le monde connaît EF et EF Core, mais juste dans un souci d'exhaustivité, pour créer quelques détails d'introduction.
Entity Framework est un ORM que vous pouvez utiliser pour .NET et avec EF Core, vous pouvez également l'utiliser pour .NET ainsi que pour .NET Core. Entity Framework simplifie la programmation de votre base de données. Vous pouvez travailler sur un modèle d'objet conceptuel. Ainsi, vous n'avez pas à travailler directement avec le modèle de données et cela simplifie la programmation globale de l'accès aux données. Vous n'avez pas besoin d'écrire vous-même du code persistant. Cela pourrait générer de nombreuses interactions entre votre couche objet au sein de votre application et le modèle de données dont vous disposez et en utilisant l'accès à la base de données généré par Entity Framework Core.
Il est très populaire pour votre .NET et .NET Core applications. Vous pouvez l'utiliser dans n'importe quel type d'application, c'est-à-dire une application Web, une application serveur typique, .NET ou .NET Core les services Web, les cas d'utilisation IOT ou toute autre application serveur peuvent l'utiliser en raison de sa popularité et aussi de sa facilité d'utilisation. Il est très facile à configurer et vous pouvez commencer avec.
Entity Framework Core est une nouvelle variante. C'est la nouvelle direction que prend Microsoft, c'est avant tout open source, c'est multiplateforme. Ainsi, vous pouvez exécuter une application qui utilise .NET Core ou vous connaissez .NET. Il peut fonctionner sous Windows avec .NET et avec .NET Core il peut fonctionner sur Windows ainsi que sur des environnements Linux et de manière similaire Noyau du cadre d'entité suit le costume, non? Ainsi, il vous permet de fonctionner sur Windows ainsi que sur des environnements Linux si c'est une exigence, puis il est très léger et de nature modulaire. Ce qui signifie essentiellement que vous n'avez pas à parcourir tous les composants d'Entity Framework que vous aviez auparavant. L'EF Core vous permet de travailler avec le composant dont vous avez besoin. Vous ne pouvez obtenir que le package NuGet pour cela et sur cette base, vous pouvez progressivement créer de la complexité au sein de votre application.
Donc, si vous avez besoin, vous savez, de gérer des scénarios complexes au sein de votre application d'ailleurs. Et, en plus, c'est super rapide grâce à .NET Core il y a aussi un objectif spécifique ou un côté performance. Ainsi, Entity Framework Core a été conçu selon les mêmes directives où la performance est l'un des facteurs clés que vous pourriez atteindre.
Schéma d'architecture d'Entity Framework
Voici donc un schéma architectural pour Entity Framework Core.
J'ai trouvé un diagramme Entity Framework qui s'applique toujours, beaucoup de choses s'appliquent également à l'architecture Entity Framework Core. Cela vient de MSDN. Avec EF Core, vous disposez d'un fournisseur de données ADO.NET. J'utiliserai SQL Server comme exemple de source de données, puis vous avez un lecteur de données Entity Client qui crée des arborescences de commandes, un scénario d'accès aux données, puis vous avez des services d'objets et du côté de l'application, vous travaillez soit avec Entity Requête SQL ou LINQ aux Entités. Donc, encore une fois, vous travaillez avec un modèle d'objet et dans les coulisses, Entity Framework Core s'occupe de tous les autres détails.
Il y a une commande que vous exécutez pour générer votre mappage et votre modèle au moment de l'exécution, donc, modèle conceptuel, EDMX, tous ces fichiers de mappage, ils se sont débarrassés de ceux dans Entity Framework Core. Donc, c'est très facile à remettre en place. Encore une fois, c'est modulable. Ainsi, vous pouvez introduire des packages NuGet et créer une application Entity Framework Core très simple en quelques minutes.
Qu'est-ce que l'évolutivité?
Ensuite, je parlerai d'évolutivité, c'est un autre concept que je voulais mettre en avant. Pourquoi avez-vous besoin d'une mise en cache dans une application qui utilise Entity Framework Core ? Tout d'abord, il y a un concept d'évolutivité. C'est une très bonne fonctionnalité dans une application, où vous êtes en mesure d'atteindre des performances d'application élevées et cela aussi sous des charges de pointe, n'est-ce pas ? Donc, si vous pouvez avoir une faible latence et la plus faible latence possible et que vous maintenez cette faible latence sous une faible charge d'utilisateurs, disons cinq à dix utilisateurs et si vous avez une conception d'architecture d'application telle que vous pouvez gérer le même une sorte de faible latence sous une énorme quantité de demandes d'utilisateurs, alors cette application serait classée comme une application très évolutive.
Et, l'évolutivité linéaire est un autre concept associé où vous pouvez ajouter de plus en plus de serveurs et vous pouvez répartir votre charge et en répartissant la charge sur plusieurs serveurs, plus de serveurs augmenteraient en fait la capacité de traitement des demandes et cette augmentation devrait croître de manière linéaire. Donc, si vous avez une application qui augmente sa capacité à mesure que vous ajoutez plus de serveurs et que cela fait une bannière d'augmentation linéaire qui serait classée comme une application évolutive linéairement.
Quelles sont les applications qui ont besoin d'évolutivité ?
Ainsi, généralement les applications qui sont de nature transactionnelle élevée telles que ASP.NET ou ASP.NET Core applications Web, services Web, IOT, applications Big Data ou tout autre .NET général ou .NET Core applications qui utilisent le noyau Entity Framework, elles exigent une évolutivité élevée, n'est-ce pas ? Ils ont donc besoin d'une charge transactionnelle élevée de capacité de traitement au sein de leur architecture.
Où est exactement le problème d'évolutivité ?
Alors, où est le problème exactement ? Pourquoi avez-vous besoin d'un système de mise en cache pour surmonter ce problème ? Vous pouvez toujours créer une ferme Web et une ferme d'applications où l'application Entity Framework Core peut évoluer de manière linéaire sur elle-même en créant une ferme Web ou une ferme d'applications. Vous pouvez mettre un équilibreur de charge devant. Ce n'est donc pas le principal sujet de préoccupation. Votre niveau d'application peut toujours évoluer. C'est ainsi qu'un Entity Framework Core et n'importe quel .NET ou .NET Core les applications sont conçues. Où vous pouvez acheminer les demandes vers plusieurs serveurs et toujours pouvoir les utiliser en combinaison les unes avec les autres.
Le principal problème est votre goulot d'étranglement de stockage de données. Généralement, s'il s'agit d'une base de données relationnelle, c'est l'exemple que nous utilisons. Les bases de données sont généralement une source unique pour tout votre stockage de données. Ils sont très bons pour le stockage. C'est quelque chose qu'ils font le mieux. Mais lorsqu'il s'agit de gérer une quantité extrême de charges de requêtes, par exemple, vous avez beaucoup de charge de données transactionnelles et de référence provenant de vos applications, la base de données n'est pas conçue pour gérer cette quantité accrue de charge de requêtes. Cela fonctionnerait bien sous de faibles charges utilisateur, mais quand il commence à consommer de la capacité côté CPU, côté mémoire, puis il y a un tunnel SGBD où toutes les requêtes sont acheminées. Il y a de fortes chances que votre stockage de données devienne un goulot d'étranglement pour l'évolutivité. Cela vous donnerait une dégradation des performances, où il placerait les demandes de file d'attente qui sont générées au moment de l'exécution. Il n'y a donc aucun moyen d'ajouter un autre serveur de base de données.
Tout d'abord, cela coûte cher au départ et il n'y a aucun moyen d'utiliser deux serveurs en combinaison l'un avec l'autre. Ainsi, cela n'augmenterait pas la valeur des performances, cela dégraderait vos performances et cela aurait également un impact sur votre expérience d'utilisateur final, ce qui pourrait également avoir un impact sur votre entreprise. Parce que, si vos applications ont des performances lentes, beaucoup d'utilisateurs n'apprécieraient pas ce comportement lent ou lent de votre application. Ainsi, les applications ont besoin d'une faible latence et d'un débit élevé tout le temps et le maintien d'un débit élevé entraîne une perte de performances et c'est ce que les bases de données ont tendance à voir lorsqu'elles ralentissent simplement vos applications ou qu'elles ont tendance à s'étouffer complètement dans la plupart des cas également.
La solution
Dans cette section, nous allons parler de la façon de résoudre ce problème. La solution est très simple. Vous pouvez utiliser système de cache distribué par NCache. C'est très rapide car c'est en mémoire. Il est très évolutif car il ne s'agit pas seulement d'une source unique. Vous pouvez avoir autant de serveurs que vous en avez besoin, ajoutés dans le cluster de cache et ces serveurs dans un cluster de cache fonctionnent en combinaison les uns avec les autres. Vous pouvez répartir vos données, puis vous pouvez répartir la charge de traitement des demandes et en ajoutant plus de serveurs, vous obtenez également une plus grande évolutivité du système. Ce n'est pas un remplacement de vos bases de données relationnelles conventionnelles. Vous utilisez un cache distribué dans votre application EF Core en combinaison avec une base de données. Ainsi, soit vous mettez en cache les données les plus facilement accessibles, vos données de référence, soit vous mettez également en cache certaines de vos données transactionnelles.
Et, je parlerai de la façon de gérer différents scénarios de mise en cache, des stratégies de mise en cache que vous pouvez utiliser dans votre application.
Architecture de déploiement
Voici l'architecture de déploiement qui clarifierait davantage certaines choses pour lesquelles il s'agit d'une meilleure option par rapport aux bases de données relationnelles.
Tout d'abord, le cache distribué se situe entre votre application et le niveau base de données. Et, en disant entre les deux, c'est essentiellement votre application qui utilisera d'abord le cache si elle trouve des données ici, elle devrait revenir si elle ne trouve pas de données ici, elle ne devrait ensuite aller qu'à la base de données principale, n'est-ce pas? Ainsi, dans un placement logique, il se situe entre votre application et la base de données.
En ce qui concerne le déploiement, vous pouvez faire déployer votre application sur des machines virtuelles, sur des boîtiers physiques, sur site ou dans le cloud. NCache est pris en charge sur Microsoft Azure, ainsi que sur AWS sous la forme d'une image préconfigurée ou tout autre cloud peut utiliser notre programme d'installation qui peut être téléchargé à partir de notre site Web, puis vous pouvez commencer par l'installation, ce qui est très facile à d'installation. NCache peut être sur son propre niveau respectif, des serveurs dédiés séparés pour NCache ou il peut fonctionner sur les mêmes boîtes. Si vous avez des boîtes où votre application est déployée, vous pouvez déployer NCache également sur le même palier. Nous vous recommandons d'avoir des boîtes séparées et vous pouvez ajouter deux à trois serveurs pour commencer, puis vous pouvez ajouter de plus en plus de serveurs en fonction de vos exigences de traitement des demandes.
Si vous devez gérer, disons, 10,000 4 utilisateurs et la charge de leurs requêtes associées, vous pouvez exécuter des tests et voir de combien de serveurs vous avez besoin. En général, sur la base de tests récents, nous avons pu atteindre deux millions de requêtes par seconde avec seulement 5 à XNUMX NCache serveurs, non ? Ainsi, vous pouvez voir le nombre de serveurs dont vous avez besoin pour gérer les exigences de charge de votre application. Uniquement prérequis pour NCache est soit .NET soit .NET Core. Il fonctionne sur Windows, sur Windows Nano, ainsi que sur des serveurs Linux. De même, vos applications peuvent être sur la plate-forme Windows ou sur la plate-forme Linux.
Et, il existe également de puissantes fonctionnalités de synchronisation de base de données. Comme je l'ai dit plus tôt, ce n'est pas un remplacement de vos bases de données conventionnelles. Il utilise votre base de données, il est utilisé avec votre base de données, n'est-ce pas ? Ainsi, certaines données seraient en cache mais toutes vos données existeraient toujours dans votre magasin permanent qui est votre base de données relationnelle. Et, je vais parler un peu de la façon de mettre en cache.
3 cas d'utilisation de la mise en cache distribuée couramment utilisés
Voici quelques cas d'utilisation courants. Cas d'utilisation généraux pour le cache distribué et le plus important est la mise en cache des données de votre application. Nous avons Entity Framework Core ici.
Mise en cache des données d'application
Ainsi, le premier cas d'utilisation qui est notre cas d'utilisation le plus courant est notre cas d'utilisation de mise en cache des données d'application. Dans ce cas, vous mettez généralement en cache les données qui appartiennent à la base de données. La motivation ici est que vous économisez autant que possible des déplacements coûteux dans la base de données et que vous obtenez des performances élevées pour la récupération de vos données. Parce que les bases de données sont lentes par rapport à l'accès en mémoire, donc c'est en mémoire, donc c'est super rapide et puis vous avez plusieurs serveurs qui hébergent et traitent votre demande depuis votre application. Ainsi, vous obtenez plus d'évolutivité plus de débit hors du système et tout en maintenant une faible latence donnée pour le cache distribué et dans la plupart des cas, il est hautement disponible et fiable en fonction de la topologie que vous avez choisie, contrairement aux bases de données qui peuvent ne pas être répliquées sur d'autres serveurs.
Avec la mise en cache des données de l'application, vous pouvez mettre en cache presque tout. Vous pouvez utiliser des API directes. Vous pouvez mettre en cache vos objets de domaine, collections, ensembles de données, éléments uniques, résultats, quelles que soient les données que vous souhaitez mettre en cache et vous avez à nouveau besoin de ces données, vous devriez envisager d'utiliser notre mise en cache d'objets et avec Entity Framework Core, encore une fois, vous pouvez utiliser des API directes ou une extension méthodes que je vais vous montrer.
Mise en cache de session ASP.NET et SignalR Backplane
Puis un autre cas d'utilisation pour NCache est-ce que c'est ASP.NET et ASP.NET Core cache spécifique. Nous avons notre cache de session. Mise en cache de session dans ASP.NET Core est via IDistributedCache ainsi qu'à notre NCache Fournisseur de session également. Donc, c'est la deuxième option et ensuite nous avons SignalR Backplane. C'est une autre option que vous pouvez utiliser. Si vous avez une application SignalR, vous pouvez utiliser NCache comme fond de panier. Il s'agit à nouveau d'une option sans changement de code, puis nous avons la mise en cache des réponses, l'état de la vue et la mise en cache des sorties. Donc, ce sont toutes les fonctionnalités spécifiques à ASP.NET et en plus de cela, vous pouvez également utiliser la mise en cache des données d'application dans votre application Web si nécessaire.
Messagerie Pub/Sub et requêtes continues
Et puis, nous avons de puissants événements de messagerie Pub/Sub et de requête continue ou, je dirais, de messagerie et d'événements Pub/Sub. Vous pouvez utiliser NCache en tant que plate-forme de messagerie, où plusieurs applications sont connectées et ces applications peuvent communiquer entre elles à l'aide de notre messagerie Pub/Sub. Une application peut publier des messages sur NCache, qui sert de canal de communication. Il a un concept de sujets, puis ces applications d'abonnés peuvent recevoir ce message si elles sont connectées à ce sujet. Ainsi, ils peuvent se coordonner entre eux pour partager des données, ainsi que des messages personnalisés si nécessaire. Et nous pouvons construire des systèmes de médias sociaux. Vous pouvez avoir un système de chat. Vous pouvez avoir des classements. Vous pouvez l'utiliser dans n'importe quel type d'industrie selon vos besoins, où vous devez avoir différents composants de votre application coordonnés les uns avec les autres.
Communication entre microservices
Les microservices sont un autre cas d'utilisation, où vous devez avoir des applications de microservices sans serveur, interagir les unes avec les autres et elles peuvent utiliser NCache pour leurs besoins de communication, puis nous avons également des événements de requête continus. Événements réguliers où vos données sont ajoutées, mises à jour ou supprimées. Au lieu d'envoyer des événements d'application, NCache peut envoyer des événements à vos applications en fonction des modifications de données et cela peut être sur tous les éléments ou sur des éléments sélectifs ou sur la base de la requête continue où vous mappez un ensemble de données dans NCache ainsi que NCache envoie uniquement des événements pour cet ensemble de données spécifié.
Il existe également un quatrième cas d'utilisation. Nous avons la fonction de recherche en texte intégral. C'est très courant dans les applications de commerce électronique. Avec NCache nous avons implémenté l'API Lucene .NET. Donc, si vous êtes intéressé par la fonction de recherche en texte intégral, NCache est également entièrement équipé de cela.
Mise en cache des données d'application dans EF Core
Parlons de la façon dont vous utiliseriez la mise en cache dans une application Entity Framework Core typique.
Configuration de l'exemple d'application
Donc, tout d'abord, j'ai cette application. Exemple d'application aligné ici. C'est l'un des échantillons qui sont installés avec NCache aussi bien. Donc, si vous allez dans C:\Program Files\NCache\, ces échantillons sont disponibles ici.
.NET et .NET Core les échantillons sont placés séparément. Donc, je continuerais avec .NET Core et Entry Framework, nous avons un échantillon EF Core ici. Donc, c'est l'échantillon que j'utilise.
Je l'ai un peu modifié pour illustrer certains de ces scénarios que je prévois de présenter dans ce webinaire. Sinon, il fait le travail de base pour votre POC. Bon, donc, c'est l'échantillon. La prochaine chose que je ferais est de me connecter à notre environnement de démonstration et de commencer par créer un cluster de cache pour vous afin que vous utilisiez réellement un cluster de cache et que vous le preniez à partir de là.
Créer un cache en cluster
Ainsi, pour la création de cache, nous avons notre outil de gestion Web opérationnel. Je vais en créer un rapidement. Alors, allons-y et ajoutons un cache en cluster. Appelons-le démocache. Je vais ajouter quelques entiers, democache111. Vous pouvez d'ailleurs conserver le format JSON ou binaire, en ce qui concerne la sérialisation. Voilà. Ainsi, vous pouvez avoir le format de sérialisation binaire ou JSON. Je vais continuer avec Binary, car c'est l'option par défaut. Vous pouvez choisir parmi quatre topologies de mise en cache et nous avons d'autres webinaires tels que NCache architecture qui sont spécifiquement ciblées pour, vous savez, expliquer NCache architecture. Donc, je vais continuer avec le cache de réplique partitionné car cela fonctionne très bien pour les lectures, très bien pour les écritures et c'est super évolutif pour la capacité de demande de lecture et d'écriture, si vous continuez à ajouter plus de serveurs et qu'il est également équipé de répliques , ainsi, il n'y a pas non plus de temps d'arrêt ni de perte de données pour votre application.
Donc, je garderais tout simple, par défaut. Réplication asynchrone entre la partition active et sa sauvegarde. Donc, je vais choisir ça, c'est plus rapide. Taille du cluster de cache et ici j'ai spécifié les serveurs qui vont héberger mon cluster de cache. Comme je l'ai dit, je vais créer rapidement un cache car notre objectif principal est Entity Framework Core. Sinon, dans nos webinaires réguliers NCache l'architecture ou la mise à l'échelle des applications Azure avec NCache, ces webinaires parlaient de toutes ces fonctionnalités en détail. Donc, dans ce webinaire particulier, je vais juste aller de l'avant et créer rapidement un cache. Bon, donc, je spécifierais le port TCP/IP par défaut et je démarrerais et démarrerais automatiquement ce cache afin qu'il démarre automatiquement lorsque votre serveur est redémarré. Donc, c'est à peu près tout.
Simuler le stress et surveiller les statistiques du cache
En ce qui concerne les configurations de cache, il vous suffit de suivre cet assistant et cela créerait un cache sur plusieurs serveurs. Je pense que ça a commencé aussi. J'ouvrirais la fenêtre des statistiques, puis j'ouvrirais NCache surveiller la fenêtre qui est un autre outil qui est installé avec NCache. Actuellement, il n'y a aucune activité, mais je peux continuer et exécuter une application d'outil de test de stress. C'est ce qu'on appelle l'outil de stress de test et cela simulerait une activité factice, une charge factice sur mon cluster de cache. Juste pour vérifier que tout, il a été configuré correctement. Bon, donc, vous pouvez voir environ, vous savez, bon, mille à quinze cents requêtes par seconde par le serveur un ainsi que par le serveur deux. Ainsi, au total, il traite environ trois mille requêtes par seconde et vous pouvez revoir la latence. Nous avons une latence moyenne très minime en microsecondes par opération de cache. Je pense que c'est quelque part entre, quelque part autour de quatre à cinq microsecondes.
Ainsi, ce graphique serait mis à jour et l'unité diminuerait. Une fois que nous, vous savez, ajoutez un peu plus de charge. Allons de l'avant et faisons cela. À droite. Donc, j'ai une autre instance en cours d'exécution. Juste pour vous montrer que maintenant, il devrait montrer la valeur accrue ici, voilà. Donc, nous avons environ, auparavant, traitions environ quinze cents quêtes par seconde par chaque serveur. Maintenant, c'est entre deux mille et trois mille requêtes par seconde par chaque serveur et vous pouvez voir que la microseconde moyenne par opération de cache est d'environ cinquante à soixante microsecondes par opération. C'est un énorme gain de performances. Considérant que vos applications ne sont pas maximisées ou que les serveurs ne sont pas maximisés du tout. Ainsi, vous pouvez vous attendre à des réponses inférieures à la milliseconde ou à la microseconde de vos applications lors de l'utilisation NCache. Ainsi, notre environnement est configuré. Tout est mis en place. Je pense que nous sommes prêts à partir. Permettez-moi d'arrêter ces tests et de continuer et de créer, passez en revue notre exemple d'application qui parle de scénarios de mise en cache.
Quelles entités EF Core mettre en cache ?
Parlons tout d'abord de la façon de mettre en cache dans Entity Framework Core. Quelles entités EF Core mettre en cache ? Vous avez généralement deux options. Vous pouvez avoir une entité unique ou un résultat de requête, qui est une collection d'entités, n'est-ce pas ? Une seule entité est retournée ou il peut s'agir d'une collection. L'entité unique est stockée telle quelle. La collection peut être stockée en tant qu'élément unique ou chaque élément de collection peut également être ajouté individuellement dans le cache et parlons de la façon de procéder.
Options de mise en cache de l'entité principale EF
direct et gratuit NCache Apis. Il existe deux approches. Tout d'abord, vous pouvez utiliser NCache API directement, n'est-ce pas ? Donc, c'est quelque chose que vous pouvez également utiliser dans Open Source, Enterprise ou Professional. Et puis nous avons Entity Framework Core Extension Methods sur lesquelles je vais passer un peu de temps.
Mise en cache de l'entité unique EF Core : NCache API directes
API directes. Voici un détail des API Direct. Laissez-moi vous montrer ça d'ici, n'est-ce pas ?
Customers GetCustomer (string CustomerId)
{
string key = "Customer:CustomerId:" + CustomerId;
Customers customer = (Customers)_cache.Get(key);
if (customer != null)
{
return customer;
}
else
{
customer = (from cust in database.Customers
where cust.CustomerId == CustomerId
select cust).FirstOrDefault();
_cache.Insert(key, customer);
return customer;
}
}Donc, il s'agit généralement de votre méthode d'obtention du client. Si vous utilisez des API directes, il est probable que vous disposiez d'un identifiant client. Donc, tout d'abord, vous devez construire une clé de cache, n'est-ce pas. Donc, c'est quelque chose que vous devez faire comme un must. Car, à l'intérieur NCache tout est stocké dans une paire clé-valeur. Key est votre clé de chaîne, pour identifier un objet. Une partie d'objet est la valeur réelle, la propriété réelle que vous souhaitez ajouter dans le cache. Données réelles que vous souhaitez mettre en cache pour votre application.
Donc, j'ai mis au point cette organisation clé, où j'ai le client comme mot-clé, puis l'ID client, puis je fournis un paramètre d'exécution qui m'est transmis, n'est-ce pas ? Donc, cela identifierait ce client particulier ici, avec un identifiant client unique, n'est-ce pas ? Ainsi, cela vous permettrait d'identifier ces clients de manière unique, puis d'appeler cache.Get pour récupérer des éléments du cache. À droite? Donc, tout d'abord, si vous utilisez la mise en cache, vous devez vous assurer que la clé est construite, puis vous vérifiez d'abord que les données sont disponibles dans le cache en appelant cache.Get et ce handle de cache est quelque chose qui est renvoyé lorsque vous initialisez le cache, n'est-ce pas ?
Donc, j'utilise ce cache ici, NCache.InitializeCache. Il vous permet d'initialiser le cache et de vous y connecter. Si vous trouvez les éléments dans le cache, ce qui signifie que le client n'était pas nul, vous revenez simplement d'ici. Vous évitez des déplacements coûteux vers la base de données et c'est la principale motivation de l'utilisation du système de mise en cache où NCache aurait vos données. Ainsi, vous économisez vos voyages coûteux via la base de données principale. Vous n'êtes pas obligé d'aller dans la base de données. Mais, puisque c'est la première fois que vous démarrez cette application. Donc, dans ce cas, le cache n'aurait pas les données.
Donc, dans ce cas, vous exécuteriez Entity Framework Core, lien à l'intérieur de Entity Framework Core. Il renverrait soit un élément unique, soit une collection. Il s'agit d'un scénario à élément unique, puis vous appelez cache.Insert pour l'ajouter pour la prochaine utilisation et renvoyer également le client. Ainsi, la prochaine fois, vous trouverez toujours ces données dans le cache tant qu'elles ne sont pas modifiées ou synchronisées avec les données. C'est donc notre utilisation unique des API Entity, Direct.
Mise en cache de la collection d'entités principales EF : NCache API directes
Dans le cas des collections, les API directes sont très similaires.
List GetCustomersByCity (string CustomerCity)
{
string key = "Customers:City = " + CustomerCity;
List custList;
custList = (List)_cache.Get(key);
if (custList != null)
{
return custList;
}
else
{
custList = (from cust in database.Customers
where cust.City == CustomerCity
select cust).ToList();
_cache.Insert(key, custList);
return custList;
}
} Nous avons des clients par ville. La ville des clients est un paramètre d'exécution. Nous allons construire une liste de clients et essayer de récupérer cette liste de collecte à partir de NCache cache.Get, obtenir une liste de clients. Si ce n'est pas un retour nul à partir d'ici, s'il est nul, nous devons le récupérer à partir de la base de données principale et l'ajouter également dans le cache pour la prochaine utilisation. Donc, c'est comme ça et si vous voulez stocker ces éléments de client individuellement, vous pouvez également parcourir cette custList et appeler individuellement cache.Insert en fournissant également des clés uniques pour chaque élément de collection. Donc, c'est une autre option que vous pouvez utiliser.
Mais vous voyez, vous devez d'abord construire une clé, obtenir l'élément du cache. S'il est là, effectuez la gestion des valeurs nulles, puis s'il n'y est pas, vous l'obtenez de la base de données, exécutez la logique de données, puis ajoutez-la également. Donc, c'est quelque chose que vous devez faire avec Direct NCache Apis. C'est le cas d'utilisation le plus courant pour toute mise en cache de base de données typique. Pour la mise en cache des données d'application, c'est ce que vous feriez normalement.
Mise en cache de l'entité unique EF Core - Méthodes d'extension EF Core
Mais il y a une autre approche, c'est à travers nos méthodes d'extension et c'est le principal point fort. Vous pouvez mettre en cache toute la collection en tant qu'élément unique ou encore mettre en cache chaque élément de collection séparément, mais via des méthodes d'extension.
Customers GetCustomer (string CustomerId)
{
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs.SeperateEntities
};
Customers customer = (from cust in database.Customers
where cust.CustomerId == CustomerId
select cust).FromCache(out string cacheKey,
options).FirstOrDefault();
return customer;
} Voici notre première méthode d'extension que je veux vous montrer. D'accord, ça s'appelle From Cache mais ça fait beaucoup d'automatisation pour vous, c'est vrai. Cela fonctionne de telle manière que tout d'abord cela vous permet de construire des options de mise en cache, n'est-ce pas ? Donc, vous créez d'abord des options de mise en cache et l'un des attributs que je présente à ce stade est Store As. Alors, NCache vous permettrait de choisir si une collection doit être stockée en tant qu'élément unique, en tant qu'éléments individuels, éléments de collection. Disons qu'il y avait 10 objets dans la collection. Ainsi, ceux-ci seraient ajoutés en tant que 10 éléments distincts dans NCache ou vous voulez le stocker comme une collection qui se trouve ici, n'est-ce pas ? Donc, c'est la deuxième option. Dans ce cas, il serait stocké comme un élément dans le cache.
Donc, j'utilise des entités distinctes. Donc, si j'exécute ce code ici, j'ai une méthode d'extension qui dit From Cache et si je vous montre la définition de cela, cela vient de NCache Alachisoft .NCache.EntityFrameworkCore. C'est l'espace de noms principal et si je viens ici et que je vous montre les packages NuGet. Sous Installé, nous avons Alachisoft .NCache.EFCore NuGet package. C'est donc le package NuGet que vous devez introduire et après cela, vous pouvez commencer avec ces méthodes d'extension. Tout d'abord, c'est une clé de cache de référence, donc, la clé de cache va être générée par NCache et vous est donné. Donc, c'est la flexibilité et ensuite il prend juste les options comme paramètre, d'accord. Donc, il fait beaucoup d'automatisation et dans les coulisses, il fait beaucoup de travail pour vous. FromCache fonctionne de telle manière qu'il vérifie d'abord automatiquement les données dans le cache, c'est le comportement, s'il trouve, il ne va pas dans la base de données.
Mais, s'il n'est pas dans le cache, il ira en règle générale dans la base de données et exécutera la requête, le jeu de résultats sera récupéré puis ajouté dans le cache à l'aide de cette clé de cache remplie, puis ces options de mise en cache seront configurées pour cet élément. . Donc, si vous le comparez à celui-ci, vous n'avez pas besoin de construire la clé de cache. Vous n'avez pas à vérifier vous-même la gestion des valeurs nulles ou l'obtention du cache. Vous n'êtes pas obligé de l'insérer dans le cache. Il vous suffit d'utiliser cette méthode d'extension. Donc, cela rend beaucoup de choses automatisées et son modèle de programmation très simplifié pour vos applications également.
Mise en cache de la collection d'entités EF Core : méthodes d'extension EF Core
Et, même cas où vous voudriez le stocker en tant que collection, vous fournissez simplement les options de mise en cache à collectionner et dans ce cas, vous avez une liste de clients que vous renverriez. Donc, vous exécutez simplement la requête, puis appelez à nouveau FromCache. Donc, cela termine notre première méthode d'extension et son introduction.
List GetCustomersByCity (string CustomerCity)
{
List custList;
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs.Collection
};
custList = (from cust in database.Customers
where cust.City == CustomerCity
select cust).FromCache(out string cacheKey,
options).ToList();
return custList;
} Quelles données mettre en cache dans EF Core ?
Ensuite, je parlerai des données de référence et transactionnelles. C'est le segment principal.
Vous auriez affaire à des applications qui ont beaucoup de lectures, des données avec beaucoup de lectures que d'écritures, puis il pourrait y avoir des scénarios d'applications où nous avons des lectures ainsi que des écritures, n'est-ce pas ? Ainsi, par exemple, les produits de données de recherche, les employés, qui ne changent pas aussi souvent mais ce ne sont pas des données statiques, c'est quelque chose qui change mais la fréquence des changements n'est pas si grande et des données entières devraient exister dans le cache. Dans ce scénario particulier, je vais vous expliquer pourquoi et vous devriez expirer après quelques heures ou quelques jours. Voilà comment garder le cache frais, c'est un autre segment.
Ensuite, nous avons des données transactionnelles. Je vais parler de la façon de gérer la mise en cache des données transactionnelles. Il est créé dynamiquement. Commandes, comptes, ce sont des exemples. Il change très fréquemment et, historiquement, les données transactionnelles n'étaient pas préférées pour la mise en cache. Parce qu'il était censé changer et était censé s'éloigner de votre application pendant que votre utilisateur est actif, il n'est nécessaire qu'à ce stade. Mais sur la base de notre expérience, nous vous recommandons vivement d'activer également la mise en cache pour les données transactionnelles. Parce que, même si vous ne le modifiez pas, les données sont toujours actives, vous pouvez les lire plusieurs fois et si vous avez des millions d'utilisateurs connectés, cela entraînerait des millions de demandes pour que ces données retournent à la base de données et si il est mis en cache et même s'il peut y avoir deux à trois requêtes alors que cela va changer, cela sera toujours bénéfique du point de vue des performances. Nous vous recommandons donc fortement d'envisager de mettre en cache une partie de vos transactions, sinon toutes.
Mise en cache des données de référence dans EF Core
D'accord, comment gérer la mise en cache des données de référence dans EF Core ?
J'ai un processus en deux étapes pour cela. Vous pouvez charger des données entières dans le cache, c'est un must. Ainsi, toutes vos données de référence doivent être chargées dans le cache, c'est ce que nous recommandons comme un must. Pourquoi? Parce que vous ne voulez pas du tout accéder à la base de données, n'est-ce pas ? Vous devriez continuer et commencer à charger toutes vos données à partir de la base de données dans NCache et nous avons une méthode d'extension qui s'occuperait de cela tout de suite, puis n'utiliserait que le cache et éviterait les déplacements de la base de données.
La deuxième étape est toujours le cache en tant qu'entités distinctes. C'est un autre conseil que je vous donnerais pour ne pas mettre en cache tous les produits ou tout autre, tous les produits en tant que collection, n'est-ce pas ? Il peut s'agir de milliers de produits ou de millions de produits. Mais les stocker individuellement vous permettrait de récupérer des sous-ensembles de données ultérieurement, n'est-ce pas. Ainsi, par exemple, vous chargez tous les produits, mais ultérieurement à partir du cache, vous n'avez besoin que des produits abandonnés. Donc, si vous les avez stockés individuellement dans le cache, disons, soixante mille produits, c'est l'exemple que je vais vous montrer. Vous ne pouvez trouver que ceux dont vous avez besoin à ce stade. Ainsi, vous n'avez pas besoin de traiter l'intégralité de l'ensemble de données produit et d'économiser encore une fois des déplacements coûteux vers la base de données.
Mise en cache des données de référence dans EF Core : cache de préchargementDonc, nous avons une méthode d'extension appelée LoadIntoCache, c'est la prochaine fois que je vais vous montrer et je vais également vous montrer un exemple concret de cela.
void LoadAllProducts (NorthwindContext database)
{
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs.SeperateEntities,
};
// Loads all products into cache as individual entities
var res = (from products in database.Products select
products).LoadIntoCache(options).ToList();
}
Maintenant, LoadIntoCache, tout d'abord, les options de mise en cache doivent être définies sur "stocker en tant qu'entités séparées", puis vous devez exécuter une requête qui doit charger tous les produits, puis vous devez appeler LoadIntoCache, puis fournir les options et encore une fois, il créerait simplement des clés de cache pour tous ceux individuellement, automatiquement. Et, il continuerait à charger tous ces éléments dans le cache, puis vous pouvez exécuter des requêtes LINQ comme celle-ci et cette requête LINQ est contre NCache. Il n'utilise aucune méthode d'extension. Il appelle product dans les produits de base de données où product.Discontinued et nous n'avons que FromCache. Il ne va pas du tout dans la base de données. Il l'obtient de NCache directement.
Mise en cache des données de référence dans EF Core : rechercher les données de référence dans le cache uniquementSi vous avez des données de référence, vous devez d'abord charger des entités distinctes. Utilisez load into cache pour charger tous les produits dans NCache. Une fois que vous avez fait cela, vous n'avez pas besoin d'aller dans la base de données. Ensuite, vous utilisez FromCacheOnly au lieu de FromCache. La première méthode d'extension était FromCache qui vérifie dans le cache puis va dans la base de données si elle n'est pas dans le cache. Mais, LoadIntoCache chargerait tous les produits, puis FromCacheOnly s'assurerait qu'il ne parle qu'au cache en supposant que toutes les données sont chargées dans le cache.
List<Products> FindDiscontinuedProducts (NorthwindContext database)
{
//Fetch discontinued products only out of all products
List<Products> discontinuedProducts;
discontinuedProducts = (from product in database.Products
where product.Discontinued == true
select product).FromCacheOnly().ToList();
return discontinuedProducts;
}Permettez-moi d'exécuter ce code, afin que vous le voyiez en action. J'ai un cache qui est configuré ici pour ce test et je vais vous montrer des statistiques. J'ai joué avec. 60,000 XNUMX produits sont chargés. Alors, laissez-moi juste aller de l'avant et effacer le contenu. Bon, alors, passons en revue les statistiques. Où est ma cache ? Voilà. Bon, donc, c'est zéro élément et ensuite je vais continuer et exécuter ça. Cela mettrait simplement en cache l'élément unique, puis rassemblerait tous les exemples de code que je vous ai montrés, mais je voudrais vous montrer comment fonctionne LoadIntoCache et sur cette base, je mettrai également un point d'arrêt là-bas.
Ainsi, les deux premiers exemples chargeaient un seul élément, puis chargeaient une collection, le code initial que je vous avais montré, puis celui-ci chargeait en fait tous les produits pour vous montrer le scénario de données de référence. Tout d'abord, il stocke en tant qu'entités distinctes et établit certaines priorités, certaines dépendances, il est élaboré en termes de cela, puis il va continuer et charger tous les produits, en les obtenant de la base de données et je vous recommande fortement de continuer à courir charger le produit, chargé dans le cache après quelques intervalles, de sorte que vous ayez des données extraites de la base de données et que le chargement dans le cache fonctionne toujours par rapport à la base de données. Il va toujours aller à la base de données et tout ce que vous avez dans la base de données, il va être exécuté sur la base de données et récupérer ces données dans NCache puis utilisez FromCacheOnly par la suite.
C'est ainsi que vous traitez les données de référence. Tout d'abord, vous les stockez individuellement, séparément. LoadIntoCache, en utilisant cette méthode d'extension LoadIntoCache, qui s'exécute toujours sur la base de données. Il n'a pas de cache en priorité. Il s'exécuterait toujours sur la base de données, puis récupérerait tout dans NCache puis utilisez FromCacheOnly. C'est aussi simple que ça.
Mise en cache des données transactionnelles dans EF Core
Données transactionnelles. Vous ne pouvez charger que le jeu de travail. C'est pour la mise en cache de l'ensemble de résultats, n'est-ce pas ?
Personnellement, je recommande que si vous êtes intéressé par les clients par ville, les commandes basées sur un produit, vous devriez avoir une sorte de mise en cache de l'ensemble de résultats et c'est ce que vous devriez faire. Vous devez les stocker en tant que collection ou entités distinctes en fonction de la taille des résultats, que si une collection n'est pas si grande, disons qu'elle traite de 100 ou 200 éléments au maximum, stockez-les en tant que collection, et mais s'il y en a sont plusieurs produits, plusieurs commandes ou informations clients, qui seraient classés comme des données transactionnelles. Stockez-les en tant qu'entité distincte. Ainsi, vous pouvez en tirer un sous-ensemble et maximiser votre utilisation de la mise en cache.
Mise en cache des données transactionnelles dans EF Core - Récupérer et mettre en cache en tant que collectionLe cas d'utilisation pour cela est à nouveau très simple. Vous le stockez simplement en tant que collection ou utilisez FromCache, vous n'utilisez pas FromCacheOnly car vous souhaitez accéder à la base de données si elle n'est pas dans le cache.
List<Orders> GetCustomerOrders (string CustomerID)
{
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs = StoreAs.Collection,
};
//Fetch from cache. If not found then fetch from DB.
orderList = (from customerOrder in database.Orders
where customerOrder.Customer.CustomerId==CustomerID
select customerOrder)
.FromCache(out string cacheKey, options).ToList();
return orderList;
}List<Orders> GetCustomerOrders (string CustomerID)
{
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs.SeperateEntities
};
//Fetch from cache. If not found then fetch from DB.
orderList = (from customerOrder in database.Orders
where customerOrder.Customer.CustomerId==CustomerID
select customerOrder)
.FromCache(out string cacheKey, options).ToList();
return orderList;
}Jusqu'à présent, nous avons introduit trois méthodes d'extension. FromCache qui fonctionne automatiquement avec le cache et la base de données et non dans le cache, vous l'obtiendriez de la base de données. LoadIntoCache s'exécuterait toujours sur la base de données. Récupérez des objets et amenez-les dans le cache et FromCacheOnly s'exécute toujours sur le cache et c'est la seule véritable source de données. Il n'irait pas dans la base de données. Donc, j'espère que cela clarifie beaucoup de choses.
Garder le cache à jour
Le segment suivant est basé sur la façon de garder le cache frais dans Entity Framework Core et c'est un autre concept important que vous devez comprendre lorsque vous traitez avec deux sources différentes.
Vous avez activé la mise en cache. Vous avez une base de données principale qui est votre principale source de données, un magasin de données persistant, puis vous avez une mise en cache qui contient également une copie des données. Alors, comment s'assurer que le cache est frais par rapport à la base de données. Alors, passons un peu de temps ici.
Gardez le cache à jour : données de référence
Tout d'abord, vous devriez, puisque vous avez un ensemble de données complet dans le cache, que se passe-t-il s'il y a un changement dans la base de données, n'est-ce pas ?
Donc, vous devez faire expirer les données du cache et pour cela, nous vous recommandons d'utiliser l'expiration, puis le rechargement automatique des données, cela pourrait être une option. Donc, la première stratégie consiste à utiliser l'expiration mais sans recharger. Ainsi, chaque fois que les données expirent, elles sont également rechargées automatiquement dans le cache et pour cela, nous avons cette configuration ici, Charger tous les produits.
Stratégie 1 : Utiliser l'expiration mais avec le rechargement automatiquevoid LoadAllProducts (NorthwindContext database)
{
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs.SeperateEntities,
};
options.SetAbsoluteExpiration(DateTime.Now.AddHours(10));
options.SetResyncProviderName("MyEFCoreResyncProvider");
// Load all products into cache with Expiration and Auto-Reload
var res = (from products in database.Products select
products).LoadIntoCache(options).ToList();
}Laissez-moi juste vous montrer ça d'ici, d'accord. Donc, tout d'abord, vous les stockez en tant qu'entités distinctes car c'est le cas d'utilisation des données de référence. Vous les chargez comme tous les produits, puis vous configurez une sorte d'expiration, puis options.SetResyncProvider, il devrait y avoir un fournisseur de rechargement, puis configurez options.IsSyncEnabled sur true. Donc, rechargement automatique, pour qu'il soit automatiquement rechargé dans le cache au cas où il expirerait, d'accord. Donc, ce sont les deux propriétés avec, si vous SetResyncProviderName qui définirait automatiquement l'indicateur de rechargement automatique sur true.
namespace Alachisoft.NCache.EFSampleResyncProvider
{
public abstract class EFDefaultResyncProvider : IReadThruProvider
{
public virtual void Init(IDictionary parameters, string cacheId)
{
db = InitializedDbContext();
}
public virtual void LoadFromSource(string key, out
ProviderCacheItem cacheItem)
{
cacheItem = new ProviderCacheItem(FetchItemFromDb(key));
cacheItem.AbsoluteExpiration = DateTime.Now.AddHours(10);
cacheItem.ResyncItemOnExpiration = true;
}
public virtual void Dispose()
{
db.Dispose();
}
}
}Et, ensuite, vous avez besoin de ResyncProvider ici, c'est-à-dire que notre exemple d'implémentation est ici que je montre.
namespace Alachisoft.NCache.EFSampleResyncProvider.Provider
{
public class EFResncProvider : EFDefaultResyncProvider,
IReadThruProvider
{
public override DbContext InitializedDbContext()
{
return new NorthwindContext();
}
}
}Voilà. Vous devez implémenter notre IReadThruProvider. Initialisez votre source de données, disposez-la à la fin, puis vous LoadFromSource vous permet d'obtenir la clé et sur la base de cette clé, vous construisez une commande SQL et récupérez les éléments de la base de données et j'ai donné un exemple d'implémentation ici où nous construisons un Requête SQL à partir de la clé de cache que nous avons.
Bon, donc, cette clé, dans cet exemple d'implémentation, est également disponible sur GitHub. Ainsi, cela fonctionnera de telle manière que vos éléments qui sont chargés dans le cache, si je lance le chargement dans le cache une fois de plus, ils auront une date d'expiration attachée. Ainsi, ils expireraient après cinq à dix heures, quelle que soit la période d'expiration et après cela, ce fournisseur entrerait en action et appellerait LoadFromSource en utilisant automatiquement le gestionnaire de lecture et les données mises à jour sont apportées à NCache. D'accord, donc votre cache sera automatiquement actualisé après l'expiration des éléments.
Stratégie 2 : ne pas utiliser l'expiration, recharger manuellementLa deuxième approche que je recommande personnellement est de ne pas utiliser d'expression, de recharger manuellement en appelant LoadIntoCache. Et, c'est quelque chose de très simple que vous devriez trouver avec cette méthode LoadIntoCache, si je vous montre une fois de plus. Continuez à appeler cette méthode après quelques intervalles et n'utilisez aucune expression. Débarrassons-nous de ceux-ci.
void LoadAllProducts (NorthwindContext database)
{
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs.SeperateEntities,
};
var res = (from products in database.Products select
products).LoadIntoCache(options).ToList();
}Donc, vous savez que ce seront les données de référence qui ne sont valables que pour, disons, une heure, deux heures, cinq jours, une semaine, un mois. Sur cette base, continuez à répéter cette charge tous les produits. Cela devrait être appelé après quelques intervalles, non ?
Donc, c'est l'idée que vous devriez recharger les données manuellement en fonction d'une estimation intelligente faite sur l'intervalle d'expiration, n'est-ce pas ? Ainsi, vous devez définir le temps de travail, après quoi vous devez automatiquement appeler charger tous les produits. Ainsi, il obtient automatiquement les données de la base de données principale et vos données de référence sont conservées à jour.
Donc, je vais les réitérer. Donc, il y a deux options. Si vous utilisez des données d'expiration, elles seront supprimées du cache. Ainsi, vous vous retrouveriez avec des ensembles partiels, vous avez donc besoin d'un rechargement automatique indispensable. Mais, si vous n'utilisez pas l'expiration, vous auriez toutes les données dans le cache tout le temps pour les données de référence, puis vous pouvez recharger manuellement ces données après certains intervalles. J'espère que cela clarifie.
Gardez le cache à jour : données transactionnelles
Ensuite, je parlerais de la mise à jour du cache pour les données transactionnelles et c'est assez simple. Vous devez toujours utiliser une expiration courte sans rechargement automatique. Parce qu'il s'agit encore une fois de données de courte durée qui ne peuvent être valides que pendant cinq à dix minutes et vous devez utiliser FromCache, de sorte que si elles ne se trouvent pas dans le cache, vous devez toujours les obtenir à partir de la base de données principale.
Et, en voici un exemple, où nous avons des commandes de clients, les stockons sous forme de collection ou d'articles individuels, cela dépend entièrement de vous. Courte expiration si nécessaire ou n'utilisez pas d'expiration, ou utilisez l'expiration et n'utilisez pas de rechargement automatique d'ailleurs. Pour qu'il soit récupéré de la base de données dès qu'il est expiré. Personnellement, je recommande d'utiliser une expiration configurable ou de proposer l'expiration dont vous savez avec certitude qu'il s'agit d'un temps de travail pour cet ensemble de données. Alors qu'après cela, il ne serait pas nécessaire. Ainsi, il devrait expirer automatiquement, puis à ce stade, vous imposeriez un accès à la base de données et vous l'obtiendriez automatiquement à partir de la base de données principale.
Courte expiration, pas de rechargement automatique private List<Orders> GetCustomerOrders (string CustomerID)
{
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs = StoreAs.Collection
};
options.SetAbsoluteExpiration(DateTime.Now.AddSeconds(60));
List<Orders> orderList = (from customerOrder in database.Orders
where customerOrder.Customer.CustomerId==CustomerID
select customerOrder).FromCache(out string cacheKey,
options).ToList();
return orderList;
}Nous avons donc expliqué comment gérer les données de référence, ainsi que les données transactionnelles. Ensuite, nous avons également expliqué comment garder le cache à jour pour référence, ainsi que les données transactionnelles.
Gestion des relations dans le cache
Un-à-plusieurs
Quelques autres choses que vous pouvez rencontrer avec la mise en cache. Gestion des relations dans le cache pour EF Core. Encore une fois, c'est très simple. L'inclusion est prise en charge, donc si vous avez une région avec des régions de base de données et que vous obtenez ensuite region.Territories à côté d'eux, n'est-ce pas ? Ainsi, vous pouvez appeler FromCache et il stockerait les régions séparément et les territoires séparément et ils formuleraient une relation entre la région et les territoires. Donc, si je vous montre une région avec des territoires.
List<Region> GetRegionWithTerritories(NorthwindContext database)
{
List<Region> regionDetails;
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs.SeperateEntities
};
regionDetails = (from region in database.Region select region)
.Include(region => region.Territories)
.FromCache(options).ToList();
return regionDetails;
}C'est un exemple ici. À droite. Ainsi, les détails de cette région incluent, puis nous utilisons FromCache. Ainsi, nous stockerons les régions ainsi que les territoires de région séparément, nous séparerons les éléments, puis nous construirons une dépendance basée sur une clé. Si les régions subissent un changement, les territoires seront également invalidés et vice versa. C'est ainsi que vous géreriez les relations un à un ou un à plusieurs.
Mise en cache des opérations d'agrégation
Les opérations d'agrégation sont également prises en charge. Ainsi, vous pouvez exécuter ces méthodes d'extension avec un premier différé ou par défaut, FromCache. Il peut être basé sur Deferred Count, FromCache. Donc, il les stockerait en tant qu'ensemble de résultats, n'est-ce pas ? Ainsi, peu importe si vous les stockez sous forme de collection ou d'éléments uniques, car il ne s'agit que du résultat d'opérations agrégées. C'est donc une autre possibilité avec notre Entity Framework.
Mise en cache des opérations d'agrégat - Entités renvoyées
Shippers GetFirstShipperInstance (NorthwindContext database)
{
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs.Collection
};
Shippers shipper = database.Shippers.DeferredFirstOrDefault()
.FromCache(out string cacheKey, options);
return shipper;
}Mise en cache des opérations d'agrégat - Valeurs renvoyées
int GetTotalShippersCount (NorthwindContext database)
{
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs.Collection
};
int count = database.Shippers.DeferredCount()
.FromCache(out string cacheKey, options);
return count;
}Architecture de mise en cache distribuée
Donc, vers la fin, je voudrais parler de quelques détails architecturaux sur la mise en cache distribuée. Pourquoi devriez-vous l'envisager. C'est hautement disponible, c'est super fiable, avec réplication. C'est un cache architecturé peer-to-peer. Il n'y a pas de point de défaillance unique. Vous pouvez ajouter ou supprimer n'importe quel serveur au moment de l'exécution et les clients bénéficient d'une prise en charge du basculement de connexion. Il est donc hautement disponible et super fiable avec une disponibilité de 100 %. Il est livré avec de nombreuses topologies de mise en cache, un cache client, une réplication WAN, des répliques partitionnées et partitionnées et je peux spécifiquement parler des détails architecturaux s'il y a des questions, sinon à ce stade, cela conclut notre présentation.
Haute Disponibilité
Topologies de mise en cache
Cache client (près du cache)
Réplication WAN du cache
Conclusion
J'aimerais en faire un bref résumé. Dans ce webinaire, nous avons parlé des options de mise en cache, des API directes, des méthodes d'extension Entity Framework Core. Nous avons donc la possibilité de choisir entre ceux-ci. Nous nous sommes davantage concentrés sur les méthodes d'extension Entity Framework Core car c'est ce que nous aimerions projeter. C'est plus facile à utiliser. Comment aborder les données de référence et transactionnelles. Nous avons donc parlé d'approches consistant à charger des données entières pour les données de référence, puis à utiliser une approche d'entités distinctes, puis à utiliser le cache uniquement pour toutes les données que vous avez dans le cache. Pour les données transactionnelles, nous vous recommandons de ne mettre en cache que le jeu de résultats, puis d'utiliser la méthode d'extension FromCache afin de pouvoir accéder à la base de données si elle ne se trouve pas dans le cache. Et puis, pour garder le cache frais, nous avons dit que vous devriez utiliser l'expiration avec rechargement automatique pour les données de référence ou ne pas utiliser l'expiration mais recharger manuellement après certains intervalles et pour les données transactionnelles, assurez-vous d'utiliser l'expiration, n'est-ce pas ? Cela devrait être une courte expiration mais sans rechargement automatique, vous pouvez donc revenir à la base de données et actualiser votre cache lors de la prochaine utilisation.
Vous pouvez toujours nous joindre au support@alachisoft.com. Si vous avez des questions techniques, vous pouvez également nous joindre au sales@alachisoft.com. Si vous souhaitez jeter un œil au produit, vous pouvez télécharger NCache Enterprise pour un essai gratuit de 30 jours.