Cosa sono i database non relazionali (NoSQL)

[Redazione HostingTalk]

I database non relazionali, pur non essendo una novità assoluta, hanno registrato una crescita esponenziale nel loro sviluppo e utilizzo negli ultimi mesi grazie al sempre più crescente bisogno di scalare in orizzontale, dove i classici RDBMS (database relazionali) presentano diverse limitazioni. Pensate infatti ai sempre più in voga sistemi cloud dove i nodi possono diventare veramente molti, gestire un RDBMS in un ambiente del genere risulta complicato e la potenza computazionale non viene sfruttata in modo ottimale (pensate per esempio alla replicazione con MySQL dove il log binario costituisce già di per sé un enorme calo prestazionale).



Leggi il contenuto dell'articolo Cosa sono i database non relazionali (NoSQL)

[GrG]

Un pò di cose perchè so di non starvi simpaticissimo ma lavoro da quasi un anno con questi DB:

La semplicità di questi database, però, porta anche alla mancanza dei controlli fondamentali sull’integrità dei dati, il compito ricade quindi totalmente sull’applicativo che dialoga col database che ovviamente dovrebbe essere testato in modo molto approfondito prima di essere messo in produzione. Per fare un esempio, se avessimo un database dei clienti coi relativi ordini effettuati immagazzinati in elementi diversi, anche se è possibile definire una relazione attraverso le chiavi, in un database non relazionale alla cancellazione di un cliente tutti gli ordini resterebbero comunque nel database, è quindi l’applicativo che una volta impartito il comando di cancellazione dell’utente X deve anche andare a cancellare tutti i relativi ordini, cosa che invece in un database relazionale è gestita direttamente dal database stesso.

Vabbè si ok è verissimo ma è un pò come dire che con i relazionali devi controllare che le query siano corrette prima di lanciarle.

Cioè non lo vedo come uno svantaggio, è un modo diverso di lavorare (che poi, oddio, che cambiano sono i modelli, fare un JOIN via applicativo è un attimo).

La mancanza di uno standard universale (come può essere l’SQL) è un’altra delle pecche di questi database non relazionali, ogni database ha infatti le proprie API e il suo metodo di storing e di accesso ai dati. Detto questo, risulta palese che se lo sviluppo del database sul quale abbiamo basato il nostro applicativo venisse interrotto, il passaggio ad un altro database non sarebbe sicuramente una cosa immediata, ma richiederebbe alcuni cambi più o meno radicali da apportare all’applicativo, è quindi bene tenere in considerazione la cosa al momento del brainstorming iniziale.

Questo è vero, ma lo stesso è per MySQL e PostreSQL quando si usano query abbastanza fuori dai loro standard. L'applicativo va riscritto. La soluzione? Astrazione.

Eh ok ma allora la stessa soluzione è applicabile ai non relazionali no?

App Engine Data Store di Google è un’interfaccia semplificata che lavora su Big Table. Come pro troviamo sicuramente la robustezza di questo database, ma il grosso svantaggio è che, a differenza di SimpleDB, non è possibile usarlo da applicazioni che risiedono al di fuori di App Engine.

Anche questo è relativamente scorretto, perchè, molto più semplicemente Amazon ti da una API, Google no ma ti da gli strumenti per creartela.

Cioè è ovvio che se devi usare questo tipo di db per salvarti la rubrica non ha senso farti la api, ma se devi usarlo per quei 2/3 milioni di query al secondo allora un giorno di sviluppo in più o in meno non conta.

In più da diversi test Google è risultato un pezzo avanti come performances, latenza esclusa si intende.

---

Chi è che ha scritto l'articolo che non è firmato?

[Stefano Bellasio]

L'ha scritto Andrea, Giorgio, è scritto come Autore in alto Ottimi spunti comunque, se Andrea vuole può modificare l'articolo eventualmente o rispondere qui direttamente

[ceccus]

Salve,
Da dire, anche, relativamente ai RDBMS che sia Oracle , con la sua tecnologia RAC che IBM con DB2 LUW "pure scale" , stanno cercando di rendere scalabile orizzontalmente il loro DB di riferimento ...
Noi abbiamo installazioni di Oracle a 3, 5, (e mi sembra anche a 7, ma dovrei verificare) nodi, e devo dire che funzionano.
La tecnologia "pure scale" è di prossima uscita ... e sarà testata sicuramente in azienda ...
Quindi, direi, che c'è sicuramente fermento anche lato "relazionale" ...

Ciao !!

[GrG]

Ceccus per curiosità ognuno di quei 7 nodi è grande come camera mia?

[ceccus]

Salve,
Sono macchine in tecnologia X86 Intel ... 16 Core (le nuove verranno acquistate a 4 socket , 8 core per socket) con 32/64 GB di RAM a bordo ... S.O. Linux RHEL 5.x

Ciao !!

[usu]

Un pò di cose perchè so di non starvi simpaticissimo ma lavoro da quasi un anno con questi DB:

Sì, sei proprio un rompipalle
Ovviamente scherzo, ci mancherebbe

Vabbè si ok è verissimo ma è un pò come dire che con i relazionali devi controllare che le query siano corrette prima di lanciarle.

Cioè non lo vedo come uno svantaggio, è un modo diverso di lavorare (che poi, oddio, che cambiano sono i modelli, fare un JOIN via applicativo è un attimo).

Beh sì, non è propriamente uno svantaggio una volta che si è entrati nella logica di questi sistemi, ma una persona non abituata a ragionare in questi termini secondo me deve considerare come uno svantaggio questa peculiarità al momento della decisione dell'eventuale passaggio.

Questo è vero, ma lo stesso è per MySQL e PostreSQL quando si usano query abbastanza fuori dai loro standard. L'applicativo va riscritto. La soluzione? Astrazione.

Eh ok ma allora la stessa soluzione è applicabile ai non relazionali no?

Vero, volevo spiegare meglio il concetto con un esempio, ma in effetti è uscito male ^^'

Anche questo è relativamente scorretto, perchè, molto più semplicemente Amazon ti da una API, Google no ma ti da gli strumenti per creartela.

Cioè è ovvio che se devi usare questo tipo di db per salvarti la rubrica non ha senso farti la api, ma se devi usarlo per quei 2/3 milioni di query al secondo allora un giorno di sviluppo in più o in meno non conta.

Domani aggiungo giustamente all'articolo questa precisazione e dò una sistemata al resto per completezza, grazie mille

@Ceccus: non conoscevo i dettagli dello sviluppo della nuova soluzione Oracle, ma già col semplice MySQL facebook ha migliaia di nodi in produzione

[ceccus]

Salve,
La soluzione RAC di Oracle non è proprio nuovissima ... sono quasi 10 anni che esiste ... ovviamente , nel tempo è stata cambiata ... in meglio ...
Non mi risulta che MySQL , in versione Enterprise, possa vantare simile tecnologia ... anche se , è possibile, come dicevi te, farlo lavorare con carichi piuttosto pesanti ... daltronde, se ti "perdi", per un motivo o per un altro, un "profilo facebook" ... credo sia poco male ... se ti perdi , per esempio, una transazione bancaria ... beh ..................
La tecnologia IBM, invece, è relativamente giovane nel senso che è diverso tempo che i laboratori IBM la stanno provando, ma solo ora sembra pronta per il grande "salto" ... vedremo come và ... e se mantiene ciò che promette

Ciao !!