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

Nu har vi uppgraderat bloggarna till wp-2.5. Det var ingen barnlek eftersom vi ändrat mallarna så pass mycket.

Passade på att installera Gengo också, får se hur bra det fungerar.

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.

I fredags öppnades mina ögon en aning när jag förstod att de javascript som man inkluderar faktiskt kan köra kod från det anropande scriptet. Det konstiga är egentligen att jag inte förstått det tidigare eftersom jag skrivit en diger mängd javascript som inkluderar andra javascript. Nåväl det som är coolt och lite nytt för mig är att man på detta sätt kan “plantera” callback funktioner och i dessa callback funktioner passar det ju utmärkt om man för in JSON data som är evaluerad och klar att användas på klienten.

Exempel:

mydomain1.com/client.html:

<script src=”http://mydomain2.com/client.js”></script>

mydomain2.com/client.js:

function myCallback(data)
{

var theDate = data.date;

//handle theDate…
}

var req = ‘http://mydomain2.com/server.js’;
document.write(”<scr”+”ipt></scr”+”ipt>”);

mydomain2.com/server.js:

myCallback({”date”:new Date()});

Självklart ska server.js vara en server-side komponent.

Det som är helt suveränt är att man kan sluta krångla med iframes och document.domain odyl och bara skriva fina webbtjänster a’la REST som sprutar ur sig JSON. Nu återstår egentligen en enda sak för mig och det är att kunna göra exakt ovanstående men synkront. Denna metod är ju asynkron då browsern kommer ladda tredjepartsscriptet efter att detta script är färdigevaluerat. Om nån vet hur man gör synkrona requests cross-domain så får man gärna kommentera här Exempel på hur man gör inom en domän: Synchronous javascript

Uppdatering: Läste igenom hur man kan göra samma sak med XhrIframeProxy, vilket är ett ramverk som DOJO bjuder på. Lärde mig också att servern måste sätta content-type till text/javascript för att det anropande scriptet ska autoevaluera det.

Jag och Peter rackade upp några nya servrar i vår serverhall för några veckor sen. Nu har vi mer skön prestanda till bjuds.

Tailsweep är i stark tillväxttakt och ska inom kort ut på nya jaktmarker.

Snart ska vi crawla hela den kända bloggosfären och behöver utvecklare som stimuleras av att utmana annons och sökjättarna internationellt.

I sökplattformen kommer du bekanta dig med tekniker såsom Hadoop, Solr, Lucene, Nutch och klustrade filsystem. Du kanske gillar att klassificera innehåll med Naive Bayes och NGram analys eller kanske bygga en dataminingplattform för träffsäkrare och relevantare annonser? Är du en crawlingnörd? Ja då har vi en hel egenutvecklad plattform som du kommer älska att leka med.

I annonsplattformen får du vara med och se och påverka hela bolagets livscykel från att en säljare tar fram en offert, tills att en sajtägare får betalt för sin annonsyta. Du är med i hela kedjan. Du hackar Hibernate, Spring, Velocity och kanske ett och annat shellscript. Här är användbarhet a och o och du får snabb feedback från våra sajtägare.

Du kanske gillar statistik ? Vi har byggt en state of the art lösning som är en sorts datawarehouse on the fly och är hjärtat i hela Tailsweep då de flesta komponenter på ett eller annat sätt är kopplade till den. Den har numer stöd för Geo-Targeting och vi lägger på nya funktioner dagligen.
Intresserad ? Skicka ett mail till job@tailsweep.com med din CV så kontaktar jag dig och sätter upp ett möte.

Med vänlig hälsning

//Marcus Herou, CTO Tailsweep AB

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).

Vi kör nu vår första kampanj där geo targeting är påslaget. Denna kampanj riktar sig endast mot Stockholmare. Cool teknik där spatiala index i kombination med regionshiarkier utgör basen.

Tog ett tag för mig att få en slav att replikera en annan slav. Uppenbarligen skall man explicit tala om att slaven ska logga sina uppdateringar. Lösningen hittades här