Gestion des données relationnelles dans un cache distribué
Webinaire enregistré
Par Ron Hussain et Adam J. Keller
Dans ce webinaire vidéo, découvrez comment appliquer vos relations de données existantes aux objets de cache pour la mise en cache distribuée.
Vous pouvez vous attendre à entendre parler de :
- Le modèle de stockage de données pour une base de données relationnelle et pour un cache distribué
- La qualité du mappage relationnel d'objet - comment gérer les relations de données au niveau de l'objet
- Cartographier les relations 'un-un', 'un-plusieurs' et 'plusieurs-plusieurs'
- En utilisant NCache fonctionnalités pour établir des relations entre les objets afin d'imiter les comportements des données relationnelles
- utilisation de la dépendance basée sur les clés, du langage de requête d'objet, des groupes, des API de groupe, des collections et des balises
- Autres fonctionnalités importantes de mise en cache distribuée pour les données relationnelles
Je vais parler de la mise en place d'une mise en cache distribuée. Lorsque vous avez une base de données relationnelle, vous savez, vous avez des défis, des problèmes de performances, des problèmes d'évolutivité, puis vous passez à l'utilisation d'un cache distribué avec la base de données relationnelle. Quels sont les défis que vous rencontrez et comment gérer ces défis ? C'est donc ce que nous avons à l'ordre du jour du webinaire d'aujourd'hui.
Ça va être assez pratique. Je veux vous montrer quelques exemples de code. Je vais parler de quelques exemples concrets. J'ai quelques exemples alignés que je vais utiliser pour le démontrer. Et, vers la fin, j'aurais également une partie pratique pour passer en revue certaines notions de base NCache configurations.
NCache, c'est le principal produit de mise en cache distribué. Nous l'utiliserons comme exemple de produit pour ce webinaire particulier. Mais, dans l'ensemble, c'est un webinaire général, vous savez, sur un sujet. Nous avons des données relationnelles dans la base de données, puis vous avez un cache distribué. Comment effectuer la transition puis commencer à utiliser le cache distribué dans, vous savez, les données relationnelles qui ont des relations et qui sont des données structurées. Alors, allons-y.
Qu'est-ce que l'évolutivité?
Donc, tout d'abord, je vais parler d'évolutivité, le concept d'évolutivité. L'évolutivité est une capacité au sein de l'application qui vous permet d'augmenter la charge transactionnelle. Où vous pouvez gérer de plus en plus de demandes chargées hors de l'architecture de l'application. Et, vous ne faites aucun compromis avec les performances, donc, si vous avez un débit élevé et une faible latence, cette capacité s'appelle l'évolutivité. Ainsi, vous pouvez gérer une énorme quantité de charges de demandes et les performances des demandes individuelles ne diminuent pas. C'est pareil! Et, avec plus de ressources, vous pouvez même augmenter cela et l'évolutivité linéaire est un terme associé qui vous permet en fait d'évoluer là où vous avez plus ou plus de capacité de traitement de charge de demande introduite dans le système en ajoutant plus de serveurs. Et, dans la plupart des cas, les performances ne diminuent pas.
Donc, si vous avez une faible latence et que vous avez une amélioration linéaire de la charge des demandes, auparavant vous traitiez, disons, 10,000 XNUMX demandes par seconde ou même pour cinq utilisateurs, vous avez une certaine latence, disons quelques millisecondes ou des temps de réponse inférieurs à la milliseconde pour cinq utilisateurs. ; vous devriez avoir le même type de réponses, le même type d'exécution, le même type de latence pour cinq mille utilisateurs ou cinquante mille utilisateurs. Et cette capacité à continuer d'augmenter la charge des utilisateurs et la charge des demandes associées, c'est ce qu'on appelle l'évolutivité linéaire.
Quelles applications ont besoin d'évolutivité ?
Alors, quelles sont les applications typiques qui ont besoin d'évolutivité,
Ce seront vos applications Web ASP.NET, vos applications Web Java ou même vos applications Web générales .NET qui sont accessibles au public. Il peut s'agir d'un système de commerce électronique, d'un système de billetterie aérienne, d'un système de réservation ou d'un service financier ou d'un service de santé dont de nombreux utilisateurs utilisent réellement son interface publique. Il peut s'agir de services Web WCF ou de tout autre service de communication qui interagit avec certaines couches d'accès aux données ou qui traite avec certaines applications frontales. Mais, il peut traiter des millions de demandes à un moment donné. Il peut s'agir de l'Internet des objets, de certains appareils back-end qui peuvent traiter des données que certaines tâches traitent pour ces appareils. Ainsi, il pourrait avoir beaucoup de demandes de charge. Le traitement de données volumineuses est un mot à la mode courant de nos jours où nous avons beaucoup de petits serveurs de calcul peu coûteux et grâce à la distribution de données sur plusieurs serveurs, vous traitez en fait une énorme quantité de charges de données.
Et, de la même manière, il y aurait une énorme charge de demandes de modèle pour ces données particulières. Et, alors pourrait être n'importe quelles autres applications serveur générales et applications de niveau qui peuvent traiter des millions de demandes, beaucoup d'utilisateurs, ce sont les meilleurs candidats pour l'évolutivité. Ce sont les applications qui ont besoin d'évolutivité au sein de l'architecture.
Goulot d'étranglement de l'évolutivité
Ceci est un schéma typique. Quel est le goulot d'étranglement de l'évolutivité ?
Donc, ce sont les applications. De par leur conception, ces frameworks sont très évolutifs. Formulaire Web ASP.NET ou formulaire WCF, il existe des options que vous pouvez utiliser pour faire évoluer ces systèmes. Mais, ils parlent tous à une base de données principale et il s'agit généralement d'une base de données relationnelle. Il peut également s'agir d'un stockage de session ASP.NET, d'un ordinateur central ou d'un système de fichiers, mais ce n'est pas ce que nous couvrons dans le webinaire d'aujourd'hui. Le webinaire d'aujourd'hui est plus axé sur les données relationnelles. Ainsi, les données relationnelles sont une source unique. Bien que vous ayez une plate-forme très évolutive ici. Vous pouvez ajouter de plus en plus de serveurs sur ce niveau. Vous pouvez évoluer en plaçant un équilibreur de charge devant et cet équilibreur de charge peut acheminer les demandes entre différents serveurs. Mais tous ces serveurs Web finissent par parler à un niveau de base de données qui n'est pas si évolutif.
Donc, ça va être une source de discorde. Il va être lent à démarrer et ensuite il ne pourra pas évoluer. C'est une source unique, il n'y a pas d'option d'ajouter de plus en plus de serveurs de base de données pour augmenter la capacité de requête. Ainsi, la capacité de requête peut atteindre son maximum et cela peut entraîner une latence élevée. Il s'agit donc d'un problème de capacité pour le traitement des demandes et cela peut également entraîner un problème de latence, ce qui peut étouffer le système lorsque vous avez une charge de demandes énorme.
La solution
C'est donc le principal problème avec les sources de données relationnelles et la solution à cela est très simple : vous commencez à utiliser un cache distribué.
Un système de cache distribué comme NCache qui est ultra-rapide car il est en mémoire en comparaison, puis il est linéairement évolutif. Ce n'est pas qu'un seul serveur. C'est un environnement de serveurs multiples où nous avons une équipe de serveurs réunis en capacité. Vous regroupez la capacité de mémoire ainsi que la capacité transactionnelle et vous obtenez un modèle très linéairement évolutif. Et, NCache est exactement ce type de solution que vous pouvez utiliser pour gérer les problèmes d'évolutivité de la base de données.
Qu'est-ce que le cache distribué en mémoire ?
Qu'est-ce qu'un système général de mise en cache distribué en mémoire comme NCache? Quelles sont les caractéristiques ?
Cluster de plusieurs serveurs de cache peu coûteux
Il s'agira d'un cluster de plusieurs serveurs de cache peu coûteux qui sont réunis en une capacité logique.
Donc, ceci en est un exemple. Vous pourriez avoir deux à trois serveurs de mise en cache. Pour NCache, vous pouvez utiliser l'environnement Windows 2008, 2012 ou 2016. Seul pré-requis pour NCache est .NET 4. Et c'est un niveau intermédiaire entre votre application et la base de données et il est très évolutif par rapport à votre niveau de base de données, mais c'est quelque chose qui vous donnerait le même type d'évolutivité que vous obtiendriez d'un web .NET accéléré formulaire ou formulaire Web des services Web WCF.
Synchronise les mises à jour du cache sur tous les serveurs de cache
Synchronise les mises à jour du cache sur tous les serveurs de cache afin que la cohérence des données soit intégrée au protocole. Toutes les mises à jour sont appliquées de manière automatique avec une compréhension de la vue cohérente des données pour tous les clients qui y sont connectés.
Échelle linéairement les transactions et la capacité de mémoire
Il devrait évoluer de manière linéaire pour les transactions ainsi qu'à partir de la capacité de mémoire, vous ajoutez simplement plus de serveurs et il ne devrait pas augmenter la capacité en réponse à cela. Si vous avez deux serveurs et que vous ajoutez un troisième et un quatrième serveur, cela devrait essentiellement doubler la capacité de ce système maintenant que vous avez le double de la quantité de service. Alors, c'est ce que NCache offre aussi.
Réplique les données pour plus de fiabilité
Ensuite, la réplication est une autre caractéristique de la fiabilité. Tout serveur qui tombe en panne, tout d'abord, il ne devrait pas y avoir de perte de données ni de temps d'arrêt. Il devrait s'agir d'un système hautement fiable et hautement disponible et c'est ce que NCache prend soin de.
NCache Déploiement
Donc, après avoir discuté de cela, vous avez un problème d'évolutivité avec les sources de données relationnelles et les systèmes de mise en cache distribués comme NCache est une solution à cela et qui devient le niveau central entre vos applications et la base de données et vos données existent à deux endroits.
Vous avez des données dans la base de données, puis vous avez des données dans le cache distribué. Donc alors NCache gère également certains problèmes de synchronisation que vous pouvez rencontrer lorsque vous avez des données sur deux sources différentes. Il existe un webinaire distinct sur ce sujet, mais, juste pour vous faire savoir qu'il existe certains fournisseurs de couches d'accès aux données, il existe des dépendances de notification de modification que vous pouvez configurer.
Ainsi, tout changement dans la base de données peut déclencher une invalidation ou une mise à jour des éléments dans le cache et de même, tout changement ou mise à jour qui se produit dans le cache peut être appliqué à la base de données. Ainsi, cela peut être réalisé avec l'aide de nos fournisseurs de couche d'accès aux données ; Lecture et écriture.
Et puis nous avons également des dépendances de changement de base de données, des dépendances de changement d'enregistrement que nous avons utilisées pour assurer une synchronisation à 100% entre la base de données et les enregistrements de cache. Mais, généralement, les données existent à deux endroits différents. Vous avez des données dans le cache qui sont généralement un sous-ensemble des données, puis vous avez des données réelles dans la base de données. Lorsque vous migrez des données, il s'agit essentiellement d'une migration de données. Bien que vous utilisiez ces deux sources en combinaison l'une avec l'autre, il s'agit de deux sources différentes.
Quelles données mettre en cache ?
Avant de poursuivre, nous parlerons rapidement des types de données que vous pouvez mettre en cache, il peut s'agir de données de référence, il peut s'agir de données transactionnelles.
Il s'agit plutôt de données intensives en lecture que vous cachez généralement, elles appartiennent à une base de données relationnelle. Ce n'est pas que ça ne change pas, ce n'est pas 100% statique. Cela change les données, mais la fréquence de ce changement n'est pas si grande. Donc, cela serait classé comme une donnée de référence. Et puis nous avons toujours des données transactionnelles qui changent très fréquemment. Aussi souvent qu'en quelques secondes, quelques minutes ou dans certains cas, cela peut être en quelques millisecondes.
Et puis la plupart des données mises en cache sont relationnelles. Il provient d'une base de données relationnelle et j'ai déjà expliqué que vous avez des données de copie principale dans la base de données relationnelle, puis que vous avez un sous-ensemble de ces données, une référence et transactionnelle, importées dans le cache distribué. À droite!
Quel est le défi ?
Alors, quel est le défi ? Alors, discutons réellement de ce défi ! Lorsque vous déplacez vos données d'une source de données vers une relation dans un cache distribué pour obtenir plus de performances, plus d'évolutivité et plus de fiabilité pour le système. Discutons simplement rapidement des défis que vous voyez.
Il fonctionne très bien. Il améliore vos performances car il est en mémoire. il est linéairement évolutif, il prend donc en charge les problèmes d'évolutivité avec la base de données. Il ne s'agit pas d'un point de défaillance unique car il existe plusieurs serveurs et n'importe quel serveur peut être arrêté. Vous pouvez mettre en place des serveurs sans aucun problème. L'entretien devient beaucoup plus facile. Vos mises à niveau deviennent beaucoup plus faciles. Donc, en comparaison, vous obtenez beaucoup d'avantages. Mais, il y a un défi que vous devez relever et vous devez en tenir compte lorsque vous migrez vos données ou déplacez vos données de la base de données vers le cache distribué et commencez à utiliser le système de mise en cache distribué.
Ainsi, le cache distribué est une table de hachage comme une interface. À droite! C'est chaque élément est séparé avec la clé et une valeur, n'est-ce pas ? Il s'agit donc d'une table de hachage où les éléments de chaque objet du cache ou chaque élément du cache ou un enregistrement du cache sont représentés à l'aide d'une clé. Donc, ce n'est pas une table ou ce n'est pas une donnée relationnelle où nous avons des relations, nous avons défini des schémas, nous avons des entités qui ont des relations appropriées entre elles. Il s'agira d'un élément de valeur clé distinct représentant un objet dans le cache. Ainsi, la base de données a des relations entre les entités et lorsque vous migrez vos données ou lorsque vous déplacez vos données d'une base de données relationnelle vers un cache distribué, vous perdez cette relation caractéristique de ces données.
Donc, par défaut, vous n'avez pas cette capacité, nous pouvons donc la supprimer. C'est l'un des principaux défis et il y a d'autres défis associés, les requêtes de base de données aboutissent à une collection d'objets. Il en résulte également une table de données ou un lecteur de données. Donc, gérer les tables de données et les lecteurs de données dans un cache distribué n'est pas une bonne idée, n'est-ce pas ? nous allons donc relever tous ces défis un par un.
Nous discuterons principalement de la façon de gérer les relations dans le cache distribué une fois que vous avez importé des données d'une source de données relationnelles dans le cache, comment vous procédez pour ce détail.
Jetez un coup d'œil dans le NCache API
Donc, nous parlerons ensuite de l'API de mise en cache.
Maintenant que nous avons discuté du fait qu'il s'agit essentiellement d'un magasin de valeur clé. Nous avons un cache.add où nous avons une clé "mykey", puis nous avons un objet qui est toutes les données autorisées et l'objet sérialisé autorisé. il peut s'agir de n'importe quel objet client, objet produit, objet commande. Mais c'est un exemple très simple de hello world où nous appelons des méthodes de valeur de clé en utilisant cache.add, cache.update. De même, nous appelons cache.get pour récupérer le même élément, puis nous appelons cache.remove.
Gérer les relations dans le cache
Passons à autre chose ! Alors, comment gérer les relations dans le cache ? Maintenant que nous avons défini ce défi, le cache est une table de hachage comme une interface, c'est une paire clé-valeur. La valeur est un objet .NET et la clé est une clé de chaîne que vous formatez et ce sont des objets indépendants les uns des autres. Et, la base de données a des tables de relations qui ont des relations les unes avec les autres. Il peut s'agir d'une relation un-à-un un-à-plusieurs et plusieurs-à-plusieurs entre différentes tables.
Première étape : utiliser la dépendance au cache
Il y a deux choses que vous devriez envisager de faire tout d'abord, vous devriez envisager d'utiliser la dépendance de cache et nous nous concentrons principalement sur la dépendance basée sur les clés qui est l'une des fonctionnalités et je vais vous montrer quelques exemples de code autour de cela qui vous aide à garder un suivi de la dépendance à sens unique entre les éléments du cache.
Ainsi, vous pourriez avoir un objet parent et ensuite vous pourriez avoir un objet dépendant de cet objet particulier. Et, la façon dont cela fonctionne est qu'un élément dépend d'un autre. L'élément principal, l'objet principal ou l'objet parent ; s'il subit une modification, il est mis à jour ou supprimé, l'élément dépendant est automatiquement supprimé du cache.
Un exemple typique que j'ai aligné dans les diapositives à venir est la liste des commandes pour un certain client. Donc, vous avez un client A. Il a une liste de commandes, disons 100 commandes, et si ce client est mis à jour ou supprimé du cache. Vous n'avez pas besoin de ces commandes associées à cela, vous voudrez peut-être également faire quelque chose autour de la collecte de ces commandes et c'est exactement à quoi sert cette dépendance pour laquelle vous devez avoir un lien entre ces 2 enregistrements car ils sont liés dans le dans le base de données relationnelle.
Ensuite, cette dépendance peut également être de nature en cascade où A dépend de B et B dépend de C. Tout changement dans le C déclencherait une invalidation de B et cela invaliderait à son tour A également. Ainsi, il pourrait s'agir d'une dépendance en cascade, puis également d'une dépendance multi-éléments. Un élément peut dépendre de l'élément A ainsi que de l'élément B et, de la même manière, un élément parent peut également avoir plusieurs éléments enfants. Et, c'était une fonctionnalité initialement introduite par le cache ASP.NET. C'était l'une des fonctionnalités puissantes qui NCache a aussi. Nous le fournissons en tant qu'objet de dépendance de cache séparé et l'un des objets les plus fantaisistes et cela va être l'objectif principal de ce webinaire particulier.
Deuxième étape : utiliser le mappage relationnel d'objet
Deuxième étape, afin de mapper vos données relationnelles, il y a un autre défi pour lequel nous vous recommandons de mapper vos objets de domaine sur votre modèle de données, n'est-ce pas ?
Ainsi, vos objets de domaine doivent représenter une table de base de données. Vous devez utiliser une sorte de mappage O/R, vous pouvez également utiliser certains outils de mappage O/R. Cela simplifie votre programmation, vous pouvez réutiliser le code une fois que vous avez mappé des classes sur vos tables de base de données. Vous pouvez également utiliser les outils de mappage ORM ou O/R tels que Entity Framework et NHibernate. Ce sont quelques outils populaires.
L'idée ici est que vous devriez avoir des classes dans l'application. Les objets, les objets du domaine dans l'application. Ainsi, vos objets de base de données, tables de données ou lecteurs de données sont transformés en correspondance avec les objets du domaine. Ainsi, une table de clients doit représenter une classe de clients dans l'application. De même, la collection ordonnée ou la table de commande doit représenter la classe de commande et l'application. Et puis ce sont les objets que vous traitez et stockez dans le cache distribué et formulez des relations à l'aide de Key Dependency.
Exemple de gestion des relations
Prenons un exemple !
Et, nous avons notre modèle de base de données de Northwind. Nous avons la table des clients, nous avons la table des commandes, puis nous avons le produit. Nous avons tous les noms de colonne du client, nous avons l'ID client, le nom de l'entreprise, le téléphone, la ville, l'état, le pays, certains attributs. De même, nous avons un produit avec l'ID du produit, le nom, le prix, les unités en stock, les unités en commande, le niveau de réapprovisionnement. Donc, ce sont des attributs ou des colonnes du produit, puis nous avons également une table de commande qui a l'ID client et l'ID produit comme clés étrangères. C'est la formulation d'une clé primaire composite, puis nous avons la date de commande, la date d'expédition et certains attributs des commandes elles-mêmes. Et si vous remarquez cela, il existe une relation un à plusieurs entre le client et la commande, puis une relation un à plusieurs entre le produit et la commande. De même, nous avons plusieurs à un et plusieurs à un entre la commande et le client et la commande et le produit, respectivement. Nous allons donc nous attaquer à ce scénario particulier.
Initialement, c'était la relation plusieurs-à-plusieurs du produit client qui a été normalisée en deux relations un-à-plusieurs. Il s'agit donc d'un modèle de données normalisé et nous en utiliserons un exemple où nous avons une classe au niveau de l'objet principal mappé sur ce modèle de données particulier. Donc, nous parlerons de l'objet principal dans un instant, mais laissez-moi vous montrer rapidement l'exemple ici.
Notez que les objets de domaine sont mappés sur notre modèle de base de données. Pour ce même exemple, nous avons une classe de clients qui a un ID client qui va être utilisé comme clé primaire, puis nous avons une collection de commandes qui représente trop de relations avec la classe de commandes. De même, nous avons un produit qui a les mêmes attributs de produit que ces ID de produit, nom, prix unitaire, n'est-ce pas ? Et puis nous avons également la collecte des commandes ici qui représente une relation un-à-plusieurs et du côté de la commande, nous avons l'ID client apporté d'ici l'ID produit apporté d'ici, puis nous avons le client donneur d'ordre, le client plusieurs-à- une relation, puis nous avons le produit de commande tant à une relation capturée dans le cadre de l'objet de domaine.
C'est donc l'une des techniques que je vais couvrir en détail dans les prochaines diapositives. Permettez-moi de vous montrer également ces objets dans Visual Studio, donc celui-ci fait partie de la classe.
using Alachisoft.NCache.Web.Caching;
using Alachisoft.NCache.Runtime;
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using Alachisoft.NCache.Runtime.Dependencies;
using System.Collections;
namespace Relationships
{
public class Customer
{
public long CustomerId;
public string CompanyName;
public string Phone;
public string City;
public string State;
public string Country;
// one-to-many list of Order objects
public IList<Order> Orders;
public void CacheCustomer(Cache cache, Customer cust)
{
// Let's preserve "orders"
IList<Order> orders = cust.Orders;
// Let's now empty "orders" so it doesn't get cached with customer
cust.Orders = null;
string custKey = "Customer:CustomerId:" + cust.CustomerId;
cache.Add(custKey, cust, null,
Cache.NoAbsoluteExpiration,
Cache.NoSlidingExpiration,
CacheItemPriority.Default);
// Dependency ensures orders is removed if Cust updated/removed
string[] keys = new string[1];
keys[0] = custKey;
CacheDependency dep = new CacheDependency(null, keys);
string orderskeys = "Customer:Orders:CustomerId:" + cust.CustomerId;
cache.Add(orderskeys, orders, dep,
Cache.NoAbsoluteExpiration,
Cache.NoSlidingExpiration,
CacheItemPriority.Default);
}
public void CacheProducts(Cache cache, double unitPrice, IList<Product> products)
{
// Let's cache each product as seperate item. Later
// we'll search them through OQL
foreach (Product product in products)
{
string productKey = "Product:ProductId:" + product.ProductId;
cache.Add(productKey, product, null,
Cache.NoAbsoluteExpiration,
Cache.NoSlidingExpiration,
CacheItemPriority.Default);
cache.GetGroupData("DummyGroup", "DummySubGroup");
cache.GetByTag(new Alachisoft.NCache.Runtime.Caching.Tag("DummyTag"));
}
}
public IList<Product> FindProducts(Cache cache, double unitPrice)
{
string query = "SELECT Relationships.Product WHERE this.UnitPrice >= ?";
Hashtable values = new Hashtable();
values.Add("UnitPrice", unitPrice);
ICacheReader products = cache.ExecuteReader(query, values, true);
IList<Product> prodList = new List<Product>();
// For simplicity, assume that list is not very large
while (products.Read())
{
prodList.Add((Product)products.GetValue(1));// 1 because on 0 you'll get the Cache Key
}
return prodList;
}
}
}Une chose que je recommanderais est de décorer ces classes avec une balise sérialisable, n'est-ce pas ? Donc, vous devez les mettre en cache, non ? Ainsi, ces objets de domaine doivent être sérialisés car ce sont eux qui vont faire des allers-retours entre votre application cliente et le cache distribué.
Donc, nous avons une classe de clients, nous avons une classe de produits, ici même. Une liste de commandes et nous avons une classe de commande qui possède également tous les attributs indiqués sur la diapositive de présentation.
Qu'est-ce que l'objet principal ?
Ensuite, nous parlerons de l'objet principal. Maintenant que nous avons montré quelques objets principaux qui sont mappés sur ce modèle de données de domaine. Nous allons vous montrer quelques techniques pour passer en revue les relations un-à-un, un-à-plusieurs et plusieurs-à-plusieurs.
Donc, tout d'abord, je vais parler d'un terme que j'utiliserai dans les diapositives à venir.
Objet principal, c'est un objet de domaine. Il est mappé sur votre base de données. C'est un point de départ de votre application, par exemple, vous avez un objet client, puis si vous avez besoin de commandes, vous avez besoin du client pour commencer, n'est-ce pas ? Donc, c'est le premier objet que votre application récupère et tous les autres objets qui y sont liés vont être mis en relation avec celui-ci, n'est-ce pas ?
Un autre exemple pourrait être si vous traitez les commandes correctement, vous voudrez peut-être récupérer les commandes dans cette unité de traitement et vous aimeriez ensuite connaître le client qui l'a commandé pour expédier cette commande particulière, n'est-ce pas ? Ainsi, dans ce cas, la commande devient votre objet principal, puis elle a une relation plusieurs à un ou elle a une relation avec l'un des clients qui a réellement commandé cette commande particulière ou tous les produits de cette commande. Donc, ça va être d'une manière ou d'une autre mais nous donnerons que nous utiliserons un objet principal qui sera mis en cache et ensuite nous rendrons d'autres objets dépendants de cela. C'est l'approche qui suivra.
Relations dans le cache distribué
Alors, commençons réellement avec ça. Donc, tout d'abord, nous allons parler des relations un-à-un et plusieurs-à-un dans le cache distribué qui est le scénario le plus courant, n'est-ce pas ? Ainsi, une option consiste à mettre en cache les objets associés avec l'objet principal. Maintenant que vous avez vu nos objets de domaine, nous avons une liste de commandes dans le cadre des clients. Donc, si nous remplissons ces commandes et que le client en fait partie, si vous stockez le client comme un seul objet dans le cache qui contient toutes les commandes, n'est-ce pas ? Donc, cela ferait le travail.
Objet lié au cache avec objet principal
Donc, voici un exemple de code pour cela.
// cache order along with its OrderingCustomer and OrderedProduct
// but not the "Orders" collection in both of them
public void CacheOrder(Cache cache, Order order)
{
// We don't want to cache "Orders" from Customers and Product
order.OrderingCustomer.Orders = null;
order.OrderedProduct.Orders = null;
string orderKey = "Order:CustoimerId:" + order.CustomerId
+ ":ProductId:" + order.ProductId;
cache.Add(orderKey, order, null,
Cache.NoAbsoluteExpiration,
Cache.NoSlidingExpiration,
CacheItemPriority.Default);
}Nous avons une commande de cache, nous définissons le client donneur d'ordre dans la commande sur "null". Très bien! Ainsi, nous n'avons pas de commandes ayant également une référence au client. C'est redondant. Ce n'est pas une très bonne pratique de programmation, mais c'est juste pour faire respecter. Nous ne voulons pas mettre en cache les commandes du client et de l'ID produit. Donc, nous voulons juste avoir un client ajouté dans le cache, puis nous aimerions simplement avoir des commandes dans le cadre de cela.
Alors, regardons ça, n'est-ce pas ? Donc, nous définissons ceci sur null, puis nous le stockons simplement ou si nous ne le définissons pas sur null, cela peut en fait avoir une référence à cela. De même, si nous avons un client, n'est-ce pas ? donc si nous ne définissons pas la commande sur null bien qu'il s'agisse d'un objet distinct mais si nous stockons simplement ce client, laissez-moi vous y amener, car il contient une liste de commandes, si nous stockons simplement ce client en tant que objet unique dans le cache, il a notre collection de commandes dans le cadre de cet objet. Bien que je le définisse null pour un autre exemple, mais juste pour vous montrer ce cas particulier, vous pouvez trier un gros objet et il aurait tous les objets liés dans le cadre de cet objet.
Donc, vous devez commencer à partir de votre objet de domaine, votre relation doit être capturée dans le cadre de l'objet de domaine et vous devez le faire malgré tout. Et, après cela, vous devriez mettre en cache, vous devriez en fait avoir une liste remplie de commandes, une liste d'objets associés dans le cadre de cela. C'est donc l'approche la plus simple que vous puissiez obtenir.
Il y a des avantages à ce que vous ayez un objet qui représente tout. Mais, il y a aussi quelques inconvénients. Ce serait un objet plus grand en taille. Dans certains cas, vous avez juste besoin d'un client, mais vous finirez par recevoir des commandes dans le cadre de cela. Vous aurez affaire à une charge utile plus importante. Et, vous n'avez pas de commandes granulaires en tant qu'éléments distincts dans le cache, vous devrez donc gérer la collecte de commandes tout le temps, même si vous n'êtes intéressé que par une seule, n'est-ce pas ? Donc, c'est une approche. C'est le point de départ.
Mettre en cache les objets associés séparément
Deuxièmement, vous cachez l'objet pondéré en tant qu'élément distinct dans le cache.
public void CacheOrder(Cache cache, Order order)
{
Customer cust = order.OrderingCustomer;
// Set orders to null so it doesn't get cached with Customer
cust.Orders = null;
string custKey = "Customer:CUstomerId:" + cust.CustomerId;
cache.Add(custKey, cust, null,
Cache.NoAbsoluteExpiration,
Cache.NoSlidingExpiration,
CacheItemPriority.Default);
// Dependency ensures order is removed if Cust updated/removed
string[] keys = new string[1];
keys[0] = custKey;
CacheDependency dep = new CacheDependency(null, keys);
string orderKey = "Order:CustomerId:" + order.CustomerId
+ ":ProductId:" + order.ProductId;
cache.Add(orderKey, order, dep,
Cache.NoAbsoluteExpiration,
Cache.NoSlidingExpiration,
CacheItemPriority.Default);
}Un exemple pour cela est la classe de commande où nous avons la commande de cache, n'est-ce pas ? Donc, c'est l'exemple où nous avons un client. Tout d'abord, non ? Et puis nous stockons le client en tant qu'objet unique, vous pouvez voir que nous avons reçu la commande, puis à partir de la commande, nous avons extrait le client, puis nous avons défini la collection de commandes dans cet objet client sur null, n'est-ce pas ? Donc, c'est quelque chose que vous devriez faire dans le constructeur, mais cela est fait ici juste pour faire en sorte que cet objet client n'ait pas cette commande dans le cadre de cela. Et, ensuite, vous stockez ce client en tant qu'objet unique. Ce que nous faisons ici, c'est que nous créons une clé client qui est le client, l'ID client, le paramètre d'exécution, puis nous stockons notre client en tant qu'objet unique dans le cache.
La prochaine chose que nous faisons est de créer une dépendance de cache. Donc, nous avons parlé de deux étapes que nous voulions faire, une étape consistait à mapper votre modèle de données sur votre objet de domaine, de sorte que vos objets de domaine doivent représenter une table relationnelle dans la base de données, puis une fois que vous prévoyez de les mettre en cache, vous avez l'objet principal dans ce cas, il s'agit du client, puis nous avons des commandes liées au client dans la relation un-à-plusieurs. Vous créez une dépendance entre le client et la collection de commandes à l'aide d'un objet de dépendance de cache. Vous créez une dépendance de cache. Cette même dépendance de cache prend deux paramètres ; le premier est un fichier, n'est-ce pas ? Donc, cela peut dépendre du nom du fichier et cela peut aussi dépendre de la clé, n'est-ce pas ? Donc, nous définissons le premier paramètre sur null. Donc, nous ne voulons pas que cela dépende d'aucun fichier.
Il y a une autre caractéristique qui dans NCache où vous pouvez rendre les éléments dépendants d'un certain système de fichiers certains fichiers de votre système de fichiers. Et, ensuite, si vous utilisez la dépendance basée sur la clé, elle a besoin de la clé de l'élément parent dont l'élément enfant va dépendre. Et, ensuite, nous construisons la clé de commande de la collection de la commande. Nous avons ici toute la collection de commandes qui est transmise à cette méthode, puis nous appelons simplement Cache.Add order.
Désormais, le client et la commande sont liés l'un à l'autre. Nous avons une liste des commandes de ce client qui sont représentées comme un objet séparé dans le cache, donc chaque fois que vous avez besoin de toutes les commandes de ce client particulier, il vous suffit d'utiliser cette clé. Tout ce que vous avez à faire est d'appeler, permettez-moi d'utiliser cet exemple ici. Je suis désolé! Vous pouvez appeler Cache.Get, puis vous transmettez simplement la clé de commande et cela vous rapportera cette commande particulière que nous avons construite dans cette méthode, n'est-ce pas ?
C'est donc ce dont vous avez besoin pour récupérer simultanément toute la collection de toutes les commandes de ce client particulier. Mais que se passe-t-il si le client subit un changement ? Si le client est mis à jour, la collecte des commandes n'a pas besoin de rester dans le cache. Il peut être supprimé ou, dans certains cas, il peut également être mis à jour, n'est-ce pas ?
Donc, c'est notre approche numéro deux qui est plus sophistiquée en termes de stockage, en termes de convivialité et elle mappe également deux enregistrements dans notre relation de relation un-à-plusieurs ou relation plusieurs-à-un. Il pourrait également s'agir d'un autre moyen que nous couvrirons un peu où vous pouvez avoir des listes de commandes et chaque commande peut être mappée sur ces commandes individuelles peut être mappée sur ces multiples commandes d'identification peuvent être mappées sur un client si la commande est l'objet principal de ce code d'application particulier. Maintenant, cela définit une relation entre le client et les commandes.
Quelques détails supplémentaires sur la fonctionnalité de dépendance au cache.
Si je vais ici, c'est d'abord exposé mais avec l'aide de Alachisoft.NCache.Runtime.Dependencies et c'est l'une des surcharges que vous utilisez, puis vous utilisez simplement cette méthode particulière, ici. Et, le comportement de ceci est tel qu'il vous permet de suivre simplement la dépendance à sens unique entre les objets et il pourrait également être mis en cascade comme indiqué précédemment dans la présentation.
Relation un à plusieurs
Ensuite, nous parlerons des relations un-à-plusieurs. Puisque nous avons parlé d'un à un ou de plusieurs à un où nous avions une commande, puis nous avions un client, cela ressemble donc à un à plusieurs dans la plupart des cas, mais comme c'était le point de départ, c'était la commande, puis nous avons inséré le client, stocké le client, puis nous stockons la collecte des commandes, puis nous avons défini une relation plusieurs à un entre la collecte des commandes et ce client.
Maintenant, la relation un-à-plusieurs, ça va être très similaire à ce dont nous avons discuté. Notre première option consiste à mettre en cache votre collection d'objets dans le cadre de l'objet principal, de sorte que le client est votre objet principal, la commande doit en faire partie.
Le deuxième élément est que vos objets associés sont mis en cache séparément, mais des éléments individuels dans le cache, n'est-ce pas ?
Un à plusieurs - Collection d'objets liés au cache séparémentpublic void CacheCustomer(Cache cache, Customer cust)
{
// Let's preserve "orders"
IList<Order> orders = cust.Orders;
// Let's now empty "orders" so it doesn't get cached with customer
cust.Orders = null;
string custKey = "Customer:CustomerId:" + cust.CustomerId;
cache.Add(custKey, cust, null,
Cache.NoAbsoluteExpiration,
Cache.NoSlidingExpiration,
CacheItemPriority.Default);
// Dependency ensures orders is removed if Cust updated/removed
string[] keys = new string[1];
keys[0] = custKey;
CacheDependency dep = new CacheDependency(null, keys);
string orderskeys = "Customer:Orders:CustomerId:" + cust.CustomerId;
cache.Add(orderskeys, orders, dep,
Cache.NoAbsoluteExpiration,
Cache.NoSlidingExpiration,
CacheItemPriority.Default);
}Donc, c'est une collection qui est séparée, nous avons des commandes, nous avons un objet client ici un à plusieurs et le client a des commandes, nous en avons extrait la collection de commandes, puis nous définirons les commandes client sur null afin que le client soit un e objet, un objet principal, la collecte des commandes est un objet distinct, puis vous stockez le client, stockez la dépendance du cache de données et stockez les commandes. Donc, ça va être un un-à-plusieurs toute la collection.
Un à plusieurs - Mettez en cache chaque objet dans la collection associée séparémentLa deuxième approche est que cette collection peut également être décomposée.
public void CacheCustomer(Cache cache, Customer cust)
{
// Let's preserve "orders"
IList<Order> orders = cust.Orders;
// Let's now empty "orders" so it doesn't get cached with customer
cust.Orders = null;
string custKey = "Customer:CustomerId:" + cust.CustomerId;
cache.Add(custKey, cust, null,
Cache.NoAbsoluteExpiration,
Cache.NoSlidingExpiration,
CacheItemPriority.Default);
// Dependency ensures orders is removed if Cust updated/removed
string[] keys = new string[1];
keys[0] = custKey;
CacheDependency dep = new CacheDependency(null, keys);
// Let's cache each order as seperate item but assign it
// a group so we can fetch all orders for a given customer
foreach (Order order in orders)
{
string orderKey = "Order:CustomerId:" + order.CustomerId
+ ":ProductId:" + order.ProductId;
CacheItem cacheItem = new CacheItem(order);
cacheItem.Group = "Customer:CustomerId:" + cust.CustomerId;
cacheItem.Dependency = dep;
cache.Add(orderKey, cacheItem);
}
}La collection de commandes peut être séparée, chaque élément de cette collection peut être un élément distinct dans le cache. Donc, dans ce cas, nous utiliserions simplement la même approche. Nous obtiendrons les clients, obtiendrons les commandes, stockerons le client, créerons une dépendance de ce client en utilisant une dépendance clé, puis nous parcourrons toutes les commandes.
Permettez-moi de passer par la méthode du client de cache ici, car c'est plus intuitif ici. Donc, nous en obtenons la collecte des commandes, nous définissons les commandes des clients sur null afin que les clients ne concernent que le client, stockons le client dans le cache à l'aide de cache.Add key, construisons une dépendance de cache autour d'une clé particulière du client et puis nous parcourons simplement. Il y a une boucle par ici. Nous devrions en fait le parcourir et c'est en fait mieux de le parcourir, puis nous le stockons simplement en tant qu'éléments individuels dans le cache afin que la commande ait sa propre clé dans chaque commande soit un élément distinct dans le cache. Et, puis une autre chose que nous avons faite est que nous avons en fait regroupé ces éléments que nous appelons les éléments de cache ajouter un groupe et l'ID client est également un groupe. Donc, nous gérons également une collection à l'intérieur du cache.
Permettez-moi de voir si j'ai .. voilà en fait, par exemple, nous avons ceci ici. Nous pourrions en fait mettre ces produits en cache, c'est un autre exemple en passant, où nous avons bouclé toute la collection de produits, puis nous les avons stockés individuellement, puis nous avons en fait tout mis dans un groupe, n'est-ce pas ?
Ainsi, ce produit qui est stocké en tant qu'élément peut également être stocké comme ceci où nous avons un ProdCacheItem. Mon clavier joue, alors s'il vous plaît, soyez indulgent avec moi ! Utilisons cela pour l'instant et ensuite je vais faire simplement. Je peux effectivement ajouter un groupe. Donc, c'est ainsi que cela me permettrait en fait de créer un groupe pour cela. Disons groupe factice maintenant. Si je stocke cet élément de cache et qu'il pourrait en fait avoir un produit comme élément pour cela, n'est-ce pas ? Ainsi, au lieu de stocker l'objet brut réel, je peux même l'organiser dans un groupe. Je peux simplement utiliser l'élément de cache produit. Voilà! À droite? Donc, maintenant, c'est en fait ou au lieu d'utiliser le groupe factice, disons le groupe de produits, et quand j'ai besoin de le récupérer, je peux simplement utiliser le groupe de produits et cela me rapporterait tous les articles de cette collection à la fois. Bien que ceux-ci soient stockés individuellement, ce sont des appels Cache.Get individuels, les produits individuels de la collection de produits sont triés individuellement, mais je peux les organiser en groupe dans une collection, puis je peux les récupérer. Mais ce qui est bien, c'est qu'il utilise toujours une dépendance, n'est-ce pas ? Donc, il utilise une dépendance d'un client sur ces éléments individuels.
Alors, prenons un exemple, nous avons un client il a une centaine de commandes. Ainsi, au total, nous aurions un article pour le client dans le cache, nous aurions cent commandes stockées séparément sous forme de cent articles dans le cache et il existe une dépendance à sens unique entre ce client et cent commandes. Si vous supprimez ce client du cache, cent commandes seront invalidées d'un coup. Et, maintenant, vous avez l'avantage de récupérer des commandes individuelles, si vous en avez besoin. Ainsi, vous pouvez interagir avec ces éléments individuellement. Un élément à la fois. Vous avez besoin d'une certaine commande que vous pouvez traiter et lorsque vous avez besoin de la collection complète de ces commandes à la fois, vous pouvez simplement appeler Cache.GetGroupData et fournir le groupe de produits, puis le sous-groupe peut être n'importe quoi. Il pourrait même être nul et vous pouvez également utiliser la balise.
Par example; l'autre façon de gérer cela est que vous utilisez l'élément de produit et que vous créez une balise pour celui-ci, n'est-ce pas ? Et puis vous... il y a un... ouais ! le voilà et vous pouvez fournir une étiquette qui peut ressembler à une étiquette de produit, n'est-ce pas ? et ensuite vous pouvez associer ceci dans le cadre de cela.
Donc, cela fonctionnerait en fait sur les mêmes lignes et vous pouvez également appeler les méthodes get by tag et cela prendrait en charge tous les éléments à la fois. Il vous apporterait tous les articles à la fois. Ainsi, cela vous donnerait plus de contrôle sur votre disposition des données dans le cache tout en gardant intacte une relation un-à-plusieurs.
Donc, cela prend en charge un scénario très particulier où nous avons une relation un-à-plusieurs et nous avons un objet ajouté, puis nous avons ces éléments du côté plusieurs que la collection stocke individuellement les éléments de cette collection stockés individuellement dans le cache, puis vous avez toujours une dépendance, puis vous avez toujours un type de comportement de collection pour cela avec ces éléments associés. Ainsi, ces éléments sont liés les uns aux autres, ils forment une collection, puis ils ont notre relation avec un autre objet dans une formulation un-à-plusieurs. Ainsi, cet extrait de code, une API intuitive très simple, prend en charge tous ces scénarios. Vous avez une relation un-à-plusieurs capturée à l'aide d'une dépendance de clé. Vous avez organisé ces éléments individuellement dans le cache, mais vous les avez toujours placés dans une collection logique de groupes ou de balises, puis lorsque vous avez besoin de ces éléments individuellement, vous appelez cache start get, n'est-ce pas?
Donc, une façon d'obtenir cet élément est d'appeler Cache.Get, n'est-ce pas ? et utilisez la clé qui est la clé de produit ici, n'est-ce pas ? Donc, cela vous rapporterait ce produit particulier qui est stocké avec cette clé particulière, n'est-ce pas ? Et, l'autre option est que vous avez besoin de tous les éléments de cette collection à la fois pour pouvoir utiliser Cache.GetGroupData. Ainsi, il peut vous donner un comportement de collecte et en même temps, il peut également vous donner la gestion individuelle de ces éléments connexes.
Donc, cela devrait prendre en charge les collections et les éléments de la collection et un à plusieurs à la fois.
Relations plusieurs à plusieurs
Ensuite, nous avons une relation plusieurs à plusieurs.
Les relations plusieurs-à-plusieurs n'existent généralement pas dans les objets de domaine. Il sera toujours normalisé en deux relations un-à-plusieurs dans la base de données également. En fait, nous avions une relation plusieurs à plusieurs entre le client et les produits. Relations plusieurs-à-plusieurs que nous avons normalisées à l'aide d'un objet intermédiaire en deux relations un-à-plusieurs. Donc, nous avons un à plusieurs ici et plusieurs à un ici entre la commande client et la commande au produit, respectivement. Donc, c'est ainsi que vous traiteriez plusieurs à plusieurs. Ainsi, il finirait par utiliser des relations un-à-un plusieurs-à-un ou un-à-plusieurs.
Donc, cela devrait prendre soin de vos relations plusieurs à plusieurs.
Gestion des collections dans le cache distribué
Ensuite, vous avez une collection, nous l'avons déjà abordé à l'aide de notre exemple de produit, mais je vais quand même passer en revue que vous cachez dans notre collection en tant qu'élément unique.
Par exemple, vous stockez le produit. Allons-y, n'est-ce pas?
public void CacheProducts(Cache cache, double unitPrice, IList<Product> products)
{
// cache the entire collection as one item
string productskey = "Product:UnitPrice:" + unitPrice;
cache.Add(productskey, products, null,
Cache.NoAbsoluteExpiration,
Cache.NoSlidingExpiration,
CacheItemPriority.Default);
}
public IList<Product> FindProducts(Cache cache, double unitPrice)
{
string productskey = "Product:UnitPrice:" + unitPrice;
IList<Product> products = (IList<Product>)cache.Get(productskey);
return products;
}Donc, vous avez des produits en cache, vous créez donc une clé de produit, puis vous avez la liste des produits qui sont apportés ici, puis vous les cachez et avez un seul objet. Et, comme je l'ai expliqué plus tôt, cela fonctionnera, cela vous permettra de faire le travail et cela fonctionnera surtout lorsque vous aurez besoin de tous les éléments de cette liste en même temps. Vous n'êtes pas intéressé par les éléments individuels de cette liste. Vous êtes entièrement intéressé par la liste complète du magasin comme un seul élément, mais cela alourdira l'objet, il ne vous donnera pas de support pour le codage, la recherche et c'est notre sujet suivant. Parce que c'est une liste générique, je liste, elle contient un produit mais pour NCache ce n'est qu'une liste, je liste. À droite! Ainsi, vous n'êtes pas en mesure d'identifier l'objet dans cette liste, puis les attributs, puis vous n'avez pas la possibilité de rechercher en fonction de ces attributs.
Ainsi, une manière plus sophistiquée de gérer cela consiste à mettre en cache chaque élément de collection séparément. Ce que nous avons couvert dans le cadre de notre exemple précédent, mais revenons-y une fois de plus. Par example; passons en revue les produits du cache une fois de plus et stockez-les simplement en tant qu'éléments individuels. Laissez-moi trouver cet exemple pour vous ! D'ACCORD! Le voilà.
Donc, tout d'abord, nous allons stocker les produits individuellement, n'est-ce pas ? Nous aurons une clé construite autour de cela pour les produits individuels. La bonne chose à ce sujet est que tous les éléments individuels de la collection de produits sont stockés en tant qu'éléments individuels dans le cache afin que vous puissiez les récupérer à l'aide de la clé qui est la surcharge pour cela, la méthode pour ce Cache.Get. Vous pouvez également les récupérer en tant que collection. C'est quelque chose dont nous avons discuté en détail. Une autre option consiste à exécuter également des requêtes et ces requêtes de recherche de type SQL peuvent être appliquées directement sur les attributs des objets. Et, vous ne pouvez le faire que si vous les avez stockés individuellement, tous les éléments de la collection sont stockés en tant qu'éléments individuels. Vous les mappez sur un objet de domaine, un produit dans ce cas, et les produits d'une collection de produits sont stockés individuellement en tant qu'éléments distincts dans le cache.
Vous pouvez maintenant indexer le prix unitaire du produit, l'ID du produit, puis exécuter une requête comme celle-ci. Sélectionnez le produit, c'est l'espace de noms du produit, où cela définit le prix unitaire égal à un paramètre d'exécution. Et, ensuite, vous pouvez appeler Cache.ExecuteReader et cela vous récupèrera tous les produits que vous pouvez parcourir et continuer à récupérer dans votre application également. De même, vous pouvez également dire où This.Tag. Si vous avez associé une balise au-dessus, vous pouvez également exécuter des requêtes à ce sujet. C'est un autre avantage des balises ainsi que des avantages de récupération, des avantages de performances, cela vous donne également de la flexibilité du point de vue de la recherche. Et, les balises vous donnent également Cache.Get par une balise. Il vous donne toutes les API, obtenez par toutes les balises obtenez par toutes les balises, de sorte que vous pouvez également récupérer des objets à l'aide de ces API de balises. Mais, la caractéristique que je voulais souligner est que vous les organisez individuellement. C'est le point de départ. Vous créez des collections logiques à l'aide de balises ou de groupes. Ainsi, la récupération est plus facile. Vous avez besoin d'éléments individuels que vous appelez Cache.Get. Obtenez les éléments en fonction de la clé. Vous avez besoin que les collections utilisent le groupe ou la balise apparaisse et en plus, vous pouvez exécuter des requêtes et vous pouvez associer, vous pouvez réellement récupérer nos éléments en fonction d'un critère.
Dans ce cas, il pourrait s'agir d'un prix unitaire. Il pourrait s'agir d'un prix unitaire supérieur à 10 et inférieur à cent. Ainsi, les opérateurs logiques sont pris en charge, vous pouvez également avoir une agrégation, compter, somme, il y a un ordre de tri par un groupe par opérateur similaire en fonctionnement, donc c'est assez excitant en ce qui concerne le support, c'est similaire à SQL c'est un sous-ensemble de Requêtes SQL, mais son utilisation est très flexible et vous offre une grande facilité d'utilisation en termes d'éléments dont vous avez besoin. Vous n'avez plus besoin de travailler avec des clés. Donc, cela ne se produirait que si vous utilisiez simplement chaque élément de collection stocké séparément dans le cache. J'espère que cela aide.
Commencer avec NCache
Cela complète notre sujet d'aujourd'hui. Vers la fin, je vais juste vous montrer cinq étapes simples pour commencer avec NCache juste passer par-dessus NCache configurations et être ensuite en mesure d'exécuter ces API dans une application réelle.
D'accord! Donc, je vais commencer rapidement avec ça. J'ai ouvert l'outil de gestion. Au fait, nous avons récemment publié, en fait nous venons de publier la version 4.9. Donc, c'est notre dernière version, donc vous voudrez peut-être commencer avec ça. Donc, tout ce que vous avez à faire est de créer un cache, par son nom, choisissez ensuite, choisissez une topologie de mise en cache, le cache de réplique de partition est le plus approprié, l'option asynchrone pour la réplication et ici vous spécifiez les serveurs qui vont héberger ce cache. J'ai démo un et deux déjà installé avec NCache.
Donc, la première étape consiste à télécharger et à installer NCache. La deuxième étape consiste à créer un cache nommé. Donc, je vais le parcourir, tout garder par défaut parce que ce n'est pas le sujet principal de la discussion aujourd'hui. Je vais juste passer en revue les valeurs par défaut et la taille du cache qui se trouve sur chaque serveur. Configurez simplement les paramètres de base et choisissez la finition.
La troisième étape consiste à ajouter un nœud client. Je vais juste utiliser ma machine. Voir si j'y ai accès, oui ! Très bien! Donc, c'est ma machine ici. J'ai ajouté cela pour que la troisième étape soit terminée. Toutes les configurations sur le serveur et dans le client sont terminées. Je dois maintenant démarrer et tester ce cluster de cache dans le cadre de mon étape 4, puis je l'examinerai et l'utiliserai ensuite dans une application réelle. Donc, c'est aussi simple que ça de commencer NCache.
Je vais vous montrer quelques compteurs rapides pour vous montrer les choses en action, puis nous conclurons rapidement la présentation également. Je clique avec le bouton droit de la souris et je choisis des statistiques qui ouvriraient des compteurs de performances et je peux également ouvrir des outils de surveillance qui sont NCache moniteur, est installé avec NCache.
Donc, c'est un compteur de performances. Il vous donne des compteurs de performances côté serveur et des compteurs de performances côté client également. Et, du côté de l'application client, je peux exécuter cette application d'outil de test de stress qui est à nouveau installée avec NCache. Il prend le nom car il y a des configurations faites pour qu'il se connecte automatiquement au cache et commence à simuler la charge sur mon cluster de cache. Voilà! Donc, nous avons une charge de demande qui arrive ici ainsi que sur l'autre serveur.
De même, nous avons une activité affichée sur ce serveur ainsi que des clients connectés au serveur et au client de visualisation de rapports. Et puis vous pouvez également avoir vos propres tableaux de bord personnalisés où vous pouvez brancher l'un de ces compteurs. Par exemple, les journaux d'API sont un bon exemple. Il enregistre toutes les requêtes en cours d'exécution sur le cache en temps réel, n'est-ce pas ?
Donc, c'est un exemple rapide d'utilisation de ces compteurs à partir de la main gauche. Comme je l'ai dit, c'est juste pour vous donner une idée de l'apparence de la mise en cache. Maintenant, je peux réellement l'utiliser dans une application réelle. Je peux utiliser ma machine ici et je peux simplement utiliser un exemple d'opération de base qui est installé avec NCache. Tout ce que vous avez à faire est qu'il existe différents dossiers d'aiguilles dans les exemples d'opérations de base .NET, en ce qui concerne l'utilisation NCache bibliothèques côté client que vous pouvez utiliser NCache Paquet SDK NuGet. C'est le moyen le plus simple d'obtenir toutes les ressources côté client.
L'autre option est que vous utilisez réellement Alachisoft.NCache.Exécution et Alachisoft.NCache.Bibliothèques Web Vous-même. Vous les incluez. Ce sont quelque chose ce sont les bibliothèques qui commencent par NCache dans les dossiers Microsoft Cache. Une fois que vous avez installé NCache cela en ferait partie et ensuite je vous montrerai rapidement ce que vous devez faire. Voilà! Donc, la première chose dont vous avez besoin est d'ajouter des références à ces deux bibliothèques ; runtime et web, incluent ces espaces de noms que je viens de mettre en évidence. Web.caching, puis à partir de ce moment, cet exemple est assez bon pour l'initialisation de base du cache qui s'y connecte, la création d'un objet le lisant, le supprimant le mettant à jour toutes sortes d'opérations de création, lecture, mise à jour, suppression.
Donc, c'est ainsi que vous initialisez le cache. C'est l'appel principal, non ? Il a besoin que le nom du cache renvoie un handle de cache, puis appelle simplement le cache ou ajoute stocke tout dans une paire de valeurs clés Cache.Get items, puis met à jour le cache des éléments ou insère, puis cache.delete. Et, nous vous avons déjà montré quelques exemples détaillés d'utilisation de la dépendance basée sur des clés à l'aide de balises à l'aide de groupes utilisant SQL comme la recherche. Donc, cela devrait en fait vous donner quelques détails sur la configuration de l'environnement et ensuite pouvoir l'utiliser dans une application réelle.
Ceci conclut notre présentation.