[Linuxtrent] Re: Key-value data stores or NoSQL databases
- From: Mario Alexandro Santini <alexmario74@xxxxxxxxx>
- To: linuxtrent@xxxxxxxxxxxxx
- Date: Fri, 22 Sep 2017 08:37:18 +0200
2017-09-22 7:42 GMT+02:00 Daniele Nicolodi <daniele@xxxxxxxxxx>:
Mario, grazie per l'introduzione. Un paio di commenti.
Figurati, provo a rispondere.
Non ho mai avuto a che fare con dataset così grandi da dover scalare
database su più server quindi magari dico una fesseria, ma si può fare
sharding semplicemente con PostgreSQL (perfino con MySQL). Se non mi
servono transazioni non capisco dove sia il problema a scalare
PostgreSQL orizzontalmente.
Il problema dei RDBMS nello scalare orizontalmente è legato alla
consistenza dei dati, che ha impatti sulle performance.
I nosql non hanno vincoli di consistenza e quindi i cluster possono
crescere senza troppi problemi.
Insomma è la famosa scelta fra consistenza del dato o accessibilità.
I nosql puntano sull'accessibilità lasciando indietro la consistenza, il
che aiuta chi ha questo tipo di esigenza e non considera molto importante
la consistenza dei dati.
Gli RDBMS, al contrario, garantiscono la consistenza del dato, ma a scapito
dell'accessibilità.
Parlo di accessibilità in termini di prestazioni, inoltre sto parlando di
situazione limite.
Il vantaggio di scalabilità orizzontale dei nosql sta nella rapidità e
possibilità di creare cluster che crescono e calano in numero di server
molto rapidamente. Una caratteristica che aiuta a limitare i costi nel
cloud, oltre a dare una risposta a chi ha un problema di picchi enormi di
traffico.
Questa credo sia la cosa che mi "infastidisce" di più :-)
Perché ti infastidisce?
Quello che trovo elegante dei database relazionali è la sintesi di un
sistema capace di descrivere elegantemente dati, relazioni tra dati, ed
un linguaggio per esplorare tali relazioni. Date queste primitive posso
modellare qualsiasi cosa.
Io, invece, mi sono trovato in casi in cui sono stato costretto a lavorare
con db relazionali dove mappare dei dati che erano in realtà dei grafi.
Quando scrivi le applicazioni ti accorgi dei problemi.
Al tempo esistevano già i graph db o gli object db (sempre della famiglia
dei nosql), ma le prestazioni e l'impiego delle risorse erano proibitivi
per i nostri numeri.
Così abbiamo utilizzato RDBMS.
Ho anche lavorato in progetti dove un relazionale funzionava molto bene.
Quello che intendo dire è che il db relazionale risolve egregiamente un bel
numero di problemi, ma non risolve tutti i problemi. Per i casi
particolari, hanno preso piede questi db nosql che tentano di dare delle
risposte a esigenze che gli RDBMS non coprono.
Per questo non capisco le tue perplessita: i nosql non sono sostituti dei
relazionali, ma alternativi.
Certo, in giro si trova gente, che per moda, sceglie MongoDB, salvo poi
trovarsi a implementare le join e complicare a dismisura l'applicativo per
gestire le "transazioni".
Se la scelta di un tipo di db è sbagliata, te ne accorgi nel codice
applicativo.
Lo so, per quanto scrivevo prima dell'uso di un relazionale per un problema
che non era coperto bene.
Nel mondo dei database NoSQL ho l'impressione che un processo che porti
a definire quali siano le primitive comuni a tutte le applicazioni
ancora non sia stato fatto. Quindi per ogni famiglia di applicazioni
serve riprogettare lo strumento perché le astrazioni fornite non sono
più quelle giuste.
Non sono d'accordo su questo aspetto.
I nosql danno risposte a problemi diversi, come ho già scritto.
Progettare il modello dati ha lo stesso tipo di problematica che ti ritrovi
con i db relazionali.
Il fatto che non sei vincolato ad uno schema, ti permette di avere
flessibilità che poi gestisci a livello applicativo.
Inolte, anche non avendo uno schema, devi comunque organizzare le
informazioni in maniera coerente.
Ad esempio in MondoDB ogni collezione di documenti deve comprendere
documenti che possibilmente siano autoreferenziali.
Se ti accorgi che hai bisogno di "unire" i documenti di 2 collezioni è
probabile che le due collezioni vadano messe in un unica collezione.
Si tratta di un modo diverso di ragionare rispetto al relazionale dove
progetti tabelle e relazioni.
Poi ci sono i big data, ovvero quelle situazioni dove gestisci moli di dati
enormi che crescono rapidamente.
Sono casi che alcuni possono avere, ma non sono casi comuni quanto si sente
in giro. :)
Nel caso dei big data, il modello è molto molto complicato da progettare. E
ogni errore lo paghi a carissimo prezzo perché quando hai tanti dati come
quelli che configurano un big data, non hai il lusso della migrazione.
Se dimentichi un campo, per introdurlo devi ricostruire l'intero recordset
perdento tutto il passato.
Ma non sono casi che hanno in molti.
Noi gestiamo più di 20 milioni di messaggi al giorno in stream con tutti
gli annessi e connessi e non siamo per nulla big.
Con una tabella sola non puoi esprimere relazioni tra dati. Ma ho capito
che ancora ho una visione semplicistica dei database NoSQL.
Ciao,
Daniele
--
Ma se il tuo dato può essere espresso in maniera ottimale in una tabella
sola, allora non hai bisogno di un relazionale. :)
Da 3-4 anni utiliziamo MongoDB e nel nostro caso funziona bene sia come
prestazioni sia come modellazione del dato.
Se dovessi tornare a rifare alcuni progetti del passato, non lo
utilizzerei, perché li i modelli erano differenti e avevamo dei dati con
relazioni e poi c'era bisogno di transazioni e soprattutto di consistenza.
La cosa più importante era la consistenza dei dati.
Secondo me, dovresti abbandonare la visione di confronto fra i 2 mondi
RDBMS e NoSQL e cominciare a vederli come strumenti che risolvono problemi
differenti e cercare di capire quale strumento risolve meglio il tuo
problema.
--
Mario
Other related posts: