Dieser Artikel wurde maschinell übersetzt.

ASP.NET

Umgang mit relationale Daten in ein verteilter Cache

Iqbal Khan

 

Das Microsoft .net Framework für die Entwicklung eines Arrays von transaktionsintensiven Anwendungen wie Web, Service-orientierte Architektur (SOA), High Performance computing und Grid-computing, populär geworden und cloud computing. Alle diese Architekturen sind skalierbar. Aber ein Engpass Auftritt im Datenspeicher — normalerweise eine relationale Datenbank — was nicht in der Lage, zu skalieren und die erhöhte Transaktion-Last, die die Anwendungsebene kann verarbeiten.

Infolgedessen wird verteilte Zwischenspeicherung ziemlich populär weil es Ihnen erlaubt, zum Zwischenspeichern von Daten in einem Cache im Arbeitsspeicher, die wesentlich schneller Zugriff auf jede Datenbank ist als. Außerdem bietet linearen Skalierbarkeit verteilte Zwischenspeicherung auf mehrere Cacheserver. Lineare Skalierbarkeit können Sie weitere Cache-Server zum verteilten Cache Cluster hinzufügen, wenn Sie eine größere Belastung der Transaktion behandeln müssen. Die Incre­geistigen Gewinn in transaktionalen Kapazität nicht schmälern, beim Hinzufügen weiterer Server (es ist eine gerade Linie in ein X-Y-Diagramm, wobei x die Anzahl der Cache-Server und y ist die Transaktion Kapazität). Abbildung 1 zeigt, wie verteilte Zwischenspeicherung passt in eine typische Anwendung für ASP.NET oder Windows Communication Foundation (WCF) und wie es bietet linearen Skalierbarkeit.

Abbildung 1 verteilten Cache in ASP.NET oder Windows Communication Foundation-Anwendungen verwendet

In diesem Artikel wird erörtert, wie Entwickler Datenbeziehungen behandeln soll, während ihre Daten zwischenspeichern.

Verteilte Zwischenspeicherung großer ist zwar eine Herausforderung, die sie bietet wie relationale Daten zwischengespeichert, die verschiedenen Beziehungen zwischen Datenelementen hat. Dies liegt daran, ein verteilter Cache bietet Ihnen eine einfache, Hashtable-wie (Schlüssel, Wert) Schnittstelle, wo der "Schlüssel" eindeutig ein zwischengespeichertes Element und "Wert" ist, Ihre Daten oder Objekt. Ihre Anwendung hat jedoch wahrscheinlich ein komplexes Objekt Domänenmodell mit Vererbung, Aggregation und andere Arten von Beziehungen.

Darüber hinaus speichert ein verteilter Cache einzelne zwischengespeicherte Elemente getrennt, die unterscheidet sich von der Datenbank in der Sie die Beziehungen zwischen verschiedenen Tabellen haben. In der Regel gibt es keine Beziehung­Schiffe zwischen den verschiedenen Elementen in einem typischen verteilten Cache zwischengespeichert. Das stellt eine Herausforderung für .net Anwendungsentwickler. Mit anderen Worten, sind Sie die Herausforderung der Verfolgung der Beziehung Informationen innerhalb Ihrer Anwendung, um sicherzustellen, dass Sie Beziehungen richtig im Cache und in der gleichen Zeit nutzen verteilte Zwischenspeicherung behandeln können.

Ich werde erklären, wie diese Beziehungen abgebildet werden und bieten Beispiele mit Quellcode. Der Effekt ist, dass die Anwendungen nicht zu verfolgen diese Beziehungen selbst. Vielmehr wird der Cache können bewusst gemacht werden und dann selbständig zu behandeln.

Zuordnung der Objekt-Relation ist gut

Stellen Sie zunächst sicher, dass Sie Ihren relationalen Daten in einem Domänenmodell Objekt umwandeln. Ohne diesen Schritt müssten Sie eine schwierige Zeit der Umgang alle Beziehungen in ein verteilter Cache.

In jeder Anwendung .net höchstwahrscheinlich verwenden Sie DataReader (SqlDataReader, OracleDataReader oder OleDbDataReader) oder DataTable zum Abrufen von Daten aus der Datenbank und das ist gut. Aber viele Entwickler Zugang dann direkt Daten aus diesen Objekten (vor allem DataTable) in ihrer Anwendung. Einige tun es aus Faulheit, weil sie nicht wollen, eigene Domain-Objekte zu erstellen. Andere tun es, weil sie glauben, dass sie intelligente Filterfunktionen in der DataTable verwenden können.

Ich empfehle Sie verwandeln Ihre DataReader oder Daten­Tabelle in einer Domäne-Objektmodell. Dies wird stark vereinfacht den Anwendungsentwurf und auch ermöglichen es Ihnen, verteilte Zwischenspeicherung effektiv zu verwenden. Und ein guter verteilter Cache bietet Ihnen in der Regel mit einer SQL-ähnlichen oder LINQ Abfragen Funktion, so dass Sie nicht die Filterfunktionen der DataTable versäumen.

Wenn Sie eine DataTable verwenden, sind Sie gezwungen, es als ein zwischengespeichertes Element zwischenzuspeichern. Beachten Sie, dass Ihre Anwendung eine große Anzahl von Zeilen in einer DataTable verlangsamt, wenn Sie es Zwischenspeichern.

Sie können entweder verwandeln DataReader und DataTable in Domain-Objekte manuell oder mit einer der führenden Object Relation Mapping (ORM) Motoren. Das Entity Framework von Microsoft ist ein solcher Motor. Eine andere ist beliebte NHibernate, das ist open Source. Eine ORM-Tool vereinfacht die Aufgabe der Umwandlung von relationaler Daten in ein Domäne-Objektmodell.

CacheDependency hilft Beziehungen zu verwalten

Ein Domäne-Objektmodell ist die erste Frage wie alle diese Beziehungen im Cache zu behandeln. Und die Antwort ist CacheDependency, die Teil des ASP.NET-Cache und ist jetzt auch in einigen kommerziellen verteilten Zwischenspeicherung Lösungen gefunden.

CacheDependency ermöglicht es Ihnen, informieren Sie der Cache über unterscheiden sich­ent Arten von Beziehungen zwischen Elementen zwischengespeichert und dann lassen Sie den Datenintegrität für sie verwalten verteilten Cache. Im Grunde können eine CacheDependency Sie dem Cache, die man erzählen, das zwischengespeichertes Element von einem anderen zwischengespeicherten Elements abhängt. Dann kann verteilte Cache Nachverfolgen von Änderungen in das Ziel-Element und das Quellelement, das hängt von der Ziel-Element für ungültig erklären.

Angenommen, wenn Daten Punkt A von b abhängt, dann wenn b jemals aktualisiert oder aus dem Cache entfernt verteilte Cache automatisch a als auch entfernt. CacheDepend­Ency bietet auch Fähigkeit, Kaskadierung, damit wenn richtet sich a auf b und B C und dann c hängt aktualisiert oder entfernt, es führt zu b automatisch von verteilten Cache entfernt wird. Und wenn das passiert, wird auch automatisch a von verteilten Cache entfernt. Dies nennt man die kaskadierenden CacheDependency.

Ich benutze CacheDependency weiter unten in diesem Artikel veranschaulicht, wie Beziehungen in ein verteilter Cache zu behandeln.

Drei verschiedene Arten von Beziehungen

Zunächst verwenden wir ein Beispiel-Datenmodell für Zwecke der Diskussion, gezeigt Abbildung 2.

Abbildung 2 Beispiel-Datenmodell für Beziehungen

Wie Sie, in diesem Datenmodell sehen können hat der Kunde eine eins-zu-viele-Beziehung mit Bestellung; Produkt hat eine eins-zu-viele-Beziehung mit Bestellung; und Kunde und Produkt haben eine viele-zu-viele-Beziehung zueinander durch die Order-Tabelle. Für unser Beispiel-Daten-Modell Abbildung 3 zeigt das entsprechende Objektmodell, die dieselben Beziehungen darstellt.

Abbildung 3 Beispiel-Objektmodell gegen das Datenmodell

Bevor ich in die Details der verschiedenen Beziehungstypen gehe, möchte ich eine Sache zu erklären. Im Gegensatz zu der Datenbank ein Anwendungsobjektmodell Domäne hat immer eine primäre Objekt, das die Anwendung aus der Datenbank geholt hat und das ist somit der Ausgangspunkt für die Anwendung während einer bestimmten Transaktion. Alle anderen Objekte werden im Zusammenhang mit diesem primären Objekt angesehen. Dieses Konzept ist gültig für alle Arten von Beziehungen und wirkt sich, wie Sie Beziehungen in einem Domänenmodell Objekt sehen. Nun, gehen wir.

1: 1- Und N: 1-Beziehungen

1: 1- Und n: 1-Beziehungen sind ähnlich. Eine Zeile in Tabelle A in einer 1:1-Beziehung zwischen den Tabellen A und b bezieht sich auf nur eine Zeile in Tabelle B. Sie halten einen Fremdschlüssel in der Tabelle A oder B, die den Primärschlüssel der anderen Tabelle ist.

Im Falle einer viele-zu-eins-Beziehung zwischen a und B, Sie müssen halten den Fremdschlüssel in Tabelle A. Diese Fremdschlüssel ist der Primärschlüssel der Tabelle B. In eins zu eins sowohl viele-zu-eins-Beziehungen hat der Fremdschlüssel eine unique-Einschränkung um sicherzustellen, dass keine Duplikate vorhanden sind.

Die gleiche Beziehung kann leicht in ein Domäne-Objektmodell umgewandelt werden. Das primäre Objekt (früher erklärt) behält einen Verweis auf das verknüpfte Objekt. Abbildung 4 zeigt ein Beispiel für das primäre Objekt Beziehungsinformationen halten. Beachten Sie, dass die Order-Klasse enthält einen Verweis auf die Customer-Klasse eine viele-zu-eins-Verhältnis an. Das gleiche würde auch in eine 1:1-Beziehung passieren.

Abbildung 4 ein verwandtes Objekt separat Zwischenspeichern

public void CacheOrder(Order order)
{
  Cache cache = HttpRuntime.Cache;
  DateTime absolutionExpiration = Cache.NoAbsoluteExpiration;
  TimeSpan slidingExpiration = Cache.NoSlidingExpiration;
  CacheItemPriority priority = CacheItemPriority.Default;
  if (order != null) {
    // This will prevent Customer from being cached with 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,
              absolutionExpiration,
              slidingExpiration,
              priority, null);
    // 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;
    // This will only cache Order object
    cache.Add(orderKey, order, dep,
              absolutionExpiration,
              slidingExpiration,
              priority, null);
  }
}

1: N-Beziehungen (Umkehrung der N-1)

Tabelle B (d. h. der "n"-Seite) hält bei einer eins-zu-viele-Beziehung in der Datenbank zwischen Tabellen A und b den Fremdschlüssel, der eigentlich den Primärschlüssel der Tabelle A, aber ohne eine unique-Einschränkung für den Fremdschlüssel ist.

Bei einer eins-zu-viele-Domäne-Objektmodell das primäre Objekt ist der Kunde und das verknüpfte Objekt ist die Reihenfolge. Das Customer-Objekt enthält eine Auflistung von Order-Objekten. Abbildung 4 zeigt auch ein Beispiel für diese Beziehung zwischen den Customer- und Order-Objekten.

n:n-Beziehungen

Im Falle einer viele-zu-viele-Beziehung zwischen den Tabellen A und b gibt es immer eine vermittelnde Tabelle AB. In unserem Fall ist die vermittelnde Tabelle und hat zwei Fremdschlüssel. Man ist gegen die Customer-Tabelle zum Darstellen einer viele-zu-eins-Beziehung und der andere ist gegen die Tabelle wieder eine n: 1-Beziehung darstellen.

Im Falle einer viele-zu-viele-Beziehung ist das Objektmodell in der Regel 1-n-aus der Perspektive eines primären Objekts (zuvor definiert), die Kunden oder Produkt ist. Das Objektmodell enthält nun auch eine viele-zu-eins-Beziehung zwischen dem zwischengeschalteten Objekt (Order, in unserem Fall) und das andere Objekt (Produkt, in unserem Fall). Abbildung 4 zeigt auch ein Beispiel einer viele-zu-viele-Beziehung, die in diesem Fall zwischen Kunde und Produkt-Objekte mit der Order-Objekt wird ein zwischengeschaltetes Objekt ist.

Wie Sie sehen können, das Objektmodell ist aus der Perspektive des Customer-Objekts, das primäre Objekt ist, und die Anwendung es aus der Datenbank abgerufen. Alle verwandten, dass Objekte aus der Perspektive des primären Objekts sind. So wird ein Customer-Objekt eine Auflistung von Order-Objekten haben, und jede Order-Objekt enthält einen Verweis auf die Produkt-Objekt. Produktobjekt wird nicht wahrscheinlich eine Auflistung aller Order-Objekte gehören Produktobjekt, weil die hier gebraucht ist nicht enthalten. Wenn Produkt das primäre Objekt, es hätte eine Auflistung von Order-Objekten — aber dann würden das Customer-Objekt eine Auflistung von Order-Objekten nicht.

Caching-Strategien für verschiedene Beziehungstypen

Bisher habe ich diskutiert, wie Sie Daten aus der Datenbank abrufen, verwandeln es in ein Domäne-Objektmodell und halten dieselben Beziehungen in der Domäne-Objektmodell wie in der Datenbank — zwar aus der Perspektive des primären Objekts. Aber wenn Ihre Anwendung zum Zwischenspeichern von Daten in einem verteilten Cache, müssen Sie verstehen, wie alle diese Beziehungen im Cache zu behandeln. Ich gehe durch jeweils.

In allen Fällen müssen Sie sicherstellen, dass Beziehungsinformationen im Cache nicht verloren, Auswirkungen auf die Datenintegrität oder Ihre Fähigkeit, später verwandte Objekte aus dem Cache zu holen.

Zwischenspeicherung: 1- und N: 1-Beziehungen

Hier haben Sie zwei Möglichkeiten:

1. Cache verwandte Objekte mit dem primären Objekt: diese Option wird davon ausgegangen, dass das verknüpfte Objekt nicht geht von einem anderen Benutzer geändert werden, während es im Cache ist, so dass es als Teil des primären Objekts als ein zwischengespeichertes Element zwischengespeichert werden kann. Wenn Sie, dass dies nicht der Fall ist befürchten, dann verwende diese Option keine.
2. Cache verwandte Objekte getrennt: diese Option setzt voraus, dass das verknüpfte Objekt von einem anderen Benutzer aktualisiert werden kann, während es im Cache ist, so ist es am besten, die primären und verwandte Objekte als separate zwischengespeicherte Elemente zwischenspeichern. Sie sollten eindeutige Cacheschlüssel für jede der beiden Objekte angeben. Darüber hinaus können Sie die Tag-Funktion eines verteilten Caches verwenden, können Sie das verknüpfte Objekt als eine Beziehung zum primären Objekt verknüpfen. Dann könnte Sie es später durch den Tag holen.

Zwischenspeichern von 1: N-Beziehungen

Bei 1: n-Beziehungen ist das primäre Objekt immer auf der Seite"1" (in unserem Beispiel ist es das Customer-Objekt). Das primäre Objekt enthält eine Auflistung von Order-Objekten. Jede Auflistung verwandter Objekte stellt eine eins-zu-viele-Beziehung dar. Hier haben Sie drei Optionen zum Zwischenspeichern:

1. Verwandte Objekte Sammlungen mit dem primären Objekt Zwischenspeichern: dies natürlich nimmt an, dass die verknüpften Objekte nicht aktualisiert oder unabhängig von einem anderen Benutzer während im Cache geholt werden, so ist es sicher, sie als Teil des primären Objekts zwischengespeichert. Dabei verbessert Ihre Leistung, da Sie alles in einem Cache-Aufruf abrufen können. Jedoch, wenn die Sammlung groß ist (d. h. Zehntausende von Objekten und dringt in Megabyte an Daten), der Leistungsgewinn bekommen Sie nicht.
2. Verwandte Objekte Sammlungen separat Zwischenspeichern: In dieser Situation, die Sie glauben, andere Benutzer möglicherweise möchten holen die gleichen Sammlungen aus dem Cache; Daher ist es sinnvoll, die Auflistung der verknüpften Objekte separat zwischenzuspeichern. Sie sollte Ihren Cacheschlüssel so strukturieren, dass Sie in der Lage werden, diese Auflistung basiert auf einige Informationen über das primäre Objekt zu finden. Das Problem des Zwischenspeicherns Sammlungen sehr viel ausführlicher weiter unten in diesem Artikel wird erläutert.
3. Alle einzelnen verknüpften Objekte aus Sammlungen separat Zwischenspeichern: In dieser Situation, Sie glauben, dass jedes einzelne Objekt in der zugehörigen Auflistung möglicherweise aktualisiert werden, von anderen Benutzern; Daher kann kein Objekt in der Auflistung halten und muss es separat Zwischenspeichern. Sie können die Tag-Funktion eines verteilten Caches alle Objekte in Bezug auf Ihre primären Objekt identifizieren, so Sie in der Lage werden, ihnen schnell später auf zu holen.

Zwischenspeichern: N-Beziehungen

M: n-Beziehungen in einem Domänenmodell Objekt existieren nicht wirklich. Stattdessen sind sie von 1: n-Beziehungen, mit der Ausnahme, dass das zwischengeschaltete Objekt (Order, in unserem Fall) einen Verweis auf die andere Seite-Objekt (Produkt, in unserem Fall enthält) dargestellt. In einer reinen-n würde nicht diese Referenz vorhanden.

Umgang mit Sammlungen

Das Thema Umgang mit Sammlungen ist interessant, weil Sie oft eine Auflistung von Objekten aus der Datenbank abrufen und Cache-Sammlungen in effizienter Weise können möchten.

Nehmen wir an Ihr habt ein Szenario, in dem Sie alle Ihre New Yorker Kunden anfordern, und Sie erwarten nicht, jede neuen Kunden aus New York in den nächsten Tag oder in den nächsten Minuten hinzugefügt werden. Denken Sie Sie sind nicht Zwischenspeichern von Daten über Wochen und Monate, nur für eine Minute oder ein paar Stunden in den meisten Fällen. In einigen Situationen können Sie es über viele Tage Zwischenspeichern.

Es gibt verschiedene Strategien für die Zwischenspeicherung von Sammlungen, Zwischenspeichern, wie ich erläutern werde.

Zwischenspeichern Sie, eine ganze Sammlung zu einem Element

In diesem Fall wissen Sie, dass Sie das Hinzufügen wird keine weitere Kunden aus New York und die andere Benutzer zugreifen und diese ändern keine Kundendaten New York während des Zeitraums, in dem die Daten zwischengespeichert werden, sind nicht. Daher können Sie die gesamte Sammlung von New York Kunden als ein zwischengespeichertes Element Zwischenspeichern. Hier können Sie die Suchkriterien oder den SQL-Query-String der Cacheschlüssel machen. Jedes Mal Sie möchten Kunden zu holen, die aus New York, gehen Sie einfach zu den Cache und sagen: "Gib mir die Sammlung mit New York Kunden."

Abbildung 5 zeigt, wie eine ganze Sammlung von verwandten Order-Objekte zwischengespeichert wird.

Abbildung 5 eine damit verbundene Sammlung separat Zwischenspeichern

public void CacheCustomer(Customer cust)
{
  Cache cache = HttpRuntime.Cache;
  DateTime absolutionExpiration = Cache.NoAbsoluteExpiration;
  TimeSpan slidingExpiration = Cache.NoSlidingExpiration;
  CacheItemPriority priority = CacheItemPriority.Default;
  if (cust != null)
  {
    string key = "Customer:CustomerId:" + cust.CustomerId;
    // Let's preserve it to cache separately
    IList<Order> orderList = cust.Orders;
    // So it doesn't get cached as part of Customer
    cust.Orders = null;
    // This will only cache Customer object
    cache.Add(key, cust, null,
              absolutionExpiration,
              slidingExpiration,
              priority, null);
    // See that this key is also Customer based
    key = "Customer:CustomerId:" + cust.CustomerId + ":Orders";
    cache.Add(key, orderList, null,
              absolutionExpiration,
              slidingExpiration,
              priority, null);
  }
}

Jedes Element der Auflistung separat Zwischenspeichern

Jetzt wollen wir weitergehen, bis die zweite Strategie. In diesem Szenario möchten Sie oder andere Benutzer einzeln abrufen und ändern ein New York-Kunden. Aber die bisherige Strategie müsste jeder die gesamte Kollektion aus dem Cache zu holen, ändern diese einem Kunden, steckte es wieder in die Sammlung und Zwischenspeichern der Auflistung wieder. Wenn Sie diese häufig genug tun, wird sie aus Performance-Gründen unpraktisch.

Also, in diesem Fall nicht Sie die Auflistung aller New York-Kunden als ein zwischengespeichertes Element halten. Sie brechen die Auflistung und separat speichern jedes Customer-Objekt im Cache. Sie müssen alle diese Customer-Objekte zu gruppieren, so dass zu einem späteren Zeitpunkt, den Sie nur sie abrufen können alle in einem Aufruf als eine Auflistung oder ein IDictionary zurück. Der Vorteil dieses Ansatzes ist die Möglichkeit zum Abrufen und ändern einzelne Customer-Objekten. Abbildung 6 zeigt ein Beispiel wie verwandte Objekte in der Auflistung separat zwischengespeichert.

Abbildung 6 jedes Element der Auflistung separat Zwischenspeichern

public void CacheOrdersListItems(IList<Order> ordersList)
{
  Cache cache = HttpRuntime.Cache;
  DateTime absolutionExpiration = Cache.NoAbsoluteExpiration;
  TimeSpan slidingExpiration = Cache.NoSlidingExpiration;
  CacheItemPriority priority = CacheItemPriority.Default;
  foreach (Order order in ordersList)
  {
    string key = "Order:CustomerId:" + order.CustomerId
      + ":ProductId" + order.ProductId;
    string[] keys = new string[1];
    keys[0] = key;
    // Dependency ensures Order is removed if Cust updated/removed
    CacheDependency dep = new CacheDependency(null, keys);
    Tag [] tagList = new Tag [1];
    tagList[0] = new Tag ("customerId" + order.CustomerId);
     // Tag allows us to find order with a customerId alone
     cache.Add(key, order, dep,
               absolutionExpiration,
               slidingExpiration,
               priority, null, tagList);
  }
}

Bitte beachten Sie jedoch, die diese Strategie setzt voraus, dass keine Kunden, New York in die Datenbank im Zeitraum hinzugefügt wurden, in denen sie zwischengespeichert worden habe. Andernfalls, wenn Sie alle New York Kunden aus dem Cache geholt werden, erhalten Sie nur eine unvollständige Liste. Ebenso, wenn ein Kunde aus der Datenbank, aber nicht aus dem Cache gelöscht wird, erhalten Sie veraltete Liste der Kunden.

Umgang mit Sammlungen wo werden Objekte hinzugefügt oder gelöscht

Die dritte Option für die Behandlung von Sammlungen ist wo denken Sie neue Kunden aus New York zugesetzt werden oder einige Bestandskunde kann gelöscht werden. In diesem Fall, was auch immer Sie Zwischenspeichern ist nur teilweise oder alte Daten. Vielleicht die Sammlung hatte nur 100 Kunden und Sie haben zwei weitere heute. Diese beiden werden nicht Bestandteil des Caches werden. Wenn Sie alle Kunden aus New York geholt werden, Sie jedoch die richtigen Daten: 102 Ergebnisse, nicht 100 werden soll.

Der Weg um sicherzustellen, dass in diesem Fall soll die Datenbank anrufen. Alle IDs für die Kunden und machen Sie einen Vergleich zu sehen, die im Cache sind und welche nicht. Holen Sie individuell aus der Datenbank diejenigen, die nicht im Cache zum Cache hinzugefügt. Wie Sie sehen können, ist das kein schneller Prozess; Du machst mehrere Datenbank und mehrere Cache-Anrufe. Ein verteilter Cache bietet, die grundlegende Funktionen, wenn Sie eine Sammlung von 1.000 Kunden und 50 neue werden hinzugefügt, Sie werden am Ende 51 Datenbank und 101 ein verteilter Cache Anrufe zu machen. In diesem Fall könnte es schneller gehen, nur um aus der Datenbank in einem Aufruf die Auflistung abrufen.

Aber wenn verteilte Cache Massenvorgänge bereitstellt, würde Sie der einen Datenbank-IDs, ein verteilter Cache Aufruf zu sehen, die IDs im Cache vorhanden, ein Aufruf an alle neuen Kunden zum Cache hinzugefügt und ein Aufruf an die gesamte Sammlung von Kunden aus dem Cache zu holen zu holen. Dies wäre insgesamt ein Datenbankaufruf und drei verteilten Cache Aufrufe und das ist überhaupt nicht schlecht. Und, falls keine neuen Kunden wurden hinzugefügt (was der Fall wäre, 90 Prozent der Zeit), dies würde zu einer Datenbank Call und zwei verteilten Cache Aufrufe reduziert werden.

Leistung und Skalierbarkeit

Ich deckte die verschiedenen Situationen, die entstehen, wenn die Anwendung relationale Daten aus der Datenbank ruft, es in ein Domäne-Objektmodell wandelt und will dann die Objekte zwischenspeichern. Der Zweck meines Artikels soll alle diese Bereiche zu markieren, an denen Objektbeziehungen beeinträchtigen, wie Sie die Objekte zwischenspeichern und wie Sie später ändern oder Sie sie aus dem Cache entfernen.

Verteilte Zwischenspeicherung ist eine gute Möglichkeit zur Verbesserung der Leistung und Skalierbarkeit der Anwendung. Und weil Anwendungen mit relationalen Daten die meiste Zeit beschäftigen, ich hoffe, dass dieses Artikels übermittelt hat Sie mit einen Einblick in, wie Sie relationale Daten in einem verteilten Cache behandeln soll.

Iqbal Khan ist der Präsident und Technologie Evangelist von Alachisoft, bietet NCache und StorageEdge (alachisoft.com). NCache ist ein verteilter Cache für .net und Java und verbessert die Anwendungs-Performance und Skalierbarkeit. StorageEdge ist ein Anbieter von RBS für SharePoint und hilft zu optimieren, Speicher und Leistung von SharePoint. Khan erhielt seinen Master-Abschluss in Informatik von der Indiana University, Bloomington, 1990. Sie erreichen ihn unter iqbal@alachisoft.com.

Unser Dank gilt dem folgenden technischen Experten für die Durchsicht dieses Artikels: Damian Edwards