Snel en Schaalbaar met Velocity Distributed Cache

In het hart van je computer vind je de processor en het interne geheugen. Deze onderdelen horen bij de computerarchitectuur die is vernoemd naar John von Neumann, een beroemd wiskundige en computergeleerde. Eén van de onhebbelijkheden van deze architectuur is de “Von Neumann bottleneck”: doordat het geheugen zich “op afstand” van de processor bevindt en veel data kan bevatten, ontstaat er een grote hoeveelheid verkeer op de relatief smalle verbindingsweg tussen die twee onderdelen. Dit leidt tot opstopping en vertraging. Deze flessenhals wordt in computers deels opgeheven door een buffer tussen de twee onderdelen te plaatsen: de cache.

Op veel grotere schaal, in de wereld van software development, krijgen we steeds meer te maken met gedistribueerde data en event-driven applicaties. Gegevens zijn cruciaal voor applicaties om te functioneren, maar applicaties zijn door hun gedistribueerde en servicegeoriënteerde architectuur afhankelijk van vele schakels in de keten. Gegevens kunnen van diverse bronnen afkomstig zijn, zelfs van externe partijen. Soms moet je gegevens van verschillende bronnen aggregeren voor je er iets mee kunt. Ook kun je er niet altijd zeker van zijn dat verbindingen voorhanden zijn. Of misschien heb je een SLA waarbij je moet betalen voor het aantal calls dat je afneemt en is het dus een kostenoverweging om het aantal aanroepen van services te beperken. Denk ook aan offline scenario’s op smart clients, handheld devices, enz. In een gedistribueerde en servicegeoriënteerde omgeving ontstaat door al deze aspecten een behoefte aan een vorm van caching.

De “Von Neumann bottleneck” is (deels) op te lossen via caches

Er zijn gelukkig middelen die het ons steeds gemakkelijker maken om caches te bouwen. De prijs van geheugenchips blijft dalen en door slim gebruik te maken van meerdere computers kunnen we gedistribueerde caches bouwen op basis van goedkope hardware. Een gedistribueerde cache bestaat uit een verzameling computers die samen één grote cache vormen. Doordat de cache verspreid is over meerdere machines kun je profiteren van b.v. hoge beschikbaarheid (door kopieën van gegevens te verspreiden over meerdere computers en ze elkaars werk te laten overnemen als er een computer uitvalt) en hoge performance doordat de belasting van de machines wordt verdeeld over verschillende computers. Zolang je computers hebt met geheugen en een netwerkkaart, kun je de gedistribueerde cache blijven vergroten.

De performance van bekende community sites als Hyves en MySpace of grote webwinkels als Amazon zou als een plumpudding in elkaar zakken als zij niet waren voorzien van grote gedistribueerde caches

De performance van bekende community sites als Hyves en MySpace of grote webwinkels als Amazon zou als een plumpudding in elkaar zakken als zij niet waren voorzien van grote gedistribueerde caches.

Wat stop je in een cache?

Er zijn verschillende soorten gegevens die zich lenen om te cachen en waarbij ook verschillende scenario’s passen.

Referentiedata

Dit zijn gegevens die niet vaak wijzigen maar wel heel vaak worden geraadpleegd. Denk hierbij aan productgegevens in een productcatalogus of gegevens over reisverzekeringen van verschillende verzekeringspartners. Stamtabellen voor landen, plaatsnamen, postcodes, etc., vallen ook in deze categorie. Meestal wordt aan deze gegevens een bepaalde geldigheidsduur meegegeven. Zolang deze uiterste houdbaarheidsdatum niet is verstreken, kunnen deze gegevens in de cache blijven. Referentiedata lenen zich uitstekend om te cachen.

Activity data

Hieronder verstaan we gegevens die geldig zijn terwijl een eindgebruiker bezig is met een gebruikerssessie. We noemen dit ook wel conversational state. Een voorbeeld van activity data is de inhoud van een winkelwagentje dat een gebruiker aan het samenstellen is op de site van een internetwinkel. Deze gegevens bevinden zich meestal ergens in de user interface / front end laag van een applicatie. In ASP.NET applicaties gebruiken we daarvoor vaak de Session container. Pas na afloop van een transactie komt activity data in een of andere vorm definitief in een backendsysteem, database of service te staan. Het winkelwagentje uit het voorbeeld wordt dan omgezet in een order. Activity data wordt vaak geschreven en gelezen, maar alleen binnen de context van één gebruiker. Deze gegevens moeten daarom worden gekoppeld aan die ene gebruiker. Voorbeelden hiervan zijn de session state, cookies of de viewstate in ASP.NET applicaties.

Resource data

Dit zijn gegevens die vaak worden gelezen en geschreven door meerdere gebruikers of applicaties. Bijvoorbeeld de beschikbare voorraad van producten in een magazijn. Bij iedere bestelling moeten deze gegevens worden bijgewerkt en ze moeten altijd beschikbaar zijn. Hier is dus een sterke koppeling met de achterliggende gegevensbron en deze gegevens moeten doorlopend met elkaar in de pas worden gehouden. Caching is in deze gevallen vooral een middel om snelheid te krijgen bij het raadplegen, maar het risico is groot dat de gegevens in de cache verouderd zijn. De beste performance krijg je door de cache zo dicht mogelijk bij de applicatie te leggen, b.v. door de cache in-process te draaien of op dezelfde machine.

Gedistribueerd cachen met Velocity

Microsoft is een project gestart met de code naam Velocity uitgaande van de eerder genoemde trend in applicatiearchitectuur en de mogelijkheden die de hardware ons biedt. Velocity levert een gedistribueerde cache die in veel verschillende scenario’s inzetbaar is. Het product is nog volop in ontwikkeling en is momenteel als CTP3 beschikbaar. Wanneer versie 1.0 beschikbaar komt is nog onduidelijk.

In de rest van dit artikel ga ik in op de eigenschappen van Velocity CTP2 en waar je rekening mee moet houden als je het product wilt inpassen in je architectuur.

Velocity is dus een gedistribueerde cache. De filosofie die Microsoft hanteert is die van een bundeltje computers waarvan de interne geheugens aan elkaar worden gesmeed tot één grote cache die beschikbaar is voor de applicatie. Vanuit de applicatie gezien benader je één logische cache, Velocity zorgt voor lastige zaken als het verdelen van gegevens over een heel cluster. Hiermee zorgt Velocity voor failover, hoge beschikbaarheid, schaalbaarheid enzovoort.

In de huidige opzet is Velocity een cache-aside, wat betekent dat de cache niet meer is dan een grote silo voor gegevens. De applicatie bepaalt zelf wanneer objecten in de cache moeten worden gezet of wanneer ze moeten worden ververst. Velocity heeft zelf dus geen weet van wat de applicatie doet of wat er in de cache wordt opgeslagen.

Wat kan er allemaal in Velocity worden opgeslagen? Eigenlijk alle gegevens, zolang ze serializable zijn: .NET objecten, DataRows, XML en byte arrays. De reden waarom ze serializable moeten zijn is dat ze proces- en machinegrenzen oversteken. Met serializable bedoel ik dat ze moeten zijn voorzien van het Serializable attribuut of de DataContract en DataMember attributen.

Velocity een Silo van serializable data.

In zijn kleinste vorm kan Velocity ook worden ingezet als een in-process cache. Dit heet een local cache. Velocity draait dan in het proces van je applicatie mee. De hoeveelheid gegevens die Velocity in de local cache stopt heeft dan wel direct invloed op het geheugengebruik van de applicatie. Een local cache kun je ook combineren met een volledig cache cluster. Gegevens die je opvraagt vanuit het cache cluster worden dan gebufferd in de local cache. Velocity werkt met een fallback mechanisme: het controleert of objecten in de local cache staan. Alleen wanneer dat niet het geval is, zal Velocity het cache cluster aanspreken. De eerstvolgende keer staan de gegevens wel in de local cache. Omdat de local cache in het proces van de applicatie meedraait, hoeven objecten niet te worden geserialiseerd en gedeserialiseerd. Het werkt daardoor zeer snel, maar het zorgt er wel voor dat de applicatie zelf meer geheugen gaat gebruiken.

De opbouw van een cache cluster

In de gedistribueerde cache van Velocity praten we over een aantal onderdelen: de cache zelf, hosts, clusters en regions. Figuur 1 toont hoe de verschillende onderdelen met elkaar in verbinding staan.

Fig. 1: Schematische weergave van de Velocity onderdelen

Een cache host is een proces dat (een deel van) een cache beheert en vormt een apart te beheren onderdeel van de gedistribueerde cache. Een host is meestal gekoppeld aan één fysieke machine, maar er kunnen best meerdere hosts draaien op één computer.

Een cluster is een logische verzameling van hosts en van één of meerdere caches. Een cluster als geheel is ook weer een eenheid van beheer. Zo kun je een cluster in zijn geheel stoppen en starten. Je kunt de omvang van je cache beïnvloeden door er hosts aan toe te voegen of eruit te verwijderen.

Een cache wordt gevormd door het geheugen van de hosts binnen een cluster te combineren en er een logische naam aan te koppelen. Door die naam wordt het een ‘named cache’. Er kunnen meerdere named caches in een cache cluster bestaan. De naam levert niets meer op dan een context voor je applicatie. Zo kunnen een order- en een salesapplicatie gebruik maken van hetzelfde cachecluster en zelfs dezelfde sleutels gebruiken voor hun data, maar doordat de cache in beide gevallen een eigen naam heeft, ontstaat er geen verwarring. Vergelijk het met de namespace van XML documenten. Zoals de figuur al aangeeft, is een cache uitgesmeerd over de hosts in het cluster.

Fabric
Het fabric clustering protocol is een populaire technologie in de netwerkwereld. Het is een protocol dat zorgt voor het beheer van group membership van hosts binnen een cluster, het automatisch detecteren dat er hosts worden toegevoegd of verwijderd. Het zorgt voor schaalbaarheid en beschikbaarheid en voorkomt een single point of failure doordat data wordt gerepliceerd naar andere nodes. Daarnaast levert het routing tables om een verzoek van de client door te verwijzen naar de juiste host binnen een cluster.
Microsoft heeft Fabric geïmplementeerd en beschikbaar gesteld als een verzameling .NET assemblies. Deze zijn op dit moment onderdeel van de Velocity CTP2 download.

Binnen een cache kun je nog een opdeling maken in regions. Een region gebruik je om gelijksoortige gegevens te bundelen, vergelijkbaar met een tabel in een database. Je kunt dan, behalve de sleutel voor een object, ook meer informatie aan je data koppelen in de vorm van tags. Je kunt daardoor tag based zoeken, b.v. naar alle objecten met de tag “Dieselauto”. Velocity koppelt zo’n region wel aan één bepaalde host, dus je kunt dan niet profiteren van het feit dat Velocity de gegevens verdeelt over de verschillende hosts ten behoeve van de schaalbaarheid. Velocity kan overigens wel regions als geheel repliceren voor failover doeleinden.

Door een cluster op te bouwen uit verschillende hosts en daar een cache overheen te “projecteren” kan Velocity een cache leveren met een hoge beschikbaarheid en failover. Deze twee doelen bereikt Velocity door gegevens slim te verdelen over de hosts en vervolgens te repliceren. Mocht er een node uitvallen, dan is er altijd nog een host die een kopie van de gegevens beschikbaar heeft.

Doordat er onbeperkt hosts kunnen worden toegevoegd aan een cluster, zelfs terwijl een cluster draait, is Velocity enorm schaalbaar. Het beheren van het cluster gebeurt in Velocity op basis van het Fabric Cluster Management protocol (zie kader). Voor het beheren van de clusters en hosts krijg je een beheertool op basis van Windows PowerShell.

Velocity past goed op je spullen

In een gedistribueerde omgeving zullen er meerdere applicaties zijn die gebruik maken van de cache. Denk aan een web farm waarop dezelfde web applicatie meerdere malen is uitgevoerd. Ook meerdere lagen binnen een applicatie kunnen gebruik maken van dezelfde cache. Doordat de cache vanuit verschillende bronnen kan worden gevuld met data en weer worden uitgelezen, is belangrijk dat Velocity zijn cache goed bewaakt.

Bij het beheren van de cache waar meerdere partijen gebruik van maken komen eigenlijk dezelfde aspecten aan bod als bij “traditioneel” gegevensbeheer, namelijk constistency, concurrency en beveiliging. Specifiek bij caching is ook een goed beheer van geheugen belangrijk.

Consistency

Consistency in Velocity betekent het gelijk houden van de gegevens die verspreid en gerepliceerd zijn over de verschillende hosts binnen het cluster. Je kunt kiezen voor twee modellen: weak consistency of strong consistency. Bij strong consistency is een operatie om gegevens in de cache te stoppen of te wijzigen synchroon: de operatie is pas klaar als de gegevens succesvol zijn gerepliceerd naar alle hosts in het cluster. Als je het niet zo belangrijk vindt om te weten of een object wel in de cache is opgeslagen, dan kun je kiezen voor het weak consistency model. In het weak model gebeurt het wegschrijven en repliceren van gegevens in de cache asynchroon. Dit kan je veel snelheidswinst opleveren als je vaak gegevens in de cache schrijft, doordat je niet telkens hoeft te wachten totdat alle gegevens succesvol over alle hosts in het cluster zijn verspreid. Wanneer het wegschrijven van de gegevens mislukt door een onvoorzien probleem terwijl je daar niet van op de hoogte bent, moet je er in je applicatie wel rekening mee houden dat objecten niet per se in de cache staan en je hierdoor mogelijk vaker misgrijpt als je om objecten vraagt. Velocity ondersteunt in CTP2 alleen nog het synchrone model (strong consistency).

Concurrency en beveiliging

Bij resource data heb je mogelijk te maken met gegevens die door verschillende clients worden gewijzigd. In deze gevallen is het prettig dat Velocity de concurrency bewaakt. Net als in een database kun je kiezen tussen optimistic en pessimistic locking. Bij optimistic locking gebruikt Velocity wat extra metadata in de vorm van een versienummer. Een update op de gegevens in de cache lukt dan alleen als je ook het juiste versienummer van die data hebt. Heeft iemand anders dat nummer in de tussentijd opgehoogd, dan zal de wijziging falen.

In het pessimistic locking scenario leg je expliciet een lock op het object in de cache en kan alleen de houder van het lock de gegevens wijzigen en het lock weer vrijgeven.

Het is wel belangrijk om te beseffen dat Velocity geen transacties over meerdere items heen ondersteunt. In een pessimistic locking scenario moet de applicatie goed de volgorde van acties en het leggen van locks bewaken om deadlock situaties te voorkomen. Velocity heeft zelf geen deadlock detectie, dus dat moet je in de applicatie verzorgen.

Velocity doet in CTP2 nog niets aan beveiliging. Objecten worden nog niet beveiligd tegen ongeautoriseerde toegang en er is ook nog geen moeite gestoken in b.v. het coderen van gevoelige gegevens. Hoewel je je moet afvragen of het verstandig is om gevoelige gegevens te cachen, moet je er dus wel rekening mee houden dat deze objecten in het geheugen van je computer kunnen zijn geladen. Ze zouden door kwaadwillenden kunnen worden uitgelezen. Het Velocity team werkt momenteel aan een model voor security. De ideeën lopen uiteen van een systeem met ACL’s (Access Control Lists) of het gebruik van een simpele sleutel per region of object. In de afweging wordt vooral gekeken naar een goed evenwicht tussen beveiliging en goede performance.

 “Traditioneel” gegevensbeheer, zoals constistency, concurrency en beveiliging, is nog steeds belangrijk in de cache

Geheugenbeheer

Eerder werd al genoemd dat Velocity een cache-aside is. Dit betekent dat de applicatie verantwoordelijk is voor het beheer van de gegevens in de cache: de applicatie bepaalt of gegevens nog geldig zijn en wanneer ze moeten worden vervangen.

Velocity zorgt echter wel voor efficiënt geheugenbeheer en houdt daarbij rekening met de kaders die je stelt bij het aanmaken van een gedistribueerde cache. Deze kaders worden uitgedrukt in twee strategieën: expiration en eviction.

Expiration gaat over de geldigheid van gegevens. Je kunt aan gegevens een bepaalde levensduur (time-to-live) meegeven. Wanneer deze levensduur is verstreken, zal Velocity de gegevens verwijderen uit de cache.

Het verwijderen van items hangt nauw samen met eviction. Eviction is het verwijderen van cache items op basis van een Low en een High Watermark. Als je een cache aanmaakt, kun je een low en een high watermark als kaders opgeven. Deze watermarks zijn een soort barometers die bepalen wanneer Velocity moet gaan opruimen. De low watermark geeft aan bij welk geheugengebruik Velocity moet beginnen met opruimen van items waarvan de levensduur is verstreken. Als de high watermark is bereikt, dan gaat Velocity objecten opruimen ongeacht de levensduur. Bij deze laatste vorm van eviction verwijdert Velocity wel als eerste de objecten die het langst niet zijn gebruikt. Dit gaat op basis van het least-recently-used (LRU) algoritme.

Als je in je oplossing gebruik maakt van expiration en/of eviction, dan is het dus belangrijk om je bewust te zijn van het gedrag dat Velocity dan vertoont. Bij caching in zijn algemeenheid kun je er niet altijd van uitgaan dat gegevens ook daadwerkelijk beschikbaar zijn in de cache en je applicatie is ervoor verantwoordelijk dat ontbrekende gegevens worden aangevuld of ververst. Het Velocity team heeft wel toekomstplannen voor het automatisch aanvullen van de cache op het moment dat objecten niet (meer) in de cache zitten.

Hoe gebruik ik Velocity?

Grofweg zijn er twee manieren waarop je Velocity kunt inzetten in je applicatie: als een expliciete cache-aside en voor sessiemanagement in webscenario’s. In het eerste geval heb je een client API ter beschikking waarmee je objecten in de cache kunt stoppen of eruit kunt halen. Voor sessiemanagement heeft Velocity een provider. Als je Velocity wilt inzetten als sessionstate-provider, dan is het wel belangrijk de cache die je daarvoor gebruikt zodanig te configureren dat sessies niet zomaar verloren gaan. Denk daarbij aan het eerder beschreven eviction en expiration gedrag. Eviction zal moeten worden uitgeschakeld. Verder kan het handig zijn de standaard expiration van 10 minuten te verhogen naar bijvoorbeeld een half uur. Sessiegegevens zijn belangrijk, dus het aanzetten van de high availability eigenschap van Velocity is in dit geval ook een goed idee. Dit alles doe je via de PowerShell beheertool met de opdracht in listing 1.

Set-CacheConfig –CacheName MijnSessionCache
  –Eviction none –TTL 30 –Secondaries 1

Listing 1: Cache configureren voor session state via PowerShell beheertool

Bovenstaande opdracht schakelt eviction uit (“-Eviction none”), stelt de expiration periode in op 30 minuten (“-TTL 30”) en schakelt high availability in (“-Secondaries 1”).

Als je eviction uitschakelt, loop je wel de kans dat het geheugen volloopt, omdat objecten niet meer worden opgeruimd tenzij de houdbaarheid verloopt.

Om CTP2 te kunnen gebruiken moet je referenties maken naar twee DLL´s: CacheBaseLibrary.dll en ClientLibrary.dll. Deze vind je na installatie in %PROGRAMFILES%\Microsoft Distributed Cache\v1.0.

Listing 2 laat zien hoe je toegang krijgt tot de cache en welke methodes je onder andere kunt aanroepen om de data in de cache te manipuleren. In het eerste deel van de code wordt de cache-client geconfigureerd. De code geeft aan met welke cache-host hij communiceert, dat het een simple client is en dat de local cache ingeschakeld is. Je ziet dat hier expliciet de naam van een cache-host wordt opgegeven. Er is altijd één host die je als eerste aanspreekt om toegang te krijgen tot de cache, maar de Velocity infrastructuur zorgt ervoor dat je ook bij de andere hosts binnen het cluster uitkomt als dat nodig is.

//--------------------------
// Cache client configureren
//--------------------------

//We communiceren met 1 cache host
ServerEndPoint[] servers = new ServerEndPoint[1];

//Cache Host Details
//  Parameter 1 = host name
//  Parameter 2 = cache port number
//  Parameter 3 = cache service name
servers[0] = new ServerEndPoint("localhost",
  22233, "DistributedCacheService");

//Routing of Simple Client
// False = Simple Client (geen routing table)
// True = Routing Client
bool routingClient = false;

//Local cache of niet
// True = Wel local cache
// False = Geen local cache
bool localCache = true;

//Geen logging van cache exceptions
CacheFactory.DisableLogSinks();

//Configuratie meegeven aan CacheFactory constructor
myCacheFactory = new CacheFactory(servers,
  routingClient, localCache);

//Vraag de "default" cache op
myDefaultCache = myCacheFactory.GetCache("default");

//----------------
// Cache gebruiken
//----------------

//Maak een region aan in de cache
myDefaultCache.CreateRegion("DemoRegion", true);

//Zet objecten in DemoRegion, beiden met twee tags
//Widget is een class met DataContract en DataMember attributen
Tag[] tags = new Tag[] { new Tag("lifestyle"),
  new Tag("work") };
myDefaultCache.Add("DemoRegion", "key1",
  new Widget("Widget101"), tags);
myDefaultCache.Add("DemoRegion", "key2",
  new Widget("Widget102"), tags);

//Zoeken op tags
List<KeyValuePair<string, object>> results =
  myDefaultCache.GetAnyMatchingTag("DemoRegion",
    new Tag[] { new Tag("work") });

foreach (KeyValuePair<string, object> kv in results)
{
  Console.WriteLine(kv.Key + ": " +
    ((Widget)kv.Value).Name);
}

//Zet een waarde buiten een region
myDefaultCache.Add("key2", "Testwaarde2");

//Zet een waarde via indexer
myDefaultCache["key3"] = "Testwaarde3";

Listing 2: Gebruik van Velocity vanuit code

Je hoeft de cache-client niet altijd vanuit code te configureren. Dat kan ook in de App.config. Listing 3 geeft een voorbeeld van dezelfde configuratie als in het C# codevoorbeeld, maar nu in App.config.

<configuration>
  <configSections>
    <section name="dcacheClient"
       type="System.Data.Caching.DCacheClientSection,
         CacheBaseLibrary"
       allowLocation="true"
       allowDefinition="Everywhere"/>
  </configSections>

  <!-- Simple client -->
  <dcacheClient deployment="simple">
    <!-- Local cache staat aan -->
    <localCache isEnabled="true"
       sync="TTLBased"
       ttlValue="300" />
      <hosts>
        <!-- Cache host configuratie -->
        <host name="localhost"
          cachePort="22233"
          cacheHostName="DistributedCacheService"/>
    </hosts>
  </dcacheClient>

</configuration>

Listing 3: Configuratie van Velocity in App.config

De eigenschappen van Velocity, zoals het schaalbaar, gedistribueerd en highly available zijn, hebben ook voordelen in webapplicaties die draaien in grote webfarms. In ASP.NET heb je voor sessiemanagement de keuze uit in-process, SQL Server of een State Server. ASP.NET gebruikt daarvoor een provider model, waardoor je gemakkelijk kunt wisselen zonder de applicatie te hoeven aanpassen. SQL Server en State Server zijn de opties die je overweegt wanneer je applicatie flink is opgeschaald en draait op meerdere webservers, zeker als je geen sticky routing toepast. Bij sticky routing wordt dezelfde gebruiker voor ieder request telkens door dezelfde web server bediend.

Nu we de kracht van Velocity kennen, zou het handig zijn ook meteen hier het sessie-management te beleggen. Dat kan, want Microsoft levert een ASP.NET sessionstate-provider op basis van Velocity. Listing 4 toont hoe je deze kunt configureren.

<!-- Overige configuratie weggelaten voor duidelijkheid -->
  <sessionState mode="Custom" customProvider="Velocity">
    <providers>
      <add
        name="Velocity"
        type="System.Data.Caching.SessionStoreProvider"
        cacheName="MijnSessionCache"/>
    </providers>
  </sessionState>

Listing 4: Configuratie van session state provider op basis van Velocity

Afwegingen voor configuratie

Velocity kun je in verschillende configuraties toepassen. Welk scenario past nu het best bij datgene wat je wilt bereiken? Tabel 1 geeft een overzicht van de effecten die een bepaalde configuratie met zich meebrengt.

Tabel 1: Verschillende configuraties en hun effecten

De configuraties in tabel 1 kunnen worden gecombineerd. Je kunt dus een gepartitioneerde cache maken die highly available is. Het verlies aan performance door high availability te gebruiken kun je compenseren door een local cache toe te passen.

Een kijkje in de toekomst

De CTP’s tonen al een aardig werkend product. Maar er zijn nog zaken waar het team aan werkt. Naast het continu verbeteren van de schaalbaarheid en snelheid wordt gekeken naar betere manieren om de cache te monitoren voor diagnose van problemen. Verder staan voor versie 1.0 de volgende zaken op de planning:

1. Notificaties vanuit de cache bij wijzigingen in objecten, zodat clients hierop kunnen anticiperen;
2. Beveiligde toegang tot named caches;
3. Bulk operaties met meerdere objecten;
4. Read thru/write behind ondersteuning.

De read thru/write behind ondersteuning is er één die een beetje tegen de cache-aside filosofie indruist. Read thru betekent dat de cache automatisch terugvalt op een back-end service of database wanneer een object niet kan worden gevonden in de cache. Write behind houdt in dat Velocity een wijziging in een item in de cache (asynchroon) doorstuurt naar de back-end. Hiermee wordt Velocity meer dan een cache-aside, namelijk de spil tussen applicatie en gegevensbronnen. Persoonlijk ben ik benieuwd naar de manier waarop Microsoft dit gaat oplossen. Ik denk dat een uniforme toegang tot gegevens hiervoor noodzakelijk is, dus ik verwacht rechtstreekse koppelingen met SQL Server tabellen of REST style interfaces zoals als die van ADO.NET Data Services.

Op de roadmap staan verder nog zaken als het ondersteunen van LINQ queries op de cache en Velocity in the cloud. Deze zaken zullen waarschijnlijk na versie 1.0 aan Velocity worden toegevoegd. Op deze manier is Microsoft bezig om technologieën, die op zichzelf al nuttig zijn, op een slimme manier te combineren.

Conclusie

In een gedistribueerde applicatie, waar gegevens uit meerdere heterogene bronnen afkomstig zijn, is caching bijna onmisbaar. Het zorgt voor snellere toegang tot data, betere beschikbaarheid en grotere schaalbaarheid. Er zijn meerdere oplossingen op de markt maar Velocity is een veelbelovende nieuwe speler. Het is gratis beschikbaar komen als losse release naast het .NET framework.

Velocity is veelzijdig doordat het in uiteenlopende scenario’s inzetbaar is, van een in-process cache tot volledig gedistribueerd en highly available en zelfs als session state provider voor ASP.NET.

Referenties

• Velocity team blog: http://blogs.msdn.com/velocity
• Voorbeeld code: http://code.msdn.microsoft.com/velocity
• Velocity whitepaper: http://msdn.microsoft.com/en-us/library/cc645013.aspx
• PDC 2008 Sessies (waaronder over Velocity): https://sessions.microsoftpdc.com