Mittendrin.

Zurück

Flurfunk der eXperts.

Hier erfahren Sie mehr über eXperts, Technologien und das wahre Leben in der SDX.

Caching transparent

11.01.201208:20 Uhr , Sebastian Weber

Das Thema Caching kann man auf viele verschiedene Wege angehen. Einer davon ist ein vollkommen transparenter Caching-Layer, der Queries abfängt und entsprechend behandelt.

Über das Wie und das Was wird beim Thema Caching gerne und häufig diskutiert, auch unter eXperts. Meistens trennt man sich nach einer solchen Diskussion mit der Erkenntnis, dass es auch für Caching keine Silver Bullet gibt. Keine Lösung, die sich in jeder Situation bedingungslos bewährt.

Eine Lösung, für ein Szenario soll der folgende Beitrag vorstellen.

Ziel ist es, das Caching transparent zu implementieren. Ein Aufrufer soll gar nicht merken, dass das Ergebnis seiner Abfrage irgendwo zwischengespeichert wird. Der Cache kann damit auch jederzeit per Konfiguration zu- oder abgeschaltet werden, ohne dass der Code auf Seite des Verwenders geändert werden muss.

Um dieses Ziel zu erreichen werden alle Aufrufe an die eigentliche Datenzugriffskomponente abgefangen und entsprechend behandelt, bevor diese dann weitergereicht werden. Hierzu definieren wir zunächst ein Interface für die Datenzugriffskomponente.

   1:  public interface ICustomerRepository
   2:  {
   3:    IQueryable<Customer> Customers { get; }
   4:  }


Die Einführung von LINQ brachte das Interface IQueryable<T> mit. Dieses Interface ermöglicht die Definition einer Abfragebedingung, die erst evaluiert wird, wenn das Ergebnis der Abfrage verarbeitet wird (etwa durch den Aufruf von ToList() oder durch die Verwendung des Ergebnisses in einer foreach()-Schleife).

Um eine solche Abfragebedingung abfangen zu können muss man nun zunächst entsprechende Implementierungen von IQueryable<T> und dessen Basisinterface IQueryable erstellen.

Etwas vereinfacht könnten diese wie folgt aussehen.

   1:  public class QueryInterceptor<T> : QueryInterceptor, IQueryable<T>
   2:  {
   3:    private readonly IQueryable<T> wrapped;
   4:    public QueryInterceptor(IQueryable<T> wrapped, QueryInterceptorProvider provider)
   5:      : base(wrapped, provider)
   6:    {
   7:      this.wrapped = wrapped;
   8:    }
   9:    public IEnumerator<T> GetEnumerator()
  10:    {
  11:      var enumerable = this.Provider.Execute<IEnumerable<T>>(this.Expression);
  12:      var enumerator = enumerable.GetEnumerator();
  13:      return enumerator;
  14:    }
  15:  }
  16:   
  17:  public class QueryInterceptor : IQueryable
  18:  {
  19:    private readonly IQueryable wrapped;
  20:    private readonly QueryInterceptorProvider queryProvider;
  21:    public QueryInterceptor(IQueryable wrapped, QueryInterceptorProvider provider)
  22:    {
  23:      this.wrapped = wrapped;
  24:      this.queryProvider = provider;
  25:    }
  26:    public Type ElementType
  27:    {
  28:      get { return this.wrapped.ElementType; }
  29:    }
  30:    public Expression Expression
  31:    {
  32:      get { return this.wrapped.Expression; }
  33:    }
  34:    public IQueryProvider Provider
  35:    {
  36:      get { return this.queryProvider; }
  37:    }
  38:    public QueryInterceptorProvider QueryProvider
  39:    {
  40:      get { return this.queryProvider; }
  41:    }
  42:    IEnumerator IEnumerable.GetEnumerator()
  43:    {
  44:      var enumerable = this.Provider.Execute(this.Expression) as IEnumerable;
  45:      var enumerator = enumerable.GetEnumerator();
  46:      return enumerator;
  47:    }
  48:  }

Das genügt allerdings noch nicht ganz. LINQ verwendet zur Erstellung und Ausführung von Queries außerdem noch Implementierungen von IQueryProvider. Auch hierfür müssen wir einen Interceptor bereitstellen.

   1:  public class QueryInterceptorProvider : IQueryProvider
   2:  {
   3:    private readonly IQueryProvider wrapped;
   4:    public QueryInterceptorProvider(IQueryProvider wrapped)
   5:    {
   6:      this.wrapped = wrapped;
   7:    }
   8:    public event EventHandler<ExpressionExecuteEventArgs> Executing = delegate { };
   9:    public event EventHandler<ExpressionExecuteEventArgs> Executed = delegate { };
  10:    public IQueryable<TElement> CreateQuery<TElement>(Expression expression)
  11:    {
  12:      var rawQuery = wrapped.CreateQuery<TElement>(expression);
  13:      var interceptor = new QueryInterceptor<TElement>(rawQuery, this);
  14:      return interceptor;
  15:    }
  16:    public IQueryable CreateQuery(Expression expression)
  17:    {
  18:      var rawQuery = this.wrapped.CreateQuery(expression);
  19:      var interceptor = new QueryInterceptor(rawQuery, this);
  20:      return interceptor;
  21:    }
  22:    public TResult Execute<TResult>(Expression expression)
  23:    {
  24:      object value;
  25:      bool handled = this.NotifyExecuting(expression, out value);
  26:      TResult result = !handled ? this.wrapped.Execute<TResult>(expression) : (TResult)value;
  27:      this.NotifyExecuted(expression, result);
  28:      return result;
  29:    }
  30:    public object Execute(Expression expression)
  31:    {
  32:      object value;
  33:      bool handled = this.NotifyExecuting(expression, out value);
  34:      object result = !handled ? this.wrapped.Execute(expression) : value;
  35:      this.NotifyExecuted(expression, result);
  36:      return result;
  37:    }
  38:    public bool NotifyExecuting(Expression expression, out object result)
  39:    {
  40:      var e = new ExpressionExecuteEventArgs { Expression = expression };
  41:      this.Executing(this, e);
  42:      if (e.Handled)
  43:      {
  44:        result = e.Result;
  45:        return true;
  46:      }
  47:      result = null;
  48:      return false;
  49:    }
  50:    public void NotifyExecuted(Expression expression, object result)
  51:    {
  52:      var e = new ExpressionExecuteEventArgs
  53:        {
  54:          Expression = expression, 
  55:          Result = result
  56:        };
  57:      this.Executed(this, e);
  58:    }
  59:  }

Vor und nach der Evaluierung einer Abfragebedingung feuert der QueryInterceptorProvider die Executing und Executed Events, auf die der Cache reagieren wird. Die zu diesen Events gehörenden ExpressionExecuteEventArgs sehen wie folgt aus.

   1:  public class ExpressionExecuteEventArgs : EventArgs
   2:  {
   3:    public bool Handled { get; set; }
   4:    public object Result { get; set; }
   5:    public Expression Expression { get; set; }
   6:  }

Diese EventArgs liefern die Expression, die die Abfragebedingung bildet. Diese Expression wird verwendet um einen eindeutigen Key für den Cache zu erzeugen. Ein Aufruf von ToString() auf der Expression reicht hierfür leider nicht. Warum das so ist und was sich dagegen tun lässt beschreibt Pete Montgomery in seinem Blog.

Mit diesen Komponenten ist es nun nur noch ein kleiner Schritt zum CachingCustomerRepository. Dieses verwendet die mit .NET 4.0 hinzugekommen Strukturen aus dem System.Runtime.Caching-Namespace. Denkbar ist aber auch jede andere Cache-Implementierung wie beispielsweise der AppFabric-Cache.

   1:  public class CachingCustomerRepository : ICustomerRepository
   2:  {
   3:    private readonly ICustomerRepository inner;
   4:    private readonly ObjectCache cache;
   5:    private QueryInterceptor<Customer> customers;
   6:    public CachingCustomerRepository(ICustomerRepository inner)
   7:    {
   8:      this.inner = inner;
   9:      this.cache = new MemoryCache(typeof(CachingCustomerRepository).FullName);
  10:      this.customers = new QueryInterceptor<Customer>(this.inner.Customers, new QueryInterceptorProvider(this.inner.Customers.Provider));
  11:      this.customers.QueryProvider.Executing += this.OnQueryExecuting;
  12:      this.customers.QueryProvider.Executed += this.OnQueryExecuted;
  13:    }
  14:    public IQueryable<Customer> Customers
  15:    {
  16:      get { return this.customers; }
  17:    }
  18:    private void OnQueryExecuted(object sender, ExpressionExecuteEventArgs e)
  19:    {
  20:      string cacheKey = e.Expression.GetCacheKey();
  21:      IQueryable<Customer> cachedResult = this.cache[cacheKey] as IQueryable<Customer>;
  22:      if (cachedResult == null)
  23:      {
  24:        var evaluatedQueryable = ((IEnumerable<Customer>)e.Result).ToList().AsQueryable();
  25:        this.cache[cacheKey] = evaluatedQueryable;
  26:      }
  27:    }
  28:    private void OnQueryExecuting(object sender, ExpressionExecuteEventArgs e)
  29:    {
  30:      string cacheKey = e.Expression.GetCacheKey();
  31:      IQueryable<Customer> cachedResult = this.cache[cacheKey] as IQueryable<Customer>;
  32:      if (cachedResult != null)
  33:      {
  34:        e.Handled = true;
  35:        e.Result = cachedResult;
  36:      }
  37:  }

Diese Klasse wrappt eine beliebige andere Implementierung von ICustomerRepository und erweitert deren Fähigkeiten vollkommen transparent um das Caching von Abfrageergebnissen. Dazu wird die Customers-Property in einen QueryInterceptor gepackt. Für die Executing/Executed-Events des zugehörigen QueryInterceptorProviders werden zwei Listener registriert. Der erste prüft vor der Abfrage, ob ein entsprechendes Ergebnis schon im Cache vorliegt und bedient die Abfrage gegebenenfalls aus dem Cache. Der zweite nimmt das Ergebnis in den Cache auf, falls es dort nicht schon vorhanden ist.

Die vorgestellte Lösung ist eine technische Machbarkeitsstudie. Sie legt sich vollkommen transparent um den Datenzugriff und verbirgt somit den Caching-Mechanismus komplett vor dem Aufrufer. Dadurch wird er von der Komplexität des Caching isoliert.

Allerdings hat er so auch keine Möglichkeit mit dem Wissen um den Kontext einer Abfrage Optimierungen beim Caching vorzunehmen.

Welche Performancegewinne sich mit einem sehr expliziten Umgang mit dem Caching erreichen lassen zeigt dieses Video. Es beschreibt, wie StackOverflow mit geringem Einsatz von Hardware die Antwortzeiten seiner Seiten kurz hält.

Und stets wiederkehrende Fragen muss der Verwender trotzdem für das jeweilige Szenario klären:

  • Muss tatsächlich jede Abfrage gecached werden?
  • Können Teile der Ergebnisse im Cache für andere Abfragen wiederverwendet werden?
  • Wiederholen sich Abfragen häufig genug um den Aufwand für das Caching zu rechtfertigen?
  • Was passiert bei Änderungen, beispielsweise durch ein Update(Customer)?
  • Bringt das Caching für das geplante Szenario tatsächlich Effizienzgewinne?
  • Beeinflusst das Caching die Konsistenz der Ergebnisse?

Wie bereits ganz zu Beginn angesprochen gibt es eben leider auch für das Caching keine allgemeingültige Lösung.

Tags: .NET Dev

2 Kommentare

11.01.20129:39 Uhr
Anonym

Ein solcher Cache ist nicht ganz ungefährlich, gerade weil er so transparent ist. Ein völlig transparenter Cache sollte das Anwendungsverhalten nicht verändern, was dieser jedoch u.U. tut, da er Änderungen in der darunterliegenden Datenbasis maskiert.

Beispiele für transparente Caches, die i.d.R. keinen Einfluss auf die Korrektheit der Anwendung haben: Disk-Cache, SQL-Server Page- und Query-Buffer, .NET Thread- und Connectionpool.

11.01.201216:53 Uhr
Sebastian Weber

Caching ist generell eine Technologie, die mit Bedacht eingesetzt werden sollte. Wie wird z.B. festgestellt, ob die Daten im Cache noch aktuell sind? Wie alt ist noch gut genug? Hat die Aktualität der Daten Auswirkungen auf die Korrektheit der Anwendung? Amazon hat sich z.B. entschieden, dass die Informationen über den Bestand eines Produktes ruhig ein paar Stunden alt sein dürfen. Für Messwerte aus einem Überwachungssystem dürfte etwas anderes gelten.

Dein Kommentar wartet auf Freischaltung.

Artikel kommentieren

Zurück

Tag Cloud


Kontakt aufnehmen


Anrufen

Gerne beantworten wir Ihre Fragen in einem persönlichen Gespräch!


Kontakt aufnehmen

Schreiben Sie uns eine E-Mail mit Ihren Fragen und Kommentaren!