Programmazione.it v6.4
Ciao, per farti riconoscere devi fare il login. Non ti sei ancora iscritto? Che aspetti, registrati adesso!
Info Pubblicit� Collabora Autori Sottoscrizioni Preferiti Bozze Scheda personale Privacy Archivio Libri Corsi per principianti Forum
Guida all'uso di OrientDB: introduzione al mondo NoSQL
Scritto da Luca Garulli il 15-12-2010 ore 12:08
Intel WebSeminar
Nell'ultimo periodo abbiamo assistito a un'esplosione di prodotti NoSQL. Sul significato di questa parola si gi detto e scritto tutto: non una campagna contro il linguaggio SQL, ma piuttosto uno spunto di riflessione per aprire le menti degli sviluppatori (e non) a nuove possibilit oltre il database relazionale. Alternative a quest'ultimo ci sono sempre state, ma usate sovente da nicchie di mercato, telecomunicazioni in primis. Oggi, invece, l'interesse per queste nuove possibilit sta aumentando, non a caso molte delle pi grandi web company utilizzano un prodotto NoSQL: tra i tanti ci sono Google, Amazon, Facebook, Foursquare, Twitter, ecc.

Quali sono dunque le motivazioni che spingono queste aziende a lasciare la strada vecchia (il relazionale) per la nuova? Possiamo riassumerle in prestazioni; scalabilit, spesso estrema; leggerezza; produttivit; flessibilit nella gestione degli schema. Da un'analisi pi approfondita si pu notare che queste motivazioni sono, guarda caso, tutti requisiti di ogni web application moderna. Infatti se solo fino a qualche anno fa, di media, chi progettava un'applicazione si preoccupava di soddisfare qualche centinaia di utenti concorrenti, oggi non raro avere un target potenziale di migliaia o milioni di utenti.

Con questi presupposti occorre per forza rimettere tutto in gioco: sul fronte applicativo, abbiamo gi assistito a un progressivo snellimento dei framework, degli standard e di alcune best practices in favore della produttivit e leggerezza; lato database, invece, la situazione rimasta pi o meno invariata per oltre 30 anni. I DBMS relazionali hanno sempre giocato il ruolo di protagonisti dagli anni '70 fino ad oggi, o meglio fino a ieri. I linguaggi si sono evoluti cos come le metodologie, ma il DBMS rimasto sempre quello. Qualcuno ha introdotto piccoli lifting, ma la sostanza sempre la stessa: tabelle, record e join.

Ora ci si accorti che esiste qualcosa di pi performante, produttivo, snello, scalabile e flessibile di un database relazionale, ovvero i DB NoSQL, con moltissime varianti. Per fare un po' di chiarezza sono state identificate quattro macro categorie:
  • Key/Valuedatabase: il modello si riduce a una hash table chiave/valore. Spesso quest'ultima distribuita su pi server (DHT). Chiave e valore sono tipi semplici. In alcuni casi ci sono i bucket intesi come un raggruppamento di chiavi. I prodotti pi famosi sono Dynamo, Cassandra, Berkley DB e Redis;
  • Column-oriented database: un estensione del tipo Key/Value, dove il valore pu essere di tipo complesso. Appartengono a questo tipo BigTable di Google e SimpleDB di Amazon;
  • Document database: un modello pi complesso dei precedenti. Ogni record pu avere pi campi senza per forza definire uno schema. I pi noti e utilizzati document database sono MongoDB e CouchDB;
  • Graphdatabase (GraphDB): modella ogni tipo di dominio, anche complesso, come un grafo, dove ogni entit un Vertex e tutte le relazioni sono Edge. Vertex ed Edge possono avere propriet arbitrarie e in genere sono indicizzate per velocizzare le interrogazioni. Sono GraphDB Neo4J, Sones e InfinityGraph.

Ognuna di queste categorie ha le proprie peculiarit e limitazioni. Non ne esiste una migliore di tutte le altre, ma dipende dal caso d'uso in esame. D'altronde NoSQL significa proprio questo: scegli lo strumento migliore per il tuo caso specifico. In questa serie di articoli prenderemo in considerazione OrientDB, un prodotto NoSQL di nuova generazione, open source, nato e cresciuto in Italia.
Precedente: Migliorare l'aspetto delle applicazioni su iPhone 4.0 (2/2)
Successiva: NoSQL Day, uno scambio di esperienze sui DB NoSQL
Copyright Programmazione.it™ 1999-2016. Alcuni diritti riservati. Testata giornalistica iscritta col n. 569 presso il Tribunale di Milano in data 14/10/2002. Pagina generata in 0.193 secondi.