Database  »  Articoli  »  NoSQL 

Con l'avvento del Web 2.0 la rete ha sperimentato per la prima volta le criticità legate alla gestione infrastrutturale di un ambiente che dovesse sostenere ed accentrare le attività tipiche di una community. Indirizzare correttamente tematiche come lo scaling, il tempo di risposta e la gestione di grossissimi volumi di dati è lentamente diventato essenziale per una cerchia sempre più vasta di player web, tra i quali cito Facebook, YouTube, Flickr e molti altri ancora.

Squadre di ingegneri del software sono quindi state assoldate per risolvere questa tematica e tra le tante osservazioni prodotte una delle più importanti è stato il notare che la maggior parte delle più popolari applicazioni web a sfondo social potevano essere sviluppate anche senza un'utilizzo massiccio delle funzionalità relazionali tipiche dei RDBMS. Cominciano così a nascere tutta una serie di prodotti che, rinunciando a concetti come chiavi esterne, joins, database schemas, consentono di memorizzare in modo rapidissimo e distribuito strutture più o meno simili ad Hash {chiave:valore}.

In Facebook, dove già MySql veniva utilizzato in modo poco ortodosso, si decide di optare per una soluzione non relazionale nella tecnica di memorizzazione dei messaggi della Inbox. Nasce così Cassandra che dopo un periodo di gestazione viene resa pubblica su Google Code e successivamente incubata da Apache.

Con questo articolo, diamo il via ad una sorta di "workshop virtuale", proprio per questo nei prossimi paragrafi faremo una breve panoramica dell'architettura.

Principali caratteristiche tecniche

Cassandra è una database distribuito, fault-tolerant, elastico e con consistenza dei dati regolabile sia in read che in write; questo significa che il server è solitamente installato in una configurazione clustered nella quale più nodi di Cassandra cooperano per ottimizzare e distribuire le informazioni.

Nessun nodo è in alcun modo diverso dagli altri, in questo modo non esiste all'interno del cluster una specificità critica che in caso di malfunzionamento possa rendere inoperante il database.

I dati sono automaticamente duplicati su più nodi, questo garantisce che all'eventuale crash di un elemento dell'insieme non debba necessariamente seguitare la perdita di informazioni importanti o lo stallo dell'intera istanza di Cassandra.

Durante le operazioni di read/write, è possibile esplicitare il livello di consistenza che si vuole mantenere: l'impostazione si attua passando alla funzione di lettura/scrittura due parametri che indicano il comportamento atteso; le scelte disponibili variano per le funzioni di write:

• 'esegui tutte le operazioni in asincrono' e conseguentemente non verificare l'effettiva scrittura del dato
• 'scrivi e verifica la scrittura almeno sulla metà + 1 del numero di nodi indicati dalle impostazioni di fault-tolerance'
• 'scrivi e verifica la scrittura su ogni nodo'

Analogamente esistono parametri simili per le funzioni di read che consentono di scegliere da quanti nodi effettuare la lettura prima di determinare quale sia la versione più fresca del dato richiesto.

Aumentando il numero di nodi da leggere, così come aumentando quelli da scrivere per quanto riguarda le funzioni di write, si ottiene un lineare miglioramento nella consistenza del dato a scapito delle performance: è quindi importante decidere con attenzione quale sia il miglior compromesso per la propria applicazione.

Altri articoli

Altre guide

Altre newsletter