Vi har de sista veckorna upplevt en ökad last på vår databasserver. Vi tweakade dels lite kod och lade på några index på rätt ställen och simsalabim!

Se och njut!

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

På sikt när vårt data växer kommer vi mest sannolikt implementera kopplingar mot nån en av de två stora utmanarna till Googles BigTable. Hypertable eller HBase. Hypertable verkar helt frankt mer lovande men har inget Java API än. De lovar att de ska ha det i version 1.0 som borde komma any-minute. Är med i HBase’s mailinglista och den är inte speciellt aktiv, vilket ger mig en mindre bra magkänsla av engagemanget i communityn.

Distribuerade kolumnbaserade databaser det man ska satsa på om man har en write-some-read-most arkitektur och vill uppnå maximal read-throughput. Tror inte MySQL kluster uppnår detta i dagsläget tyvärr.