CouchDB conosciamolo meglio

couchDBQuesto articolo e’ la continuazione della precedente “Introduzione a CouchDB” per cui riprenderemo alcune informazioni di base gia viste per poi allargare alcuni importanti concetti ed aspetti che riguardano questo interessantissimo documentale via HTTP.


Apache CouchDB
e’ un moderno documentale, document-oriented, richiamabile semplicemente con l’HTTP e che al tempo stesso offre le piu’ avanzate funzionalita’ di replicazione dati e di ricerca in parallelo (Map/Reduce).

Caratteristiche

Scritto in: Erlang
Punto principale: Consistenza DB consistency, facilità d’uso
Licenza: Apache
Protocolli: HTTP/REST
Replicazione bidirezionale continua o ad-hoc con individuazione dei conflitti, replicazione master-master
MVCC – le operazioni di scrittura non bloccano le letture
Sono disponibili le versioni precedenti dei documenti
Progettazione crash-only (reliable)
Necessità di compattazioni nel tempo
Viste: embedded map/reduce
Viste formattate: lists & shows
Possibilità di validazione server-side dei documenti
Possibile autenticazione
Aggiornamenti real-time attraverso _changes (!)
Gestione degli allegati e, CouchApps (standalone js apps)
libreria jQuery inclusa
Utilizzo ideale: Per accumulazione dei dati con cambi occasionali sui quali vengono eseguite query predefinite. Situazioni in cui la gestione delle versioni è importante.
Per esempio: CRM, sistemi CMS. Situazioni in cui la replicazione master-master è una caratteristica interessante (ad esempio multisito).

In CouchDB non esistono tabelle. Il contenuto informativo è suddiviso in diversi database che fungono da contenitori di documenti con strutture potenzialmente disomogenee tra di loro. Il documento è il fulcro di questo software (e di quelli che come lui condividono l’approccio document-oriented).
Un documento è formato da un insieme di coppie chiave-valore.
A differenza dei database relazionali CouchDB non possiede il concetto di schema e quindi ogni documento in ogni database può essere strutturato in modo diverso dagli altri.

Le uniche due chiavi obbligatorie sono:
_id serve per identificare univocamente il documento (è comparabile, semanticamente, alla chiave primaria dei database relazionali)
_rev viene utilizzata per la gestione delle revisioni, ad ogni operazione di modifica infatti la chiave “_rev” viene aggiornata (questo meccanismo è alla base della prevenzione dei conflitti
in fase di salvataggio su CouchDB).

Questo accorgimento permette inoltre di poter interrogare il DBMS su versioni del documento non più attuali in quanto, con un approccio simile a quello di Subversion, CouchDB mantiene memoria di ogni revisione, da quella iniziale alla più recente.

L’altra grande differenza rispetto ai tradizionali RDBMS è il meccanismo di gestione delle query. Nei database relazionali una volta specificate e popolate le tabelle è possibile eseguire query utilizzando un linguaggio conosciuto come SQL (ne esistono vari dialetti ma il concetto non cambia nell’essenza);
a fronte di una query il RDBMS utilizza indici interni e le proprie relazioni per costruire in tempo reale una tabella di risultato (che può, nelle query più semplici, essere un sottoinsieme della tabella di partenza).

Questa soluzione riesce ad essere performante in quanto i dati sono strutturati con questo preciso scopo; inoltre il database non deve conoscere a priori le query che verranno eseguite ma può rispondere a qualsiasi interrogazione, purché sia stilata usando SQL valido.

Consistenza dei dati e replicazione

CouchDB non utilizza alcun meccanismo di locking ma sfrutta l’MVCC (Multiversion Concurrency Control): ogni modifica di un oggetto ne crea una nuova versione. Le versioni precedenti non vengono cancellate. Se due modifiche vanno in conflitto poiche’ accedono allo stesso documenti, la seconda riceve un errore in save. L’applicazione deve riprendere l’ultima versione del documento e rieseguire l’UPDATE.
L’isolamento e’ mantenuto solo a livello di un singolo documento, questa e’ una notevole semplificazione, rispetto alla complessa logica transazionale di altri database, ma consente l’ottimizzazione, la parallelizzazione e la distribuzione dei dati in modo semplice. A livello di accesso al file di dati ogni singola modifica ad un documento rispetta le proprieta ACID (Atomic Consistent Isolated Durable) con la serializzazione delle modifiche sui documenti e la scrittura sincrona sul disco.

Piu’ database CouchDB possono essere collegati tra loro in modo molto semplice. I database vengono aggiornati tra loro con una replicazione peer-to-peer incrementale implementata nativamente nell’engine. CouchDB permette una replicazione bidirezionale asincrona, utilizza un meccanismo automatico di risoluzione dei conflitti e fornisce una eventual consistency tra i database. Se i database sono ospitati su nodi differenti si ottiene con questo la distribuzione dei dati.
La replicazione di CouchDB puo’ essere utilizzata sia per sincronizzare database locali che per complesse configurazioni con sharding dei dati.

Per lavorare su CouchDB esiste anche la possibilita’ di installare CouchApp, in pratica una serie di script che permettono di costruire completi applicazioni stand-alone per il database usando solo HTML e JavaScript. Poiche’ il database stesso risponde in HTTP e’ possibile concentrare su un solo nodo (eventualmente replicabile) la classica pila applicativa web a tre livelli.

CouchDB si e’ cosi’ rapidamente imposto sul mercato, diventando uno tra i piu’ usati database non relazionali. In pratica i due piu’ diffusi NoSQL documentali sono CouchDB e MongoDB: entrambi sono velocissimi (memorizzano i dati in BSON/JSON), sono scalabili in modo nativo su piu’ nodi e non forniscono un’interfaccia SQL.

Per una documentazione piu’ dettagliata si rimanda al sito ufficiale di Apache CouchDB.

 

Per ora e’ tutto, alla prossima e, buon divertimento!

GlusterFS: Storage Scalabile e Distribuito

glusterfsIntroduzione

GlusterFS è un file system open source distribuito e scalabile orizzontalmente, la cui capacità può essere dinamicamente espansa mediante l’aggiunta di nuovi nodi. GlusterFS è in grado di arrivare a gestire fino a diversi Peta Byte, migliaia di client e diverse aree dati (storage) organizzandole in blocchi che rende accessibili su Infiniband RDMA (remote direct memory access, fibra ottica) o connessioni TCP/IP.

Le risorse {memoria e disco} vengono rese disponibili sotto un unico punto di condivisione e tali risorse possono essere montate dai client mediante tre diversi protocolli: CIFS, NFS oppure tramite il client nativo Gluster.

Inoltre GlusterFS supporta la replica geografica ossia la replica dei dati di un Volume su un Server dislocato in un area geografica diversa da quella dove sono presenti gli altri nodi.

Iniziamo a prendere confidenza con alcune terminologie di GlusterFS:

  • Volume: Identifica la condivisione effettiva che viene messa a disposizione
  • Brick: Identifica il file system locale di un server su cui opera GlusterFS
  • Translator: Identifica delle componenti ( librerie ) che estendono le funzionalità del file system
  • Server: Identifica la macchina o le macchine ( reali o virtuali ) dove risiedono i dati
  • Client: Identifica la macchina che monta il volume

La logica quindi è la seguente:

Si installa GlusterFS su ogni server che fa parte del pool di storage del cluster, si definiscono i blocchi ( bricks ) da esportare ( directory ) andando cosi a creare la condivisione effettiva chiamata Volume.

Successivamente su ogni Client interessato installiamo allo stesso modo GlusterFS, e tramite i protocolli citati prima ( NFS, CIFS, GlusterFS Client ) andiamo a montare il cluster rendendo disponibile la condivisione ( Volume ).

Vediamo adesso le diverse TIPOLOGIE DI VOLUME ossia come i dati possono essere organizzati:

  • Distributed: Definisce un {Volume Distribuito} dove i file vengono distribuiti in maniera random tra i vari brick del Volume che compongono il Cluster. Questo comporta maggior scalabilità ma molta meno ridondanza,infatti nel caso in cui ci fosse un Volume cosi configurato, un guasto del Server ( Brick ) comporta la perdita dei dati in esso contenuti.
  • Replicated: Definisce un Volume Replicato dove i file vengono replicati tra i Brick del Volume che compongono il Cluster. Questo comporta una riduzione dello spazio disponibile per lo Storage ma una maggior ridondanza e tale configurazione è consigliabile per avere un Elevata Affidabilità e un Elevata Disponibilità.
    Nel caso in cui ci fosse un Volume cosi configurato, un guasto del Server ( Brick ) NON comporterebbe la perdita dei dati visto che ne abbiamo una replica a disposizione. Le repliche dei dati è consigliabile averle in brick separati cioè che non si trovino sulla stessa macchina.
  • Striped: Definisce un Volume Striped dove i file vengono memorizzati in blocchi nei brick del Volume che compongono il Cluster.
    Questo comporta maggiori prestazioni in lettura e scrittura su file di grandi dimensioni e maggior spazio a disposizione ma una minor ridondanza. Nel caso in cui ci fosse un Volume cosi configurato, un guasto del Server ( Brick ) comporta la perdita dei dati in esso contenuti.
  • Distribuited Striped: Definisce un Volume Distribuito e Striped dove il Volume memorizza i file in blocchi tra 2 o più nodi del Cluster. Nel caso in cui ci fosse un Volume cosi configurato, un guasto del Server ( Brick ) comporta la perdita dei dati in esso contenuti.
  • Distribuited Replicated: Definisce un Volume Distribuito Replicato dove il Volume distribuisce e replica i file tra i Brick del Cluster. Questo comporta la combinazione dei pregi delle singole soluzioni distributedd e Replicated.
    Nel caso in cui ci fosse un Volume cosi configurato, un guasto del Server ( Brick ) NON comporterebbe la perdita dei dati visto che ne abbiamo una replica a disposizione e il Volume resterebbe sempre accessibile.
  • Striped Replicated: Definisce un Volume Striped Replicato dove il Volume fa lo Stripe dei file e li replica tra i Brick del Cluster.
    Si combinano i pregi dello Stripe ossia maggiori prestazioni in lettura e scrittura utile per esempio su file di grandi dimensioni con i pregi della Replicazione sui Brick del Cluster per avere cosi prestazioni e ridondanza.
    Nel caso in cui ci fosse un Volume cosi configurato, un guasto del Server ( Brick ) NON comporta la perdita dei dati in esso contenuti.

INSTALLIAMOLO
Per procedere all’installazione e testare il software dovremo avvalerci di almeno due macchine, decidete voi se reali o VM, dopodiche’ inizieremo dividendo il lavoro; partiamo con la macchina che fara’ da Server :

modifichiamo a dovere il file /etc/hosts, io ho fatto nel seguente modo

# vim /etc/hosts
192.168.2.138    server1.example.com     server1
192.168.2.182    client1.example.com     client1

aptitude install glusterfs-server

…ora dobbiamo creare le seguenti directory

mkdir /data/
mkdir /data/export
mkdir /data/export-ns
cp /etc/glusterfs/glusterd.vol /etc/glusterfs/glusterd.vol_orig
cat /dev/null > /etc/glusterfs/glusterd.vol
vim /etc/glusterfs/glusterd.vol
volume posix
  type storage/posix
  option directory /data/export
end-volume

volume locks
  type features/locks
  option mandatory-locks on
  subvolumes posix
end-volume

volume brick
  type performance/io-threads
  option thread-count 8
  subvolumes locks
end-volume

volume server
  type protocol/server
  option transport-type tcp
  option auth.addr.brick.allow 192.168.2.182 # inserire qui l'indirizzo od il nome host del vostro client
  subvolumes brick
end-volume
/etc/init.d/glusterfs-server start

…ora passiamo a lavorare sul client

aptitude install glusterfs-client glusterfs-server
mkdir /mnt/glusterfs  

cp /etc/glusterfs/glusterd.vol /etc/glusterfs/glusterd.vol_orig
cat /dev/null > /etc/glusterfs/glusterd.vol
vim /etc/glusterfs/glusterd.vol

volume remote
  type protocol/client
  option transport-type tcp
  option remote-host server1.example.com # inserite qui l'indirizzo od il nome host del server
  option remote-subvolume brick
end-volume

volume writebehind
  type performance/write-behind
  option window-size 4MB
  subvolumes remote
end-volume

volume cache
  type performance/io-cache
  option cache-size 512MB
  subvolumes writebehind
end-volume

ora dobbiamo lanciare uno di questi due comandi :

glusterfs -f /etc/glusterfs/glusterd.vol /mnt/glusterfs

oppure

mount -t glusterfs /etc/glusterfs/glusterd.vol /mnt/glusterfs

….se non avete avuto errori eseguendo il comando mount dovreste vedere qualcosa del genere

# mount
/etc/glusterfs/glusterd.vol on /mnt/glusterfs type fuse.glusterfs (rw,default_permissions,allow_other,max_read=131072)

# [client1] df -h
/etc/glusterfs/glusterd.vol
143G   33G  103G  25% /mnt/glusterfs

che nel mio caso equivale alla partizione /home della macchina server
# [server1] df -h
/home/server1/.Private            143G   33G    103G  25% /home/server1/Private

…come notate dalle dimensioni dei due filesystems

a questo punto non ci rimane altro che modificare il file /etc/fstab in modo da rendere immediato il mount al boot del client

# vim /etc/fstab

/etc/glusterfs/glusterfs.vol  /mnt/glusterfs  glusterfs  defaults  0  0

Questo era solo un semplice esercizio per imparare a capire il software in questione ovviamente con le dovute aggiunte e modifiche del caso si potranno creare Volumi e directory ad hoc della grandezza desiderata in cui salvare tutti i dati per noi importanti.

Buon divertimento !