Hej.

Vi utvärderar as we speak Voldemort & Cassandra för vårt bloggdata. Än så länge vinner Cassandra i den utvärderingen av några skäl.

1. Cassandra är en sorterad hash av hashar av hashar, Voldemort är ju en hash
2. Rikare community
3. Lägre latency i lookups och högre throughput
4. Minst sagt skapliga referensimplementationer, Voldemort har ju LinkedIn men FB, Digg & Twitter känns ju tyngre.

Dock ska tilläggas att Voldemort gick snabbare att komma igång med klient-mässigt än Cassandra som java-mässigt har en del att önska. (Hur tex en ColumnPath skapas)

Vi har testat HBase men den är så jäkla fullblown att det är svårt att testa den lokalt på en enda maskin, vilket gör att man blir lite ”rädd” för den.

Du behöver:
1 st ZooKeeper (3 i prod)
1 st HBaseMaster
1 st HRegionServer (massor i prod)
1 st HDFS DataNode (massor i prod)
1 st HDFS NameNode (”Brutalt” med minne krävs)

Detta bara för att testa om det överhuvudtaget funkar…

Fast nu när jag skrivit detta så måste jag nog banne mig utvärdera HBase en gång till… Jag gillar ju St.Ack o company.

Memcached är ju en key-value store och är större än någonsin. Det finns en anledning till att en hel uppsjö med mjukvara använder samma protokoll – varför listas den inte bland de andra key-value lagringarna?

Är också intresserad av att höra vilket problem du försöker lösa när du byter bort memcached?

Tack Jens för intressanta kommentarer!

C. Davén: När jag gör sökningar i SQL nu för tiden så söker jag enbart på ID:n för annars så skulle det gå för långsamt. Så därför så är det bara att lagra i KVS på ID och sätta en array där istället exempelvis

Hej igen,

Uppföljning: Erlangs databas ”Mnesia” stödjer (tillsammans med ”fragmentron”) distribuerad lagring/replikering/fragmentering och kan således göra precis det som Cassandra gör.

C. Davén: Idéen med key-value storages (KVS) är att de är väldigt flexibla och därför är det också svårt att säga exakt hur man ska göra. Vanligtvis brukar man i KVS använda sig av prefix, och nån typ av avdelare (:) för att simulera en tabell i en RDBM:s. Han man t.ex. en tabell med namn, ålder och längd på personer så kan man lika gärna spara denna som:
=
person:Calle:length = 2.73
person:Calle:age = 43
person:Arnold:length = 1.43
person:Arnold:age = 34
person:list = ”Calle|Arnold”

Anledningen att jag lagt till prefixet ”person:” är för att jag senare kanske vill lägga in en annan ”tabell” i min KVS. Självklart är det dumt i exemplet ovan om en person har ett namn som innehåller ett kolon.

Redis kan även hantera listor och därför kan person:list istället lagras på formen
person:list = ["Calle", "Arnold"]

Sist men inte minst så kan du t.ex. själv hålla reda på en lista över alla personer över två meter (index):
person:list_all_above_two = ["Calle"]

Några tankar,
Jens

Känner du till någon bra guide till hur man ”tänker i” key-value-databaser istället för relationsdatabaser? Det är ju inte bara att byta och jobba på samma sätt.
.-= C. Davén senaste inlägg blog ..Ärlighet varar längst =-.

Intressant! Tack för länken till rapporten. Den verkar sammanfatta ett mycket spännande område just nu!

Jag och en kollega testade Cassandra för inte särskilt länge sedan. Vi funderade på om det var något att använda skarpt/i produktion. Dock blev vi lite oroade av de stacktraces som Java ibland spottade ur sig ibland, och vi misstänkte att även om Facebook kör det på 600 noder så finns det en anledning varför de samtidigt lagrar informationen på annan plats. Kanske hade vi inte konfigurerat Cassandra korrekt, vad vet jag?

Detta sagt så verkar det upperbarligen som att Cassandra uppfyller Twitters krav – vilket inte är illa(!) – och i annat fall kommer att leda till att Twitter ser till att Cassandra är stabilt som fan. Det verkar ju som att de vill byta ut hela sin MySQL-backend mot det.

För övrigt har jag kikat på det distribuerade programmeringsspråket Erlang de senaste två veckorna och jag tror inte att det verkar väldigt svårt att implementera något likt Cassandra i det… Programmeringsspråket känns nästan som gjort för det. CouchDB, som är skrivet i Erlang, skalar idag inte på bredden men jag såg precis att det ligger i planeringsstadiet: http://wiki.apache.org/couchdb/Partitioning_proposal