Utilisation de la mise en cache .NET dans EF Core via les méthodes d'extension
Webinaire enregistré
Ron Hussain et Nick Zulfiqar
Entity Framework (EF) Core est la nouvelle version multiplateforme et légère du populaire Entity Framework de Microsoft. EF Core est un moteur de mappage objet-relationnel pour .NET qui élimine le besoin de la plupart du code d'accès aux données que les développeurs écrivent autrement.
EF Core est de plus en plus utilisé dans les applications serveur à transactions élevées (ASP.NET, WCF et autres applications serveur .NET). Et ces applications ont besoin d'évolutivité pour gérer un grand nombre de demandes d'utilisateurs sans ralentir. Mais, la base de données devient un goulot d'étranglement et la mise en cache distribuée doit être utilisée pour éliminer ce goulot d'étranglement.
Apprenez à utiliser le cache distribué comme NCache dans votre Applications de base EF pour supprimer les goulots d'étranglement de l'évolutivité de la base de données.
Ce webinaire couvrira (y compris des exemples de sources pratiques :
- Introduction à EF Core et ses nouvelles fonctionnalités (Modèle, Requête, Enregistrement des données)
- Goulots d'étranglement de l'évolutivité de la base de données dans EF Core et comment le cache distribué les résout
- Diverses options d'utilisation NCache dans EF Core (API directes et méthodes d'extension EF Core)
- Détails de l'utilisation des méthodes d'extension EF Core pour la mise en cache
- Comment gérer la mise en cache des collections et des relations pour les données de référence et transactionnelles ?
- Certaines caractéristiques importantes d'un bon cache distribué comme NCache
EF Core est un moteur de mappage relationnel d'objets pour .NET et .NET Core applications. Cela permet aux développeurs de générer automatiquement le code d'accès aux données, normalement ils devraient écrire ce code eux-mêmes. Semblable à .NET Core, EF Core est également multiplateforme et je veux dire que vous pouvez l'exécuter sur Windows, Linux, Mac et il devient très populaire auprès de la communauté des développeurs.
Dans ce webinaire, nous parlerons des besoins en performances et en évolutivité dans les applications EF Core et démontrerons différentes stratégies pour mettre en cache les données de référence et transactionnelles à l'aide des méthodes d'extension EF Core. Quels sont les défis de performances et d'évolutivité auxquels vous seriez confrontés dans une application EF Core typique, puis nous parlerons des différentes options d'utilisation de la mise en cache dans Entity Framework Core Applications.
Je me concentrerai principalement sur les méthodes d'extension, les méthodes d'extension EF que nous avons implémentées pour les applications Entity Framework Core. Je vais donc passer en revue toutes les méthodes d'extension de base d'Entity Framework de NCache puis nous parlerons des différentes stratégies pour gérer les données de référence et les données transactionnelles comme l'a suggéré Nick. Nous verrons également comment synchroniser les données lorsque les données existent à deux endroits différents lorsque vous commencez à utiliser un cache distribué. C'est donc ce que nous avons à l'ordre du jour du webinaire d'aujourd'hui. Je vais rapidement commencer. Nous avons beaucoup à couvrir. Il y a beaucoup d'exemples pratiques que je veux présenter. Alors, commençons rapidement.
Qu'est-ce qu'Entity Framework / EF Core ?
Ainsi, la première diapositive est davantage une introduction à Entity Framework et EF Core.
EF et EF Core, il s'agit d'un moteur de mappage relationnel d'objets pour .NET et .NET core applications. La dernière version d'Entity Framework est nommée EF Core. Vous savez, nous avons récemment vu la sortie d'EF Core 2.1 avec .NET Core 2.1. Vous savez, cela simplifie la programmation de votre base de données. Vous savez, cela vous permet de générer automatiquement votre modèle d'accès aux données. Donc, vous n'avez pas à l'écrire vous-même. Cela réduit l'effort de développement nécessaire pour cela. Vous n'avez pas besoin d'écrire du code de persistance que vous écrivez généralement vous-même au niveau ADO.NET, puis vous devez avoir un mappage entre votre modèle de données et le modèle objet. Donc, il optimise simplement cela pour vous.
Donc, c'est très souple. Il devient très populaire auprès de la communauté des développeurs et de sa plate-forme croisée et il est très populaire dans .NET et .NET Core Applications, en particulier les applications transactionnelles élevées qui traitent beaucoup de demandes.
Schéma d'architecture d'Entity Framework
Il s'agit d'un schéma d'architecture d'Entity Framework.
Vous savez, cela s'applique également sur EF Core. Il existe peu de différences entre EF et EF Core. EF Core est léger. Il a une approche modulaire. Il n'y en a pas beaucoup, vous n'avez pas à passer par l'installation complète. Vous pouvez avoir une approche modulaire. Ils l'ont décomposé en packages plus petits, vous pouvez donc travailler avec le package qui vous intéresse.
Ainsi, vous n'avez pas besoin de passer par une installation complète d'ailleurs et ils se sont également débarrassés de .edmx et de ces fichiers de mappage. Donc, avec vous le savez, les packages NuGet et certaines commandes que vous exécutez et qui génèrent le modèle pour vous, puis vous travaillez simplement avec les API LINQ to Entities sur la couche application et l'approche globale reste la même.
Qu'est-ce que l'évolutivité?
En règle générale, dans une application EF Core que vous connaissez, nous parlerons des exigences de performances et d'évolutivité. L'évolutivité est une capacité au sein d'une application qui vous permet d'augmenter le nombre de demandes que cette application doit gérer. Par exemple, votre charge d'utilisateurs augmente ou les utilisateurs qui contribuent à la charge des demandes, cette charge de demande augmente au sein d'une application et si votre application ralentit, cette application n'est pas évolutive.
Ainsi, des performances élevées sous des charges de pointe, c'est ce que nous qualifions d'évolutivité. Si votre application fonctionne assez bien, en moins d'une milliseconde, avec une latence inférieure à cinq utilisateurs, elle devrait avoir le même type de performances, le même type de latence, une faible latence sous, disons, cinq mille utilisateurs ou cinq cent mille utilisateurs et beaucoup de la charge de la demande.
Ainsi, des performances élevées sous une charge de stress élevée, sous des charges de pointe, c'est ce que nous qualifions d'évolutivité. EF Core.
Quelles sont les applications qui ont besoin d'évolutivité ?
Il peut s'agir d'une application Web ASP.NET. ASP.NET ou ASP.NET Core qui peut traiter un grand nombre de demandes. Il peut s'agir de .NET et .NET Core services Web, toujours sur le site Web. Ensuite, nous avons les applications serveur IoT. Encore une fois, il pourrait s'agir de .NET ou .NET Core ou tout autre .NET général et .NET Core Les applications qui peuvent traiter un grand nombre de demandes ou d'utilisateurs dans leurs propres domaines.
Ce sont donc les candidats à l'évolutivité.
Où est exactement le problème d'évolutivité ?
En règle générale, EF et EF Core sont déployés sur une batterie de serveurs Web. S'il s'agit d'une application Web, elles évoluent de manière linéaire. Vous n'avez aucun problème d'évolutivité au niveau de l'application, mais ils doivent toujours communiquer avec une source de données relationnelle principale. Il pourrait s'agir d'un serveur SQL. Il peut s'agir d'Oracle Server ou de tout autre stockage de données pris en charge par EF ou EF Core. Dans EF Core, ils ont beaucoup de fournisseurs de données. Vous pouvez choisir parmi une liste de fournisseurs. Donc, vous finissez par parler à une base de données.
Bien que votre niveau d'application évolue bien, mais ce stockage de données, la base de données, la base de données relationnelle devient une source de conflit. Il est lent à démarrer car il n'est pas en mémoire. Bien qu'EF Core ait mis au point un fournisseur de données en mémoire, il s'agit d'un InProc, d'un magasin et c'est pour les tests locaux. Cela facilite vos tests, mais une fois votre application déployée en production, vous devez gérer une base de données relationnelle qui est lente et qui n'évolue pas. C'est très bon pour le stockage, mais il n'évolue pas lorsque vous avez réellement besoin de cette évolutivité dans votre application.
Il s'agit donc d'une source unique qui peut s'étouffer sous des charges extrêmes.
La solution
La solution est très simple : vous commencez à utiliser un système de mise en cache perturbé comme NCache, pour votre application principale EF, vous l'utilisez en combinaison avec une base de données relationnelle.
Architecture de déploiement
Voici l'architecture de déploiement de NCache.
Tout d'abord, c'est en mémoire. Donc, c'est super rapide en comparaison. Ensuite, vous avez plusieurs serveurs qui stockent les données qui vous permettent généralement d'extraire de la source de données relationnelle principale. Vous pouvez le mettre dans le cache et il pourrait s'agir de votre ASP.NET ou ASP.NET Core Apps, .NET ou .NET, Web Services ou il pourrait s'agir de .NET ou .NET Core Applications serveur ou tout type de .NET ou .NET Core Les applications ou même les applications Java peuvent tirer parti de ce système de mise en cache distribué. Cela évite vos déplacements coûteux vers les sources de données relationnelles. C'est en mémoire. Vous pouvez ajouter plus de serveurs et augmenter la capacité de ce cluster de cache de manière linéaire.
Il ne s'agit donc pas d'un seul point de défaillance. Ce n'est pas une performance, un goulot d'étranglement. Ce n'est pas un goulot d'étranglement d'évolutivité. C'est donc l'approche recommandée pour l'accompagner et c'est ce que nous allons couvrir en détail aujourd'hui, comment utiliser la mise en cache .NET et ce sera NCache comme exemple de produit dans une application EF Core via des méthodes d'extension.
3 cas d'utilisation de la mise en cache distribuée couramment utilisés
Quelques cas d'utilisation courants du cache distribué. Vous pouvez l'utiliser pour la mise en cache des données. Vous pouvez utiliser des appels d'API directs. Ou utilisez Entity Framework ou les méthodes d'extension même pour les applications EF Core et vous enregistrez autant que possible vos déplacements dans la base de données.
Alors sur site, le site des choses, tu as ASP.NET, ASP.NET Core Mise en cache. Il peut s'agir d'une application Web ou d'un service Web. S'il s'agit d'une application Web, alors si vous souhaitez utiliser des sessions. Vous voudrez peut-être utiliser ASP.NET et ASP.NET Core SignalR Backplane, Mise en cache des réponses pour un ASP.NET Core. De même, l'interface IDistributedCache est disponible, l'état d'affichage et la mise en cache de sortie. Ce sont toutes des options sans code pour vos applications.
Et puis vous avez une puissante messagerie Pub/Sub. Vous pouvez avoir un sujet auquel vous vous abonnez, puis vous partagez des messages entre différentes applications. Les éditeurs et les abonnés peuvent s'envoyer des messages.
Donc, c'est une idée générale. Nous nous concentrerons davantage sur la mise en cache des données aujourd'hui dans une application EF Core et je vous expliquerai des étapes simples pour commencer, puis nous développerons davantage, en partageant de plus en plus de détails sur différents scénarios.
Alors, commençons rapidement avec ça.
Mise en cache des données APP : Entités principales EF
La première chose que je voudrais aborder aujourd'hui est la mise en cache des données d'application.
Vous avez un EF Core Entities. Donc, ces entités doivent être mises en cache. Ainsi, vous pouvez voir une seule entité. Par exemple, vous avez un compte, une somme. C'est une valeur ou vous pourriez, vous faites un tri et vous en sortez le premier client ou les critères sont tels qu'il renvoie un seul client, un seul produit, une seule commande. Donc, c'est une seule entité, comment la mettre en cache ? De même, nous avons des résultats de requête, il pourrait s'agir d'une collection d'entités. Ce n'est donc pas une seule entité. C'est une collection d'entités. Il y a deux options. Vous pouvez mettre en cache la collection entière en tant qu'élément unique dans le cache ou vous pouvez mettre en cache chaque élément de collection, chaque entité de cette collection séparément dans le cache distribué.
Options de mise en cache de l'entité principale EF
Alors, passons en revue les approches autour de cela.
Comme indiqué précédemment, vous pouvez utiliser directement NCache Apis. NCache L'API est un magasin de valeurs clés, vous ajoutez des données à NCache vous-même, puis vous en recevez vous-même ou vous pouvez utiliser les méthodes d'extension de base EF et prendre en charge cette collection d'entités et d'entités uniques.
Alors, laissez-moi d'abord vous montrer le direct NCache Approche API commune à tous les types d'applications. Vous pouvez l'utiliser dans EF Core. Vous pouvez l'utiliser dans EF standard ou dans toute autre application .NET, puis je parlerai des méthodes d'extension EF Core qui sont spécialement conçues pour vos applications principales EF, ce qui vous facilite la vie lorsque beaucoup de choses sont faites automatiquement. pour vous et il vous suffit d'appeler cette méthode d'extension avec vos requêtes. Donc, je vais vous montrer les deux approches une par une, puis nous nous concentrerons davantage sur les méthodes d'extension à l'avenir.
Mise en cache de l'entité unique EF Core : NCache API directes
Ainsi, notre premier exemple met en cache une seule entité EF Core.
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;
}
}Nous avons une méthode GetCustomer, ici. Je vais vous montrer cela à l'aide d'un exemple d'application que j'ai formulé pour cela. Donc, c'est notre première méthode. J'espère que vous pouvez voir mon écran. Donc, nous avons Get Customer. Cela prend notre identifiant client et l'idée ici est que cela renvoie une seule entité, n'est-ce pas. Ainsi, généralement avec l'API directe, le défi est que vous devez prendre en compte ou quelque chose que vous devez implémenter vous-même.
Tout d'abord, vous devez avoir une clé et cette clé est quelque chose que vous identifiez à l'intérieur d'une entité NCache et vous devez conserver toutes les clés dans le même format. Vous pouvez proposer un exemple de format, comme indiqué à l'écran. Il y a un mot clé client, puis l'ID client et un paramètre d'exécution de l'ID client qui constitue la clé de cache.
In NCache tout est stocké dans une paire clé-valeur. La clé est une clé de chaîne et la valeur est un objet autorisé par .NET et il peut également s'agir de n'importe quelle entité EF Core, mais vous formulez la clé, puis vous utilisez l'entité en tant qu'objet à stocker dans NCache. Maintenant, vous vérifiez d'abord si cette clé existe déjà dans le cache ou non en appelant cache.Get et si vous obtenez ce client directement à partir du cache et qu'il s'agit d'un NCache API cache.Get, vous transmettez la clé et si vous obtenez ce client, vous renvoyez le code à partir d'ici, s'il n'est pas nul. Mais, s'il est nul, par exemple, vous exécutez cette requête pour la toute première fois, à droite, rien n'est encore dans le cache. Donc, dans ce cas, vous exécuteriez contre Entity Framework Core, l'API LINQ contre la base de données, puis vous récupérez ce client à partir de la base de données et appelez également cache.Insert, stockez-le avec la même clé que vous avez formulée, puis le client est le l'entité que vous souhaitez ajouter, puis vous la renvoyez également.
C'est ainsi que vous traiteriez réellement une seule entité en utilisant la bonne API.
Mise en cache de la collection d'entités principales EF : NCache API directes
Puis la collecte. La collection peut être soit une collection en tant qu'objet unique, soit à nouveau en tant qu'entité unique.
List<Customers> GetCustomersByCity (string CustomerCity)
{
string key = "Customers:City = " + CustomerCity;
List<Customers> custList;
custList = (List<Customers>)_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;
}
} Chaque entrée de collection peut être une seule entité ajoutée séparément dans le cache. Donc, pour cela, nous devons obtenir des clients par ville, c'est donc la méthode suivante. Il renvoie une liste de clients. Encore une fois, il s'agit de passer la ville du client comme critère. Encore une fois, vous formulez une clé. Encore une fois, c'est vous savez, cela représente une collection de clients basée sur la ville, puis cette ville pourrait être un paramètre d'exécution ici. New York, Paris, Londres, puis vous récupérez d'abord en appelant le cache. Obtenez vous-même du cache, puis vous vérifiez s'il existe dans le cache, s'il revient d'ici, si ce n'est pas le cas, vous le stockez simplement en tant que seul recueil.
Ainsi, cette liste de clients est stockée comme un seul objet. Une autre alternative pourrait être que vous parcouriez la liste des individus, des clients dans les entités client et appelez le cache.Insérez individuellement comme indiqué ici. À droite? Ainsi, les entités uniques et les collections d'entités utilisant directement NCache Les API vont être mises en cache en utilisant ces approches. Nous avons maintenant couvert les API directes. C'est quelque chose que vous pouvez utiliser dans n'importe quelle application.
Mise en cache d'entité unique EF Core : méthodes d'extension EF Core
Concentrons-nous sur les méthodes d'extension Entity Framework Core. Donc, pareil pour, une seule entité et une collection d'entités utilisant le NCache méthodes d'extension. Donc, je vais vous présenter FromCache.
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;
}C'est notre première méthode d'extension et d'ailleurs pour que cette méthode d'extension soit utilisée, vous devez d'abord introduire NCache Package NuGet Package Entity Framework Core NuGet dans votre application. Donc, c'est un must. Si vous allez à l'installé, c'est un Alachisoft.NCache.EFCore NuGet package. C'est ce que vous devez introduire dans votre application, c'est un et après cela, tout ce que vous avez à faire est, permettez-moi, d'ouvrir simplement le contexte. Donc, à l'intérieur du contexte, vous appelez simplement NCacheConfiguration.Configure et il prend un cacheID que je lis à partir des paramètres de l'application, puis il prend également le type de, si vous utilisez des dépendances, c'est une fonctionnalité avancée dans les méthodes d'extension Entity Framework Core. Vous devez fournir le type de la source de données.
Mais, une fois que vous avez appelé NCache Configurer la méthode, il y a plusieurs choses que cette méthode demande. Vous pouvez également configurer un enregistreur, mais c'est tout. Cela vous permet de commencer à appeler NCache, EF Core Extension Methods dans votre application.
Mise en cache de la collection d'entités EF Core : méthodes d'extension EF Core
Donc, la même méthode que vous connaissez, mais cette fois, obtenez des clients grâce à des méthodes d'extension.
List<Customers> GetCustomersByCity (string CustomerCity)
{
List<Customers> 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;
}Cela va rendre tout beaucoup plus simple. Vous n'avez pas à vérifier vous-même les données dans le cache et vous n'avez pas à appeler vous-même explicitement insert et, plus important encore, vous n'avez pas à appeler, vous n'avez pas à construire vous-même la clé de cache. Ceci est complètement automatisé dans le cadre de la mise en place de ce 'FromCache'.
Maintenant, d'un point de vue comportemental, c'est exactement ce que nous avons montré plus tôt. FromCache, prend tout d'abord une option de mise en cache, les options et 'cacheKey' est une référence out. Ainsi, il construit automatiquement la clé de cache pour vous dans les coulisses. Vous avez juste besoin d'appeler depuis le cache à côté de votre requête en tant que méthode d'extension et vous transmettez simplement les options de stockage si, il renvoie toujours une collection, à droite. Donc, dans ce cas, vous pouvez choisir qu'il s'agisse d'une entité distincte ou d'une collection distincte, n'est-ce pas. Ainsi, il peut s'agir d'une collection d'entités ou d'entités distinctes de cette collection.
Ainsi, FromCache fonctionne de telle manière que si une entité ou si une requête que vous avez exécutée et les entités résultantes sont déjà dans le cache, il l'obtiendrait de NCache automatiquement. Mais, s'ils ne sont pas dans le cache, dans ce cas, il exécuterait automatiquement cette requête sur la base de données et le jeu de résultats est renvoyé et en même temps, il est également mis en cache et nous avons également attaché le contexte de la base de données pour les appels ultérieurs.
Par exemple, si vous appelez FromCache pour la première fois, il le met en cache. La prochaine fois que la même requête s'exécutera, elle s'exécutera évidemment sur le cache mais pas sur la base de données. Cette fois, votre contexte, s'il a été supprimé précédemment et pour cette demande, vous utilisiez la construction using d'ailleurs, si vous apportez des modifications aux entités qui attachent également ces modifications au contexte. Et lorsque vous appelez Enregistrer les modifications, toutes les modifications apportées aux entités extraites du cache sont en fait appliquées à la base de données. Donc, c'est un peu, encore une fois, un concept légèrement avancé. Je passerai un peu plus de temps, à un stade ultérieur, mais juste pour vous faire savoir, la méthode from cache fonctionne de telle manière que si quelque chose n'est pas dans le cache, il le récupère dans la base de données et le met en cache. Mais, si quelque chose est déjà disponible dans le cache, il le renverra simplement à partir de là. Ainsi, cela automatise l'ensemble de l'approche directe de l'API pour vous, mais cela construit également les clés. Il organise également automatiquement les données dans une entité distincte ou une collection distincte et il vous suffit d'appeler à partir du cache et de transmettre la clé de sortie et les options.
Même cas pour les collections. Pour une collecte, obtenez client par ville. Il serait stocké en tant que collection, puis à nouveau vous pouvez appeler à partir du cache. C'est donc aussi simple que cela de démarrer avec les méthodes d'extension Entity Framework Core.
Quelles données mettre en cache dans EF Core ?
Notre sujet suivant concerne, notre sujet suivant concerne à nouveau l'utilisation du type de données dans le cache.
Vous pouvez avoir soit des données de référence, soit des données transactionnelles. Y a-t-il une question?
Ouais, Ron, j'ai une question ici. Méthodes d'extension de NCache travailler avec EF Core, vous recommandez .NET Core 2.0 Framework ou un .NET Framework?
Très bien. Ainsi, puisque EF Core lui-même peut s'exécuter sur .NET ainsi que dans .NET Core, donc, c'est très flexible. NCache les méthodes d'extension fonctionneraient parfaitement. En fait, j'exécute cet exemple d'application sur .NET framework 4.6.1 et j'ai un autre exemple d'application qui fonctionne je crois .NET core 2.0. Alors ceci est .NET Core 2.0. Donc ça marche avec les deux .NET frameworks et fondamentalement, il est préférable que vous utilisiez .NET Core, mais c'est souple. Cela fonctionnera pour les deux. J'espère que cela répond à votre question.
Passant à autre chose, le segment suivant de la présentation concerne le moment où vous commencez à planifier la bonne mise en cache et, évidemment, les méthodes d'extension de base du cadre d'entité vous facilitent la vie en termes de mise en cache. Ainsi, il fait en fait beaucoup de choses automatiquement. Donc, la question suivante est de savoir quelles données mettre en cache, n'est-ce pas ?
J'ai donc classé les données en deux catégories. Nous avons des données de référence. Il s'agit de données de recherche, puis nous avons nos données transactionnelles, qui sont créées dynamiquement et changent très fréquemment. Donc, les données de référence, un exemple rapide serait les produits, les employés. Ce ne sont pas des données statiques à 100 %, mais c'est quelque chose qui ne change pas fréquemment. Mais, ça change, la fréquence des changements n'est pas si grande. Et pour cela, vous devez prévoir de mettre en cache toutes les données de référence. Toutes les données de référence doivent être mises en cache comme un must, puis les données transactionnelles sont des données créées dynamiquement. Tels que les commandes, les comptes, certains traitements de flux de travail sur une collection spécifique de données et la portée de cette collection est uniquement pour ce flux de travail. Une fois que ce flux de travail est terminé, ces données ne sont plus nécessaires et ces données peuvent également changer très fréquemment. À tel point qu'il peut changer en cinq minutes. Alors que les données de référence sont généralement des données de recherche qui peuvent changer entre les heures. 1 à 2 heures, 5 à 10 heures ou même en jours.
Nous avons une question ici. Comment identifieriez-vous cet objet mis en cache lors de la récupération à l'aide des extensions EF, tout comme les clés créées automatiquement ? En fait, ne pas récupérer mais supprimer une clé particulière ?
Très bien. Nous avons donc une méthode d'extension pour la récupération., La méthode d'extension s'exécute avec EF Core. Ainsi, l'objet de retour serait identifié sur les mêmes lignes que votre requête LINQ l'identifierait. Je pense que la question est plus axée sur ce qui se passe lorsque vous prévoyez de mettre à jour les enregistrements et pour cela, nous avons un ensemble d'API. Nous vous donnons une méthode qui vous permet de générer une clé contre une entité. Il existe une méthode de génération de clé que nous avons rendue publique. Donc, avant de modifier directement le cache et je suppose que cette question est davantage axée sur la suppression de quelque chose dans le cache ou la mise à jour de quelque chose dans le cache ou la suppression ou l'ajout explicite de quelque chose dans le cache. Nous avons exposé la classe de cache que je vais vous montrer dans un instant, puis il y a une génération de clé. Encore une fois, vous transmettez une chaîne et utilisez la référence out et vous transmettez également l'entité. Donc, contre cette entité, nous utilisons la même approche et nous vous donnerons une clé et en utilisant cette clé, vous pouvez identifier l'objet de cette entité, s'il existe dans le cache, vous devriez pouvoir le mettre à jour et le supprimer.
Je pense que vers la fin, je vais vous montrer un exemple de la façon d'y parvenir, mais juste pour vous faire savoir, il y a des méthodes auxquelles nous avons été exposés, obtenir la clé de NCache aussi bien. J'espère que cela répond à votre question.
Mise en cache des données de référence dans EF Core
Passons à autre chose. Nous avons donc parlé de données de recherche, puis de données créées dynamiquement.
Je vais donc passer en revue, une par une, différentes approches pour gérer cela. Donc, tout d'abord, nous parlerons des données de référence dans EF Core. Comme je l'ai mentionné, il s'agit généralement de données de recherche. Donc, il y a deux choses que vous devriez faire comme un must. Vous devez tout d'abord charger des données entières, des données de référence entières dans le cache comme un must et la motivation ici est que ces données sont quelque chose qui ne change pas aussi fréquemment. C'est un catalogue de produits dans un EF, dans une application e-commerce. Il y a des remises sur certains produits pendant que cette remise est activée, disons pendant trois jours. Ces produits peuvent ne pas changer, il est donc préférable de mettre tous ces produits en cache dans NCache et économisez autant que possible vos déplacements coûteux dans la base de données. 100 %, les données doivent être chargées dans le cache. Ainsi, vous n'avez pas besoin de revenir à la source de données et de toujours les mettre en cache en tant qu'entités distinctes. Pourquoi? Parce que les produits, l'ensemble de données complet pourrait être des milliers et des milliers de produits.
Disons, la base de données Northwind. Les produits peuvent aller de 50,000 100,000 à 10 100 produits. Mais, vous n'aurez peut-être besoin que de, disons, XNUMX de ceux-ci ou XNUMX de ceux-ci pour une demande donnée. Ainsi, si vous les stockez en tant qu'entités distinctes, vous pouvez exécuter des requêtes LINQ. NCache prend également en charge LINQ sur NCache directement. Ainsi, vous pouvez exécuter LINQ pour obtenir le sous-ensemble des données interrogeant le sous-ensemble des entités sur NCache également.
Donc, ce sont deux règles que vous devez suivre comme un must et j'ai un exemple et ici je présente notre deuxième méthode d'extension qui s'appelle Charger dans le cache.
Mise en cache des données de référence dans EF Core : cache de préchargementMaintenant, cela fonctionne de telle manière et cela est ciblé uniquement pour les données de référence. Il s'agit d'un préchargeur dans le cache.
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();
}Donc, la motivation ici est que vous devez appeler cette méthode, disons Charger tous les produits et vous devez vous assurer que vous le stockez en tant qu'entités distinctes et vous devez exécuter une requête qui dit des produits dans la base de données produits et sélectionner des produits . Donc, vous ne spécifiez aucun critère qui signifie que cela chargerait les 60,000 XNUMX produits dans le cache, puis vous utilisez LoadIntoCache, à droite. Lorsque vous dites des entités distinctes, il vous suffit de transmettre cette option et nous créerons simplement une entité distincte pour chaque produit dans le cache et il s'agit encore une fois d'un préchargeur, n'est-ce pas. Vous devriez précharger ceci..
Il y a deux options. Vous pouvez exécuter une application distincte pour cela qui peut prendre en charge le préchargement du cache. Il peut s'agir d'un démarrage d'application ou d'une application distincte ou d'une implémentation de chargeur de cache de NCache aussi bien. Il existe un chargeur de cache et, dans les versions futures, travaillait également sur le rafraîchissement du cache.
La responsabilité du chargeur de cache est qu'il s'exécute réellement au démarrage de votre cache, puis il s'assure que toutes les données que vous souhaitez charger dans le cache sont chargées dans le cadre de cela. C'est votre implémentation mais NCache l'appelle simplement. Mais, comme je l'ai mentionné, vous pouvez trouver la méthode comme celle-ci et vous assurer que vous l'appelez une fois au démarrage de votre application ou qu'une application distincte le fait et partage ces données sur toutes vos instances d'application.
Maintenant, une fois que cela est fait, comment interroger les données hors du cache et à ce stade. Je vais vous présenter ma troisième méthode d'extension qui est From Cache Only.
Mise en cache des données de référence dans EF Core : rechercher les données de référence dans le cache uniquementList<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;
}Ainsi, la première méthode d'extension était FromCache qui était, si quelque chose est dans le cache, récupérez-le à partir de là. Si ce n'est pas le cas, accédez automatiquement à la base de données et récupérez-la. LoadIntoCache s'exécute toujours sur la base de données. Il n'est jamais exécuté contre le cache bien qu'il revienne, mais cela revient de la base de données comme un must pour que l'ensemble de données soit actualisé. Une nouvelle donnée est chargée, puis elle est également mise en cache, puis FromCacheOnly ne s'exécute que contre NCache car ceci est conçu uniquement pour les données de référence. Ainsi, pour les données de référence, vous utiliserez une combinaison de LoadIntoCache. Pour que toutes les données de l'ensemble de données existent dans le cache en tant qu'entités distinctes, vous appelleriez FromCacheOnly afin que seul l'ensemble de données qui vous intéresse, c'est-à-dire que les produits abandonnés dans ce cas n'aient été apportés qu'à partir du cache. Ainsi, vous n'avez pas du tout besoin d'accéder à la base de données. Je vais parler de la façon de garder ces données à jour lorsque les données changent dans la base de données. Donc, j'espère que cela a du sens. Laissez-moi vous montrer cet exemple ici.
Donc, j'appelle cette méthode ici, puis je renvoie une liste de produits, des produits abandonnés en utilisant un simple EF, l'API LINQ directement sur NCache entités.
Donc, cela ne s'exécuterait pas du tout sur la base de données. Cela ne s'exécuterait que sur le cache car j'utilise FromCacheOnly, méthode d'extension. J'espère que ça aide. Nous avons couvert trois méthodes d'extension, FromCache qui est davantage un cas d'utilisation de données transactionnelles, puis nous avons couvert LoadIntoCache et FromCacheOnly. Pour les données de référence, vous devez vous concentrer sur l'utilisation de données entières à l'aide de LoadIntoCache, puis sur des entités distinctes, puis pour les requêtes, vous devez utiliser FromCacheOnly.
Mise en cache des données transactionnelles dans EF Core
Ensuite, nous parlerons des données transactionnelles, puis nous parlerons de la manière de conserver ces données à jour à la fois pour la référence et pour la transaction.
Maintenant, les données transactionnelles sont généralement un ensemble de travail. J'ai déjà expliqué qu'il s'agit de données créées dynamiquement. Il n'est nécessaire que pour un utilisateur actuel, une demande en cours ou un flux de travail en cours d'exécution et une fois exécuté, vous n'aurez peut-être plus besoin de ces données. Ainsi, il est probable que seule l'instance de l'application qui récupère réellement ces données que ces entités ne soient nécessaires que par cette instance d'application. Cela n'a donc aucun sens de stocker toutes vos données transactionnelles dans le cache. Ce n'est pas une exigence. Vous ne devez mettre en cache que le jeu de travail. Donc, c'est l'étape numéro un. Donc, vous devez mettre en cache les résultats de la requête. Vous pouvez récupérer les entités d'accès les plus faciles et la deuxième étape consiste en deux options 2a, 2b.
Récupérer et mettre en cache en tant que collectionVous pouvez mettre en cache vos données transactionnelles en tant que collection entière. C'est une approche privilégiée.
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;
}Habituellement, vous avez toujours besoin d'une collection entière, car vous travaillez dessus et vous pouvez également stocker des entités distinctes. Cela dépend entièrement de vous et c'est pour le scénario où, bien que vous ayez mis en cache une collection, mais que vous la stockiez toujours en tant qu'entités distinctes, car vous pourriez n'avoir besoin que de deux ou trois entités de cette collection. Il est donc préférable d'avoir une approche granulaire lors du stockage des collections et nous avons GetCustomerOrders. Les commandes sont des données assez transactionnelles. Il doit y avoir une unité de traitement qui s'occupe de certaines commandes et il est probable que chaque flux de travail qui s'en occupe ait son propre ensemble de commandes.
Donc, je vais vous montrer cet exemple très rapidement. Donc, cela fonctionne de telle manière qu'il met beaucoup d'options de mise en cache. N'entrons pas vraiment dans les détails ici. Conserver en tant que collection. C'est ainsi que vous choisissez de le stocker en tant que collection, puis j'utilise FromCacheOnly. La raison des données transactionnelles, j'utilise FromCache parce que les données peuvent exister dans le cache et si elles font toute la collection, j'ai juste besoin de les utiliser. Je n'ai pas besoin d'aller dans la base de données. Mais, s'il n'existe pas dans le cache et que ces données changent également très fréquemment, nous avons également défini une expiration, disons, 30 secondes, vous voudrez peut-être revenir à la base de données. Si vous utilisez FromCacheOnly, vous pouvez renvoyer une valeur nulle si elle n'existe pas dans le cache, si elle a déjà expiré.
Ainsi, pour les données transactionnelles, utilisez la méthode d'extension From Cache, pour les données de référence, utilisez LoadIntoCache pour précharger, puis utilisez FromCacheOnly. Donc, c'est l'approche à suivre.
Récupérer et mettre en cache en tant qu'entités distinctesPour les entités distinctes, tout ce que vous avez à faire est de stocker, appelez ceci.
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;
}Permettez-moi simplement d'utiliser ceci et au lieu d'utiliser une entité distincte, dites simplement (je dois commenter, j'aurais dû commenter) Bon, stockez en tant qu'entités séparées. C'est tout ce que vous devez faire.
Alors, Ron, pendant que vous y réfléchissez, il y a une question. Dans l'exemple précédent, interrogeant les données de référence, y a-t-il une indexation ? Parce que, c'est seulement ce que vous feriez sur la base de données pour le faire….
Absolument, c'est une très bonne question et pour les données de référence, puisqu'elle s'exécute sur le cache uniquement, cette requête LINQ nécessite que votre produit et l'attribut sont le long desquels vous exécutez la requête LINQ est indexé et en fait je suis en utilisant des données d'index et c'est très simple à indexer, il vous suffit de fournir le type, le modèle, puis de fournir les attributs que vous devez indexer. Donc, ce sont des attributs d'index et nous exécutons en effet des requêtes sur les attributs d'index. J'espère que cela répond à votre question.
Garder le cache à jour
Je vais passer très rapidement à notre partie pratique, vous montrer le produit réel en action, puis le segment le plus important de ce webinaire, comment conserver les données de cache à jour par rapport à la base de données et également en ce qui concerne les données de référence et données transactionnelles.
D'accord, je vais donc ouvrir un nouveau projet. D'accord, donc, la partie de démonstration pratique, je vais vous montrer rapidement le produit réel en action afin que vous sachiez à quoi ressemble une mise en cache distribuée, puis nous exécuterons l'application dessus et je vous montrerai comment garder c'est frais, les données et le cache sont frais.
j'ai déjà installé NCache sur deux de mes boîtes 107 et 108. Je vais les utiliser comme serveurs de cache et ma machine personnelle ici, mon ordinateur portable va agir en tant que client.
Alors, tout d'abord, je vais lancer le NCache outil de gestion qui est installé avec NCache et je vais créer un cache, disons, nommons-le cache EF Core. J'utiliserai deux serveurs. Conservez les répliques de partition comme topologie de mise en cache, puis l'option de réplication asynchrone car c'est plus rapide et ici j'ai spécifié les serveurs qui vont héberger mon cache. Donc, j'ai deux serveurs, démo 1 et démo 2 et un port TCP/IP pour la communication. Tout est piloté par TCP/IP en ce qui concerne la communication entre les serveurs et les clients.
Taille du cache, basée sur les données que vous prévoyez de mettre en cache. S'il s'agit de données de référence, vous devez tenir compte du fait que vous chargez tous les produits, tous les clients. De même, s'il s'agit de données transactionnelles, vous devez tenir compte de l'ensemble de travail et d'un peu plus d'espace pour cela également. Gardez tout simple, choisissez la finition et c'est tout. C'est aussi simple que de commencer NCache et configurer un cache.
Depuis, j'exécute des applications sur ma machine, il me suffit donc d'ajouter ma boîte en tant que machine cliente. Je peux démarrer et tester ce cluster de cache et après cela, je suis prêt à exécuter l'exemple d'application pour m'y connecter. C'est tellement simple. Nous avons un habitué NCache Webinaire sur l'architecture et la mise à l'échelle des applications .NET dans lequel nous parlons de ces configurations en détail. Donc, si vous avez des questions, vous voudrez peut-être également consulter ces webinaires.
Je vais également vous montrer certains aspects de la surveillance. Fenêtre de statistiques, puis j'ouvrirai NCache outil de surveillance afin que je puisse réellement exécuter l'application d'outil de test de stress qui est installée avec NCache et voir les choses en action. Il s'agit donc d'un outil de test de stress. Je vais l'exécuter contre cela parce que ma boîte est un client, donc je peux simplement fournir le nom et il devrait se connecter à cela et je devrais pouvoir simuler une charge fictive sur mon cluster de cache, voilà. La taille du cache augmente, des éléments sont ajoutés et les demandes par seconde de chargement montrent également une activité sur les deux serveurs, puis cet outil de surveillance, je pense que cela prend du temps, il crée un tableau de bord.
Alors, laissez-le rouler et en attendant, laissez-moi exécuter une autre instance de cet outil à partir du serveur lui-même. Ma faute. Très bien, vous pouvez donc voir le nombre croissant de requêtes par seconde augmenter. Pour une raison quelconque, le chargement du tableau de bord, l'outil de surveillance, prend un certain temps. Je pense que je le laisserai ici dès qu'il reviendra je vous montrerai les détails de surveillance de cet outil.
Gardez le cache à jour : données de référence
Très bien, notre prochain segment de ce webinaire consiste à conserver les données de cache à jour dans une application Entity Framework Core et pour cela, j'utiliserai à nouveau des données de référence et des exemples de données transactionnelles. Donc, nous allons commencer avec des données de référence.
Nous avons déjà établi que pour mettre en cache les données de référence, vous devez mettre en cache l'ensemble des données dans le cache. Par exemple, vous avez des produits, vous devez charger tous les produits dans le cache, puis les charger en tant qu'entités distinctes. Alors quel est le problème avec ça?
Depuis, les données de référence, l'intégralité des données de référence dans le cache, puis vous utilisez uniquement le cache à l'aide de la méthode d'extension FromCacheOnly. Maintenant, vous ne voulez pas vous permettre un ensemble de données partiel hors du cache. S'il s'agit de produits abandonnés ou si vous utilisez certains critères, vous voulez que tous ces produits soient dans le cache. Mais, il y a des chances que ces produits changent réellement dans la base de données. Désormais, les données existent à deux endroits différents. Vous avez une base de données qui est votre copie principale et bien que vous ayez chargé des données entières dans le cache, il y a toujours des chances que la base de données soit mise à jour en dehors de la portée de vos applications.
Ainsi, afin de garder les données du cache à jour, vous devez vous assurer que vous disposez d'une sorte de mécanisme qui met à jour automatiquement les données et le cache et pour cela, nous avons deux options. L'option numéro un est que vous utilisez l'expiration.
void 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();
}Il s'agit d'une expiration basée sur le temps, puis vous la mélangez, vous l'utilisez en plus avec la fonction de rechargement automatique. NCache la fonction d'expiration vous permet d'expirer les données, de supprimer les données après la période de temps spécifiée, disons, 5 heures, 10 heures et avec des données de référence car il s'agit de données longues et en cours d'exécution, il s'agit de données de recherche, de données de base, donc la fréquence de changement n'est pas c'est génial, vous pouvez donc trouver un nombre confortable d'heures ou vous savez, cela pourrait être 5 heures, 10 heures, 24 heures. Donc, sur cette base, vous pouvez définir un délai d'expiration. Mais, comme mentionné précédemment, vous ne voulez pas vraiment perdre ou supprimer ces données du cache.
Ce dont vous avez vraiment besoin, c'est que les données qui sont modifiées, disons, 10 produits sont expirés en fonction de l'expiration de ce que vous avez spécifié, il devrait recharger automatiquement ces données dans le cache avec un mécanisme de rechargement automatique. Et NCache vous fournit cela à l'aide d'un gestionnaire de lecture. Donc, tout ce que vous avez à faire est de charger à nouveau des données entières et le cache en utilisant charger dans le cache, d'utiliser des entités distinctes mais à côté de cela, utilisez ces caractéristiques. Tels que, Set Absolute Expiration.
C'est la valeur d'expiration que vous définiriez pour tous les produits qui vont être chargés dans le cache, puis vous définissez le fournisseur de resynchronisation, qui appelle essentiellement votre fournisseur de lecture dans NCache. La lecture continue est combinée avec l'expiration. Ainsi, au lieu de supprimer les données du cache, il se recharge en fait, puisqu'il connaît toutes les clés et toutes les informations liées à la base de données, nous avons juste besoin que vous transmettiez le contexte et en fonction de ce contexte, nous appelons votre fournisseur automatique et resynchronisé. Nous obtenons la valeur mise à jour à partir de la source de données.
Permettez-moi de vous en montrer un exemple concret. Voici une méthode. Je stocke cela en tant qu'entités distinctes. En règle générale, je définirais une expiration de 5 heures, mais comme nous n'avons pas beaucoup de temps, ce que je ferais vraiment, c'est que je définirai une expiration d'environ 30 secondes et je mettrai un point d'arrêt ici et je chargerai tous les produits dans le cache. Je ne mettrais pas en place un fournisseur de resynchronisation à ce stade juste pour vous montrer comment fonctionnent les expirations et dès que l'expiration entre en jeu, il supprimera les éléments du cache, puis je vous montrerai comment, prenez soin de ce scénario de telle sorte qu'au lieu de supprimer, il suffit de recharger à l'aide du gestionnaire de lecture.
Donc, je vais utiliser le cache local pour cet exemple. Je vais simplement effacer le contenu juste pour être du bon côté, puis je vais exécuter ce morceau de code et atteindre le point d'arrêt. À droite. Donc, il a 30 secondes d'expiration et je vais juste frapper et j'ai obtenu les produits abandonnés, c'est bien. Donc, nous avons tous les produits ici et nous avons environ un millier d'entrées ici. Après 30 secondes, ces milliers d'éléments vont expirer en fonction de cette expiration absolue, indicateur que nous avons configuré et je relancerai cette requête et vous verrez qu'elle ne renverra rien car rien n'existe dans le cache. Il utilise From Cache Only. Donc, nous avons des articles expirés. Je vais exécuter ceci une fois de plus et vous remarquerez que j'ai obtenu la valeur 0.
Donc, ce n'est pas ce qui est recommandé ou ce qui est préféré, étant donné qu'il s'agit de vos données de référence, des données entières sont déjà chargées dans le cache et vous appelez la méthode d'extension From Cache Only. Donc, vous avez besoin de toutes les données disponibles en tant que must, pas de la réponse partielle ou des données manquantes et en même temps, cela devrait être rechargé après votre expiration. Au lieu de le supprimer, il faut le recharger et c'est exactement ce que nous allons faire à l'aide de ce nom de fournisseur de resynchronisation.
J'ai un exemple de fournisseur de resynchronisation, qui se trouve ici, IReadThruProvider. Ce qu'il fait vraiment, c'est que nous vous en avons donné une implémentation par défaut.
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();
}
}
}Ceci est notre IReadThruProvider. Tout ce que vous avez à faire est de montrer cela à l'aide du cache que nous avons configuré. Vous devez configurer le gestionnaire de lecture. Par exemple, laissez-moi juste créer un nouveau cache, laissez-moi juste créer un cache local. À droite. Donc, c'est juste un cache local. Je vais juste mettre en place une source de sauvegarde. Activez la lecture, ajoutez et disons EF par défaut et cela doit être configuré et je peux l'utiliser comme projet et la mise en œuvre est déjà effectuée.
Cela fonctionne de telle manière que j'ai implémenté le gestionnaire IReadThru. C'est le fournisseur de resynchronisation par défaut, à droite. Il a quelques méthodes. Il a une initialisation où vous initialisez le contexte de base de données. LoadFromSource qui est appelé à l'expiration et à l'intérieur de celui-ci, je récupère l'élément de la base de données. Si j'entre dans la définition, elle prend en charge tous les appels liés à la base de données et c'est quelque chose que nous fournissons dans le cadre de notre implémentation. Notre package NuGet en fait partie. Donc, nous obtenons la clé et sur la base de cette clé, vous transmettez le contexte et le contexte est utilisé pour obtenir l'objet réel directement à partir de la base de données.
Tout ce que vous avez à faire, c'est savoir, hériter, implémenter ce fournisseur de resynchronisation par défaut EF et donner votre propre implémentation et nous donner le contexte de la base de données.
Donc, c'est une classe abstraite que nous vous avons donnée. Vous avez juste besoin de donner votre contexte de base de données Northwind ou tout contexte de base de données que vous avez et sur cette base une fois que cette méthode est remplacée / implémentée, vous l'enregistrez simplement avec votre cache. Par exemple, il s'agit d'un fournisseur de resynchronisation. Si j'ouvre ceci, il en contient deux. L'un est par défaut et l'autre est votre implémentation et vous pouvez transmettre votre chaîne de connexion et d'autres informations si nécessaire et c'est tout. Vous déployez simplement ceci. Permettez-moi d'en arriver là et cela vous donnerait juste un succès à ce sujet. Donc, cela doit être fait. Comme je l'ai mentionné, cela se fait déjà dans le cadre de NCache, la mise en oeuvre. Il a, le package NuGet est livré avec un fournisseur de resynchronisation que vous pouvez simplement implémenter en implémentant cette méthode particulière ici et en nous donnant le contexte et le reste du travail est effectué par cet exemple de fournisseur de resynchronisation par défaut, qui fonctionne en fait sur les mêmes lignes que l'extension les méthodes fonctionnent.
Nous construisons votre clé, afin que nous sachions quelle clé représente quelle entité et sur la base de cette entité et de ces informations clés, nous interrogeons réellement la base de données à l'aide d'Entity Framework, APIs. Maintenant, cela a déjà été fait pour mon cache. Ce que j'ai fait ici, c'est que j'ai, il a été déployé avec succès. Donc, pour mon cache, j'ai déjà fait cela. J'ai cette valeur par défaut EF et je l'ai déployée. Donc, je vais exécuter le même cas d'utilisation mais cette fois, au lieu de simplement l'expirer, je le rechargerais en fait. Alors, c'est ce que je vais faire. Tout ce que j'ai à faire est de configurer le nom de leur fournisseur de resynchronisation, puis, puisque je prévois également de mettre à jour certaines valeurs, je vais utiliser 60 secondes. En règle générale, pour les données de référence, vous auriez beaucoup plus de temps spécifié comme votre expiration absolue, comme 5 heures ou même plus. Donc, je vais juste l'exécuter avec 60 secondes et cette fois, je vois que mon fournisseur de resynchronisation est configuré.
Donc, je vais exécuter ce cas d'utilisation une fois de plus et vous montrer comment il est mis à jour au lieu d'expirer, au lieu de le supprimer. Donc, cela a fonctionné et j'espère que cela reviendra à ce point. Très bien. Donc, nous avons des produits chargés. Je vais l'exécuter une fois de plus et, pendant ce temps, puisqu'il a une expiration de 60 secondes, je mettrai à jour ce produit particulier, l'ID de produit 17 et ce que nous ferons, c'est que nous dirons simplement de le mettre à jour, d'accord.
Bien qu'il soit mis à jour dans la base de données, il ne serait pas encore mis à jour dans le contexte de l'application, car il n'utilise que des données de cache et n'a pas encore expiré. Donc, nous continuerons à obtenir les anciennes valeurs et si vous remarquez sur mon cache que nous avons des milliers d'éléments et qu'il y a un Readthru/sec, cela montrerait une activité après 60 secondes, puis il appellerait automatiquement le gestionnaire de lecture que nous avons vient de mettre en place.
Alors, permettez-moi de l'exécuter une fois de plus et j'attends à nouveau des valeurs de commande, si elles ne sont pas déjà rechargées, mais il y aurait un point où il se rechargerait simplement et après cela, au lieu d'expirer, il rechargerait simplement le 999 de les produits. Il y a un élément qui est en plus, c'est généralement une référence. Voilà. Ainsi, au lieu de l'expiration, un seul élément a expiré car il s'agit d'une liste de clés, sinon, toutes les données de référence basées sur ma requête, laissez-moi vous montrer la requête, elle indique où l'ID du produit est inférieur à 1000. Donc, en fait représente 1000 produits.
Donc, je vais exécuter cette requête une fois de plus et cette fois puisque les données ont déjà été mises à jour à l'expiration, au lieu d'être supprimées. Donc, je m'attends à ce que le produit mis à jour soit ajouté dans le cache. Alors, voilà. Ainsi, mon produit a été mis à jour dans le cadre de cela. Donc, c'est ce que nous recommandons dans le cadre de notre option numéro un qui dit que vous utilisez l'expiration mais avec la fonction de rechargement automatique. Ainsi, au lieu de l'expiration, vous rechargez simplement les données et cela prendrait soin de garder les données du cache à jour. Ainsi, vous trouvez un temps confortable qui vous permet de conserver les données dans le cache, vous continuez à obtenir des données plus anciennes et dès que ces données plus anciennes sont sur le point d'expirer, cela pourrait représenter une journée de temps, disons, 24 heures , il peut s'agir de 2 jours, d'une semaine, selon la période la plus confortable pour votre application. Cela pourrait prendre quelques heures également et après cela, il suffirait de recharger ces données dans le cache.
Donc, c'est notre option numéro un. J'espère que c'était assez simple.
L'option numéro deux est que vous n'utilisez pas d'expiration. Donc, cela résoudrait simplement ce problème ici où les données existeraient toujours dans le cache. Mais les données peuvent être périmées dans le cache et elles peuvent être périmées pour toujours. Pour cela, vous devez recharger manuellement et c'est très simple aussi.
void LoadAllProducts (NorthwindContext database)
{
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs.SeperateEntities,
};
var res = (from products in database.Products select
products).LoadIntoCache(options).ToList();
}Tout ce que vous avez à faire est d'appeler simplement Charger tous les produits après un intervalle périodique. Par exemple, si nous revenons à ce bit ici. Donc, cette méthode doit être appelée après quelques intervalles et encore une fois, comme mentionné précédemment, cela se fait généralement au démarrage de votre application et cela pourrait être l'une des applications qui s'en charge, qui s'occupe de tout cela. Donc, cela pourrait être soit cela, soit l'une des applications, une application distincte qui fait cela. Ainsi, il peut s'agir de votre application, de l'une de vos instances d'application ou d'une application distincte et cette application peut périodiquement appeler cette méthode après, disons, 5 heures, 24 heures, encore une fois, ce qui est votre temps confortable après lequel vous voulez cela doit être exécuté sur la base de données et vous voulez que vos produits soient rechargés.
Ainsi, LoadIntoCache prendrait en charge ce scénario particulier où s'exécuterait sur la base de données et chargerait de nouvelles copies dans le cache. C'est ainsi que vous prenez en charge les données de référence. J'espère avoir été assez direct.
Gardez le cache à jour : données transactionnelles
Passons au segment suivant où nous utilisons des données transactionnelles. Maintenant, les données transactionnelles sont quelque chose qui est de courte durée, n'est-ce pas. C'est un ensemble de travail, comme expliqué précédemment. Ainsi, vous pouvez utiliser 5 à 10 minutes d'expiration. Donc, ce que vous devez vraiment faire ici, puisque vous utilisez FromCache qui s'exécute sur le cache, s'il existe dans le cache et s'il n'existe pas dans le cache, il l'exécutera toujours automatiquement sur la base de données. Donc, cela est intégré à cette méthode d'extension, contrairement à FromCacheOnly que vous utilisez avec le scénario de données de référence, à droite, qui ne s'exécute que sur le cache. Il est donc normal que certaines données soient disponibles, que vous les ayez stockées en tant que collection ou en tant qu'entité distincte.
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;
}Donc, vous utilisez simplement une courte expiration, disons 60 secondes bien que j'ai utilisé cet exemple pour les données de référence mais c'était pour cette démo particulière, mais pour les données de référence, vous avez généralement 5 à 10 heures d'expiration et pour les données transactionnelles vous avez quelque part entre 60 secondes ou connexe, l'expiration y est attachée et puisque vous utilisez From Cache, jetons un coup d'œil à Get Customer Orders, puisque vous utilisez FromCache qui devrait vous permettre d'utiliser le, prenons cela comme Exemple.
Bon, donc, vous configurez une expiration ici et vous appelez cette méthode d'extension FromCache et cela devrait se charger de l'obtenir de la base de données s'il n'existe pas dans le cache et après un certain temps, si votre ensemble de travail est actif dans le cache, vous l'obtiendriez du cache, s'il n'est pas actif dans le cache, il y a de fortes chances qu'il ne soit plus nécessaire, n'est-ce pas. Ainsi, vous pouvez finir par revenir à la base de données et c'est la bonne chose à faire avec les données transactionnelles. Donc, j'espère que cela couvre nos données de référence ainsi que les scénarios de données transactionnelles et comment garder les données de cache à jour en ce qui concerne ces deux.
Gestion des relations dans le cache
Je vais passer à notre segment suivant, qui traite des relations dans le cache.
Ron, j'ai quelques questions ici. Est-ce que le NCache ou les éléments mis en cache résident-ils dans le NCache serveur ou sont-ils cachés dans chaque serveur d'application ?
Ils résident dans NCache. Bon, donc les éléments existent réellement dans NCache, à droite. Ainsi, le référentiel réel est maintenu dans NCache et nous construisons en fait les clés et les objets à côté de ces méthodes d'entité. Donc, c'est l'idée ici.
Une autre question est la suivante : pouvons-nous configurer plusieurs chargeurs de cache ou tous doivent-ils être configurés en un seul, lorsque nous ajoutons des données de référence au cache ?
Vous pouvez le faire car le chargement dans le cache est une méthode générique, n'est-ce pas. Donc, il charge en fait n'importe quoi, la requête que vous prévoyez d'exécuter correctement. Donc, c'est lié à la requête. Vous pouvez avoir un multiple de charge dans le cache et il peut y avoir une application distincte ou il peut y avoir différents endroits dans l'application. Donc, c'est aussi très flexible à cette fin.
Gestion des relations dans le cache : un-plusieurs
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;
}Il y a quelques concepts importants que je veux souligner. Comment gérer les relations ? Un-à-plusieurs et vous savez, un exemple plusieurs-à-plusieurs.
Concentrons-nous sur le one-to-many. Si vous avez, disons, des régions et puis il y a des territoires qui en font partie, des régions et il y a une relation un-à-plusieurs entre les régions et les territoires. Passons à l'approche de synchronisation et à l'intérieur, récupérons les régions à partir d'ici.
Très bien, alors, obtenez des régions avec des territoires. L'idée de base ici est que vous avez le mot-clé Include, puis que vous utilisez FromCache et que vous le stockez toujours en tant qu'entité distincte. L'idée ici est que l'élément parent de la région sera stocké en tant qu'élément distinct dans le cache. Étant donné que la région a également une relation un-à-plusieurs avec les territoires et qu'il existe une collection de territoires à l'intérieur de chaque entité de région, NCache obéirait à cela. Dès que vous appelez FromCache, il obtiendrait simplement la région et toutes les régions sont stockées en tant qu'entités distinctes et basées sur la portée que vous spécifiez et tous les territoires avec l'aide de FromCache vont être stockés en tant que collection distincte à l'intérieur de chaque région .
Il s'agit donc d'une entité ayant plusieurs côtés, le côté collection en tant qu'objet connexe. C'est ainsi que vous abordez le cas d'utilisation un à plusieurs.
Mise en cache des opérations d'agrégation
Ensuite, vous avez la mise en cache des opérations d'agrégation. Vous savez, vous pouvez aboutir à une entité ou aboutir à une valeur.
Par exemple, obtenir un premier expéditeur ou un expéditeur par défaut, à droite. Donc, c'est quelque chose, disons, si je fais juste un premier ou un défaut ici, cela me chercherait le premier expéditeur et ensuite vous savez sur cette base, cela va être stocké dans NCache.
Et de même, cela pourrait être la somme des comptes. Il peut s'agir de n'importe quelle opération d'agrégation, il peut donc s'agir d'une valeur. Encore une fois, cela peut être stocké dans NCache en tant qu'entité distincte.
Shippers GetFirstShipperInstance (NorthwindContext database)
{
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs.Collection
};
Shippers shipper = database.Shippers.DeferredFirstOrDefault()
.FromCache(out string cacheKey, options);
return shipper;
}Et de même, cela pourrait être la somme des comptes. Il peut s'agir de n'importe quelle opération d'agrégation, il peut donc s'agir d'une valeur. Encore une fois, cela peut être stocké dans NCache en tant qu'entité distincte.
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, cela couvre notre webinaire en ce qui concerne la partie technique. Vers la fin, je vais vous montrer une architecture de mise en cache distribuée.
Haute Disponibilité
NCache en tant que produit est très, évolutif, rapide. C'est quelque chose qui est basé sur l'architecture peer-to-peer dans le protocole. Il n'y a pas de point de défaillance unique. Vous pouvez ajouter ou supprimer des serveurs à la volée à partir d'un cache en cours d'exécution. Vous n'avez pas besoin d'arrêter le cache ou les clients qui y sont connectés. Ainsi, vous pouvez apporter des modifications dynamiques à un cluster de cache en cours d'exécution.
Topologies de mise en cache
Alors notre topologie la plus populaire est Cache de réplique de partition. Cela vous permet de répartir simplement les données sur tous les serveurs sous forme de partitions. Donc, ils mettent en commun les ressources de mémoire, les ressources de calcul, et cela vous présente une capacité logique et chaque service a également une sauvegarde. Server1 est la sauvegarde sur 2. Serve2 est la sauvegarde sur 1 et Serve3 est la sauvegarde sur Serve1. Ainsi, de manière circulaire, chaque serveur dispose d'une sauvegarde sur un autre serveur.
Cache client (près du cache)
De même, il s'agit de la topologie très rapide, très évolutive et la plus populaire. Vous pouvez également avoir un cache client qui peut fonctionner sur votre propre boîte d'application. C'est un cache local mais il est synchronisé avec le cache du serveur. Un sous-ensemble de données serait automatiquement mis dans le cache et sans aucun changement de code. Cela améliore vos performances si vos données sont principalement de nature de référence. Ainsi, une fois que vous chargez dans le cache, vous commencez à appeler ce sous-ensemble de données en appelant le cache client FromCacheOnly, ce serait vraiment utile dans ce cas.
Réplication WAN du cache
Réplication WAN est une autre fonctionnalité, la réplication de pont. Vous pouvez avoir des sites de données actifs-passifs ou actifs-actifs. Toutes les données, les données EF Core, les sessions ASP.NET ou les données régulières peuvent être transférées vers le site cible via le WAN de manière active-passive ou active-active. Alors, c'est ce que NCache couvre dans le cadre de celui-ci.
Conclusion
Juste pour réitérer, je prendrai une minute de plus avant de céder la parole à Nick. Nous avons donc parlé d'entité unique et de stockage de collections d'entités à l'aide d'API directes. C'était légèrement différent en termes de méthodes d'extension, puis nous avons parlé de méthodes d'extension qui étaient de nature très simple et, vous savez, de nature plus flexible également. FromCache était la première méthode qui récupère quelque chose du cache s'il existe, s'il n'existe pas, il le récupère automatiquement à partir de la source de données, contrairement aux API directes où vous devez l'implémenter vous-même. Il construit également les clés et les options associées que vous configurez ici.
Ensuite, nous avons parlé de données de référence et de données transactionnelles. Pour gérer les données de référence, vous devez charger des données entières à l'aide de LoadIntoCache et vous devez appeler FromCacheOnly. LoadIntoCache s'exécute toujours sur la base de données et vous savez, FromCacheOnly, ne s'exécute que sur le cache, puis nous avons parlé des données transactionnelles que vous pouvez gérer à l'aide de FromCache et vous avez défini des expirations. Données de référence, afin de les garder à jour, vous devez utiliser des expirations, puis vous utilisez le rechargement automatique ou n'utilisez pas d'expirations, puis rechargez manuellement à l'aide de LoadIntoCache. Ensuite, nous avons parlé des données transactionnelles, que vous devez trouver, une sorte d'expiration et utiliser FromCache pour que, si elles existent dans le cache, vous les obteniez. S'il n'existe pas dans le cache, vous l'obtenez toujours à partir de la base de données.
Donc, cela conclut notre présentation. S'il vous plaît laissez-moi savoir s'il y a des questions.
Vous pouvez toujours nous joindre au support@alachisoft.com. Si vous avez des questions techniques, vous pouvez également nous joindre via sales@alachisoft.com. Si vous vouliez y jeter un œil, télécharger le produit, vous pouvez aller sur notre site web alachisoft.com et vous pouvez télécharger NCache et il est livré avec une version d'essai de 30 jours que vous pouvez utiliser et s'il y a des questions, faites-le nous savoir, sinon, merci beaucoup d'avoir assisté à cette émission aujourd'hui, le webinaire, et nous vous verrons la prochaine fois. Merci beaucoup Ron. Merci les gars.