[Linuxtrent] Re: Key-value data stores or NoSQL databases
- From: Mario Alexandro Santini <alexmario74@xxxxxxxxx>
- To: linuxtrent@xxxxxxxxxxxxx
- Date: Thu, 21 Sep 2017 09:58:00 +0200
2017-09-20 18:39 GMT+02:00 Daniele Nicolodi <daniele@xxxxxxxxxx>:
Ciao,
Ciao Daniele,
per diverse ragioni mi sto esplorando un poco il mondo dei database
NoSQL o key-value data stores. In particolare ho cominciato a
giochicchiare con Redis, che sembra essere la soluzione più matura e
popolare.
Il mondo dei nosql è vario e ci sono diverse soluzioni.
In sostanza esistono delle "famiglie" di db nosql con caratteristiche
differenti.
Se vogliamo accomunarli assegnando un'altra caratteristica, per esempio in
contrapposizione con gli RDBMS, sono cosiddetti schemaless, anche se alcuni
sono piuttosto complicati da progettare bene.
Redis e Cassandra appartengono alla famiglia dei key value. Ovvero dei db
che consentono di memorizzare dati in base a una chiave.
Redis è molto usato per i siti web come cache della sessione utente.
In pratica l'id di sessione è la chiave che permette di caricare tutti i
dati di un utente collegato al sito.
Questo permette al sito di scalare in maniera orizzontale molto
velocemente, avendo la persistenza su Redis.
Redis mantiene tutti i dati in RAM e questo gli consente di essere molto
molto veloce, ma ha anche la possibilità di salvarli su disco in modo
trasparente all'utilizzo e senza intaccare le performance.
Puoi senz'altro fare la stessa cosa con PostgreSQL, quello che non puoi
fare e scalare PostgreSQL con la stessa rapidità con cui scali Redis.
Inoltre, per il dominio specifico Redis è più semplice da utilizzare
rispetto ad un RDBMS.
Altri nosql come HBase sono detti colonnari e sono molto difficili da
progettare, perché la struttura dei dati influenza le prestazioni in
scalabilità del db.
Di contro, HBase non ha rivali in prestazioni sui big data e parlo di big
data, non di qualche decina di milioni di record o anche qualche centinaio,
parlo di dati che vanno almeno 1 ordine di grandezza sopra.
I nosql, non avendo le transazioni hanno la possibilità di creare cluster e
scalare in maniera più semplice e rapida di RDBMS.
Anche con gli RDBMS puoi rispondere a carichi elevati o elevatissimi e
scalare un po', ma non con la flessibilità dei nosql.
Il che li rende economicamente molto più vantaggiosi se hai il tuo sistema
eseguito in cloud dove paghi per l'utilizzo.
Poi ci sono i db document oriented come MongoDB, che io utilizzo al lavoro.
Questi sono basati su collezioni di documenti e sono molto utili se la tua
applicazione richiede di salvare dati con dimensioni variabili e se non hai
bisogno di relazioni fra dati e di transionalità puoi scrivere una
applicazione molto più semplice se utilizzo MongoDB.
I dati sono salvati in JSON (in caso di MongoDB una forma binaria) e
possono essere serializzati e deserializzati moto facilmente a livello
applicativo.
Certo se hai bisogno di transazioni o di mettere in relazione i dati per
fare report o di entrambe le cose i nosql non fanno al caso tuo.
Ad un primo sguardo, sono piacevolmente stupito da quanto sia facile da
usare, ma ad un analisi più approfondita non riesco a capire quale
vantaggi presenti rispetto ad un tradizionale database relazionale. Per
quello che ho visto fino ad adesso, mi sembra una database relazionale
per qualcuno che non ha capito come si usano i database relazionali, o
che ha avuto a che fare solo con MySQL o altri database zoppi.
Mi sa che non hai capito bene.
I nosql NON sono db relazionali e non intendono esserlo.
Il nome NOSQL è fourviante, è usato solo perché definisce tutto quello che
non è basato su SQL, intendendo per SQL i database relazionali.
E' un mondo molto vario e diversificato.
Ogni db che ti ho citato sopra è ottimizzato per un certo tipo di caso
d'uso e in quella nicchia funziona molto meglio dei RDBMS.
Anche le applicazioni che scrivi sono molto più semplici.
La prima perplessità viene dal fatto che, non è esattamente vero che si
possono memorizzare dati di tipo non uniforme, ma è più corretto dire
che si possono memorizzare solo stringhe binarie e che un sistema di
marshalling deve essere utilizzato per memorizzare qualsiasi altra cosa.
Quindi non capisco che differenza ci sia tra Redis e (per esempio) una
tabella PostgreSQL '(key text primary key, value bytea)'.
la transazionalità e le relazioni fra i dati. :)
Occorre quindi abbinare a Redis (ma da quanto ho visto tutti i
contendenti funzionano allo stesso modo) un sistema di marshalling: ce
ne sono a bizzeffe. Dopo una breve ricerca ho scelto MessagePack,
soprattutto perché ha una ovvia scelta per il supporto per Python e
questa non sembra una schifezza (lo stesso non si può dire per altre
librerie simili).
Credo mi stia sfuggendo il nocciolo del problema. Commenti?
Ciao,
Daniele
--
Non si tratta di sostituti degli RDBMS, ma di strumenti per gestire la
persistenza specializzati rispetto ai tradizionali db.
Hanno scope di utilizzo limitato perché i dati che contengono sono spesso
funzionali ad un unica applicazione a differenza dei db ai quali eravamo
abituati.
Ma l'architettura moderna di sistemi complessi che includono molte
applicazioni differenti, in genere vede sempre un data warehouse RDBMS che
contiene il dato modellato dal quale arrivano fussi in scruttura o lettura
che sono cachati su db nosql ognuno utilizzato da una diversa applicazione.
La chicca, ho pure scoperto che alcune applicazioni utilizzano addirittura
il sistema di messaging come db.
Spero di averti illustrato un po' il mondo nosql.
--
Mario
Other related posts: