CouchDB i Key-Value Stores.

Avui he estat a una presentació de Jan Lehnard sobre CouchDB. Podeu trobar les slides aquí.

CouchDB és una key-value store, i aquest és justament el primer post sobre aquest tema. En vindran molts més ja que és un tema molt extens i molt interessant, si més no per mi. Bàsicament podriem dir que una key-value store és una base de dades molt senzilla distribuïda per la xarxa, també hi ha qui ho enten com una taula de hash gegantina distribuïda en diversos ordinadors. I molt més pensada per a l'eficiència dels gets/sets que a per la complexitat que poden tenir altres bases de dades com Postgres o Mysql.

Una de les coses que m'ha fet pensar més de la xerrada és la quantitat de key-value stores que hi ha actualment. La majoria són bastant noves i tot i que totes serveixen pel mateix, emmagatzemar i obtenir certs valors, els seus dissenys són totalment diferents i fan que cadascuna tingui la seva sortida de mercat.

Aquí podeu trobar un post molt complert i interessant sobre key-value que va fer l'RJ (CTO de last.fm)

Unes pinzellades per a qui li faci mandra llegir-se tot l'article o li faci cosa perquè està en anglés:

Les principals diferències de disseny de les key-value stores que convé mirar abans d'adoptar-ne una, o bé que s'han de tenir en compte són:

• Tolerància a fallades: Les key-value stores normalment estan en màquines dedicades, i més d'una màquina, per tant diem que tenim 5 màquines servint l'informació. Què passa si una de les màquines s'espatlla de cop?. Depenent de la tolerància a fallades de la key-value store pot ser que no passi res, o que tinguem un problema gros. Entre els tipus de tolerància a fallades que són més normals destacaria:
  
  
  
  • Replicació: Tant senzill com tenir més d'una còpia de cada valor que es serveix. Si cau una màquina no passa res perquè hi haurà alguna altre màquina que també té aquest valor. Lògicament gastem més espai del necessari, però és el preu a pagar.
  
  
  • Particionat: No és una tècnica en si sola, sino que és una millora del mètode anterior, si els valors són grans (fitxers, mp3, imatges) podem partir el fitxer en diversos trossos i repartir-los (amb redundància o replicació) per diverses màquines.
    
  
  
• Persistència: Normalment aquests mecanismes tenen totes les dades a memòria RAM. Amb això ens estalviem tot el temps d'I/O a disc. Lògicament fa que quedi poca RAM per altres coses, però és el preu de la velocitat. Ara bé, de nou, què passa si hem d'apagar la màquina?. N'hi ha que guarden els valors en una base de dades relacional, ja sigui Mysql, Berkeley, etc. Així, al engegar agafen tota la informació de la base de dades i la posen a memòria. Treballen en memòria i finalment, quan s'apaga la màquina es guarda de nou a la base de dades. N'hi ha d'altres que ho serialitzen utilitzant llibreries natives dels llenguatges de programació en que estan implementades i fins i tot n'hi ha que _no_ guarden res. Quan s'apaguen es perd tot!, normalment són utlitzades com a caches.


• Accés: Molt bé, tenim molta informació, però com hi accedim?. N'hi ha que porten les seves pròpies llibreries en diversos llenguatges, n'hi ha que utilitzen HTTP (sempre REST, mai SOAP) i n'hi ha d'altres que ofereixen interficies de thrift o protocol buffers (hi haurà tot un post sobre aquests dos, no patiu, són mecanismes de serialització / RPC, el primer fet a facebook i el segon fet a google).


• Eficiència: Lògicament, s'ha de parlar d'eficiència. Tant en temps d'accés a les dades (quan tardes en fer un GET, quan tardes en fer un PUT?) com en l'eficiència d'ús de recursos que utilitzen les màquines per servir l'informació.
  

En pròxims posts entraré una mica més en detall en implementacions concretes i en les key-values stores que considero més interessants.