Jag skrev häromdagen att jag inte ska titta på HBase pga prestanda. Jag kunde dock inte motstå att prova att göra en implementation. Det återstår att testa prestandan men jag är rädd att det är kraftig tradeoff genom att använda det underliggande HDFS. Mer om detta senare alltså.

Jag har implementerat ett Map interface som använder HBase som storage. Som vanligt kan man utföra put/get/remove kommandon. Denna implementations karaktäristik är att den vanligen ska innehålla enorma datamängder och därför är ytterligare några metoder implementerade tex keyIterator() och valueIterator() som öppnar en “cursor” mot HBase och den underliggande HDFS implementation.

Detta är en utmärkt tutorial i HBase eftersom alla CRUD operationer finns med i en och samma klass samt att implementationen har ett syfte från start, vilket gör ingången låg till HBase.

Jag har byggt denna kod mot HBase-1.2 och man behöver följdaktligen denna jar i sin CP för att få det att fungera.

HbaseCache är en klass i AbstractCache

Du hittar den i 1.3-SNAPHOT

Under en tid så har vi använt en HashedDiskCache för persistens av våra inlägg då MySQL inte lämpar sig för uppgiften. Jag har funderat på varför den har varit aningens seg på att skriva. Då visar det sig att det egentligen är jdbm som är seg som ett träsktroll. Den används som db för att hålla koll på vilka nycklar som hör ihop med vilka filer. Helt enkelt en HashMap på disk.

Nu hittade jag ett riktigt snabbt bibliotekt i Apache Xindice där man kan välja på antingen en lösning som funkar som en hashmap eller ett bträd. De är ungefär lika snabba och läser 64kb chunkar i hela 80MB/sek! Det är riktigt snabbt eftersom det inte är sekventiell läsning vi pratar om.

För skojs skull byggde jag en lösning som använder Lucene i botten som lagring och gissa om den också är snabb. Dock så är den inte atomär (än) eftersom jag har sagt åt den att flusha själv baserat på RAM. Den kommer då spara indexet asynkront. Den behöver också optimeras med tex statistikräknare som håller koll på när det är dags att den ska optimera sig själv. Om man inte flushar asynkront sjunker skrivhastigeheten från ca 50MB/sec till ca 1MB/sec, vilket inte är acceptabelt.

Här hittar du LuceneCache och TreeCache (xindice).

Nu använder sig SymmetricJgroupsCacheStrategy av strömmar när slavarna hämtar stt initiala tillstånd. På så sätt kan man undvika att få OutOfMemoryException om cachen är stor. En cache på 500MB är inte precis smart att allokera i en enda stor byte array buffert. Läs mer om JGroups

Den första publika open source versionen av AbstractCache är nu släppt. Jag utvecklade denna lösning då jag jobbade på Eniro. Dock så ville jag fortsätta utveckla denna lösning efter att jag lämnade och Eniro uppmuntrade mig att släppa den som ett Open Source projekt. Tack Linus!

Den är testad under ganska extrema förhållanden men behöver naturligtvis hela tiden förbättras.

AbstractCache är ett javaprojekt som satsar på att hantera lagring av data som är nyckel/värde baserad dvs kan ett värde kan letas upp med hjälp av en nyckel. Semantiskt ex. $cache->get($key)

För närvarande finns det stöd för Minnes, Disk och replikerade cachar.

Minnescacharna kan delas upp i tre grupper.

• LRU - Least Recent Used - Håller en MRU lista med LRU policy i minnet - Jag har i nuläget 4 implementationer men favoriserar två
• LFU - Least Frequently Used (bäst). De nycklar som används minst kastas först - 2 implementationer just nu.
• Hash - Obegränsad minneslagring - Ytterst snabb - En implementation som wrappar en HashMap.

De diskcachar som det finns stöd för idag.

• Btree - En b+tree lösning som använder sig av JDBM. Nycklarna är sorterade på samma sätt som en java.util.TreeMap och implementerar också SortedMap.
• Htree - En snabbare osorterad lösning som är hashbaserad.
• HashedDiskCache - En fil per nyckel/värde - Mycket stabil men inte lika snabb.

Distribuerade cachar

• MemCached - En wrapper kring Greg Whalin’s MemCached klient men följer java.util.Map interfacet
• Hdfs - En cache som använder sig av Hadoop Distributed File System som lagring. Mycket skalbar lösning men inte så snabb.
• Jgroups - Symmetrisk - En distributionsmekanism som ska garantera att alla noder som är anslutna har samma tillstånd i varje ögonblick.
• Jgroups - Assymmetrisk - Fungerar ungefär som MemCached men man kan ange hur många noder som skall innehålla samma nyckel/värde par.

+ en massa annat smått och stort bla.

• Stöd för Hibernate 2nd level cache.
• OsCache wrapper
• Timade cachar och mappar
• Cache som sparar dess tillstånd periodiskt och vid nedstängning.
• Acegi User Cache

TODO

• Förbättra Jgroups replikeringen.
• Bygga stöd för distribuerad Lucene indexering av det data som läggs i cachen.
• Lägga till en wrapper för EHCache
• Lägga till en wrapper för JBoss TreeCache
• Bygga en buffrad cache som kan öka prestanda på de diskbaserade lösningarna mångfalt.
• Bygga en cache som tar en lista av andra cachar och sparar tillståndet till/från dem i specificerad ordning. Tex en jgroupscache som backas av en minnescache som i sin tur backas av en diskbaserad.
• Slutligen wrappa ihop min CacheServer som använder sig av NIO. Detta är inte så hög prio då det finns andra serverlösningar som är ganska snabba.
• Plocka upp stöd igen för min rmilösning som jag slutade använda mig av för några år sen då det var så struligt att starta stoppa RMI processen inifrån webbapplikationer.