Jump to content
Sign in to follow this  
Redazione Hosting Talk

Cosa sono i database non relazionali (NoSQL)

Recommended Posts

database_icon.thumbnail.jpg

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)

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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 !!

Share this post


Link to post
Share on other sites

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 !!

Share this post


Link to post
Share on other sites
Un pò di cose perchè so di non starvi simpaticissimo ma lavoro da quasi un anno con questi DB:

 

Sì, sei proprio un rompipalle :emoticons_dent2020:

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 :approved:

 

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

Share this post


Link to post
Share on other sites

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 :sisi:

 

Ciao !!

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×