NoSQL – MySQL och memcached på väg bort

Jag ser fler och fler välja alternativa lösningar till MySQL och memcached och väljer då istället exempelvis Redis eller Cassandra. Ryan King som jobbar på Twitter intervjuades nyligen och berättade att de håller på att gå över till Cassandra för att lagra deras ofantliga mängder med tweets.

Som jag har skrivit tidigare så använder jag Redis för alla mina nya projekt men ser även till att ha en kopia kvar i MySQL för att Sphinx skall indexera fritext. Men jag kommer förmodligen att skippa MySQL helt snart eftersom Sphinx även kan läsa in exempelvis fritext från XML som kan genereras från innehållet i Redis.

När jag startar mitt nästa projekt så kommer jag att skippa MySQL och memcache helt och försöka att bygga en lösning som enbart förlitar sig på Redis (och Sphinx så klart).

Kategorisering av de olika lagringstyperna:

  • Key-value stores: Redis, Scalaris, Voldmort, and Riak.
  • Document stores: Couch DB, MongoDB, and SimpleDB.
  • Record stores: BigTable, HBase, HyperTable, and Cassandra.
  • Scalable RDBMSs: MySQL Cluster, ScaleDB, Drizzle, and VoltDB.

Glöm inte läsa denna rapport som nyss släpptes på ämnet:

High Performance Scalable Data Stores av Rick Cattell

NoSQL here we come.

6 reaktioner på ”NoSQL – MySQL och memcached på väg bort

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

  2. 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 =-.

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

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

  5. 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?

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

Kommentera

E-postadressen publiceras inte. Obligatoriska fält är märkta *

Följande HTML-taggar och attribut är tillåtna: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>