Scegliere un RDBMS oppure un NoSQL, ovvero il teorema CAP parte seconda

Nel post precedente, abbiamo visto come un sistema distribuito non possa essere allo stesso tempo consistente, disponibile e partition tolerant.

Questo significa che qualsiasi scelta di hosting tu faccia, se la tua applicazione web utilizza una base dati, sarai sempre costretto a scegliere tra consistenza e disponibilità, oppure tra disponibilità e partition tolerancy oppure tra consistenza e partition tolerancy.

In pratica, dovrai fare dei compromessi su come la tua applicazione utilizza i database e su come questa risponde ad eventuali problematiche lato infrastruttura di erogazione.

Hai capito bene… il livello di resilienza applicativa non lo sceglie il provider, ma lo scegli tu (anche) nel momento in cui decidi come interfacciare la tua applicazione ad un database.

Quindi, che alternative hai?

Se decidi di puntare su Availability e Consistenza del dato, cadrai su di un RDBMS tradizionale, che poi potrebbe non essere MySQL. Ad esempio potresti scegliere SQL Server di Microsoft, oppure PostgreSql oppure Oracle.

Ciascuno di questi prodotti ha i suoi pro ed i suoi contro, ma di buono hanno tutti di essere basati sul linguaggio SQL, percui è relativamente facile trovare qualcuno che li sappia sfruttare al meglio sia al livello di sviluppo che lato sistemistico.

Se invece decidi di sacrificare la consistenza in nome della partition tolerancy potrai scegliere dei sistemi come Riak, SimbleDB oppure Cassandra.

Cassandra, in modo particolare, è mantenuto dall’apache foundation, ha la capacità di scalare molto bene e ti permette di gestire dataset molto grandi. Personalmente ho visto un paio di installazioni cassandra sui cloud che ho dedicato ad alcuni clienti, mi sembra un prodotto molto interessante.

Non che gli altri prodotti siano necessariamente meno buoni, ma non ho ancora avuto modo di testare ne Riak ne SimpleDB su basi dati molto larghe, quindi ne parlerò quando avrò qualche dato in mano.

Infine, se decidi di puntare su consistenza e partition tolerancy sacrificando l’availability, allora userai probabilmente MongoDB oppure Redis.

Redis è un prodotto maturo, molto noto e soprattutto lanciato dall’italianissimo Antirez, che è anche colui che va ringraziato se in italia esiste OkNotizie, l’aggregatore che probabilmente avete usato per raggiungere questo blog.

Sei ancora indeciso tra RDBMS e NoSQL? Ti dico la mia: NoSQL is the way forward.

Innanzitutto perchè la dimensioni delle basi dati sta crescendo più velocemente della capacità delle piattaforme di accoglierli. Quindi molto spesso i sistemi database necessitano di essere distribuiti.

In secondo luogo per un problema legato alle performance. Oggi, infatti, i database sono spesso legati ad applicazioni web, questo significa che i tempi di risposta contano. A meno che non abbiate *davvero* bisogno del SQL, i sistemi NoSQL consentono ottime performance in cambio di un po di eleganza in meno.

Infine, le applicazioni moderne hanno un volume di ‘scritture a disco’ a volte molto importante. Provate ad immaginare, ad esempio, sistemi dedicati all’advertising pay-per-click, oppure dedicati al performance monitoring.

Non è strano che in questi sistemi ‘ad elevato carico di scrittura’ i dati vengano raccolti con stream di write su dei NoSQL (performanti) e poi gli stream vengano tradotti in SQL attraverso batch notturni (più lenti) per essere poi analizzati con più calma e sfruttando la potenza del SQL laddove serve per davvero.

Per oggi è tutto. Se ti piace quello che scrivo e vuoi entrare in contatto con me, oppure se hai bisogno di un partner competente per le tue esigenze di hosting dedicato, non esitare a contattarmi attraverso questo form.

Stay tuned.