Sapere cosa sono, come funzionano e vantaggi/svantaggi sicuramente si
Puoi vedere mongo che è documentale, anche Redis che è key-value (e creato da un italiano)
Software Development for Dummies
- Creatore Discussione marc.overmars
- Data di inizio
Puoi vedere mongo che è documentale, anche Redis che è key-value (e creato da un italiano)
Uso mongo dal 2010, redis cassandra e altri db da molti anni.
Ho diverse applicazioni grosse basate su mongo.
Se hai domande, sono qui.
per ampliare la risposta sui db NoSQL alla domanda di @koji82 in modo che sia comprensibile per tutti, ecco alcune spiegazioni.
Probabilmente chiunqie, in modo magari molto vago, sa che in un database i dati sono strutturati in tabelle e campi (righe e colonne).
In realta' non e' cosi'. Si prende per scontato che i db siano fatti cosi' ma questa tipologia di db e' una delle moltissime esistenti, e si chiamano db relazionali. Ne esistevano prima dei db relazionali (vedi db gerarchici) e e ne esistono molte altre tipologie (a oggetti, a grafo, a documenti, a chiave valore, ...)
Una delle caratteristiche fondamentali dei db relazionali (o spesso chiamati db sql, perche' il linguaggio con cui comunichi e' SQL, Structured Query Language) e'a appunto quello di strutturare i dati in modo molto rigido, con campi previsti a priori, tabelle con nomi ben definiti e relazioni tra i campi/tabelle. le relazioni sono delle informazioni che legano varie tabelle tra loro, per evitare duplicazioni di dati. Se ho una informazione su un employee, non ho bisogno di duplicare i suoi dati anagrafici ogni volta che una tabella (stipendio, orari, assenza, ...) ne parla, ma uso una "relazione" verso quel employee.
Tutto cio' e' comodissimo, utilissimo, e gran parte del sw esistente e' basato su db sql. L'esistenza di relazioni permette inoltre di avere dati sempre consistenti (non e' possibile scrivere relazioni errate, cioe' dare un o stipendio a un employee non esistente, non e' possibile cancellare dati relazionati, cioe' non posso cancellare una persona se possiede un conto corrente).
Tuttavia il mondo oggi e' piu' complicato, molte applicazioni richiedono gestione di grandi quantita' di dati, la cui struttura spesso non e' nota a priori e non e' neppure prevedibile a priori. E in questo caso un db sql e' una gabbia in cui e' difficile muoversi.
I db NoSQL, tipo MongoDB, sono orientati alla gestione di collezioni di documenti, totalmente unstructured. Posso fare conto che qualunque campo sia scrivibile, a prescindere dalla struttura della collezione, perche' e' appunto libera, non esiste struttura.
La flessibilita' e' infinita, la comodita' e' elevatissima ma ... manca integrita' referenziale. E' possibile scrivere informazioni totalmente inconsistenti, posso avere uno stipendio che parla di un employee che non esiste.
Quindi sono db estremamente interessanti per moltissime applicazioni ma il loro uso spesso non e' adeguato, che so, in un sistema di accounting, in un sistema bancario, in uno shop, in un sistema di prenotazioni aeree, ... tutti sistemi in cui le relazioni sono core, e la flessibilita' della struttura e' secondaria.
Anche in questo caso, si possono scrivere molti libri, questa e' una descrizione super light dell'argomento, anche perche' i db a documenti (mongo) sono solo una delle categorie NoSQL, ve ne sono molte altre, con pro e contro.
Probabilmente chiunqie, in modo magari molto vago, sa che in un database i dati sono strutturati in tabelle e campi (righe e colonne).
In realta' non e' cosi'. Si prende per scontato che i db siano fatti cosi' ma questa tipologia di db e' una delle moltissime esistenti, e si chiamano db relazionali. Ne esistevano prima dei db relazionali (vedi db gerarchici) e e ne esistono molte altre tipologie (a oggetti, a grafo, a documenti, a chiave valore, ...)
Una delle caratteristiche fondamentali dei db relazionali (o spesso chiamati db sql, perche' il linguaggio con cui comunichi e' SQL, Structured Query Language) e'a appunto quello di strutturare i dati in modo molto rigido, con campi previsti a priori, tabelle con nomi ben definiti e relazioni tra i campi/tabelle. le relazioni sono delle informazioni che legano varie tabelle tra loro, per evitare duplicazioni di dati. Se ho una informazione su un employee, non ho bisogno di duplicare i suoi dati anagrafici ogni volta che una tabella (stipendio, orari, assenza, ...) ne parla, ma uso una "relazione" verso quel employee.
Tutto cio' e' comodissimo, utilissimo, e gran parte del sw esistente e' basato su db sql. L'esistenza di relazioni permette inoltre di avere dati sempre consistenti (non e' possibile scrivere relazioni errate, cioe' dare un o stipendio a un employee non esistente, non e' possibile cancellare dati relazionati, cioe' non posso cancellare una persona se possiede un conto corrente).
Tuttavia il mondo oggi e' piu' complicato, molte applicazioni richiedono gestione di grandi quantita' di dati, la cui struttura spesso non e' nota a priori e non e' neppure prevedibile a priori. E in questo caso un db sql e' una gabbia in cui e' difficile muoversi.
I db NoSQL, tipo MongoDB, sono orientati alla gestione di collezioni di documenti, totalmente unstructured. Posso fare conto che qualunque campo sia scrivibile, a prescindere dalla struttura della collezione, perche' e' appunto libera, non esiste struttura.
La flessibilita' e' infinita, la comodita' e' elevatissima ma ... manca integrita' referenziale. E' possibile scrivere informazioni totalmente inconsistenti, posso avere uno stipendio che parla di un employee che non esiste.
Quindi sono db estremamente interessanti per moltissime applicazioni ma il loro uso spesso non e' adeguato, che so, in un sistema di accounting, in un sistema bancario, in uno shop, in un sistema di prenotazioni aeree, ... tutti sistemi in cui le relazioni sono core, e la flessibilita' della struttura e' secondaria.
Anche in questo caso, si possono scrivere molti libri, questa e' una descrizione super light dell'argomento, anche perche' i db a documenti (mongo) sono solo una delle categorie NoSQL, ve ne sono molte altre, con pro e contro.
Ultima modifica:
grazie della risposta, mi ci devo sicuramente mettere perché in alcuni casi proporre soluzioni che usano questi tipi di database potrebbe essermi utile
usare mongo e' estremamente semplice dal punto di vista tecnico.
quello che e' complicato e' capirne l'uso corretto, la filosofia da applicare
se arrivi dal mondo sql, sarai portato a pensare in logica di tabelle e relazioni, e ci sbatterai la faccia
la filosofia di uso e' completamente diversa e all'inizio sconfortante per chi si aspetta relazioni
fai conto che per esempio le transazioni non esistevano fino a poco fa, sono state introdotte 10 anni dopo la nascita di mongo (tipo nella versione 5 .....), perche' fare operazioni cross "tabelle" non ha molto senso. e se scopri che lo devi fare spesso, allora non dovevi usare mongo.
faccio un pò fatica a comprendere i casi d'uso della classe NoSQL
esiste un db schema? come fare joins se (mi par di capire) non esistono key-value pairs? Forse faccio fatica perchè per me db = queries per estrarre, manipolare un pò e poi importare il dataset risultante in altro linguaggio/sistema per analisi vera e propria, STOP. Sono del fronte SELECT diciamo, magari per chi fa uso diverso del db il caso d'uso è chiarissimo. Esempi?
esiste un db schema? no. si chiama no sql per quello
non esistono key-value pairs? no (o meglio non in mongo)
in mongo esiste il concetto di "collection" (paragonalo alla tabella come altezza nello stack)
ogni collection contiene documenti ... e fine, non esistono altri livelli
i documenti sono composti da:
- un id, autogenerato, una sorta di UUID
- il conteunoto del documento, che null'altro e' che una struttura json (in realta' bjson, un json che puo' ospitare roba binary)
nel documento ci scrivi cio' che vuoi, come in un oggetto json/javascript
ma in piu' fai ricerche (su campi, sottocampi, ...) aggregazioni, modifiche togli/metit campi, ...
se vuoi fare "relazioni" tra collections, esiste un tipo particolare di field json dove di fatto metti l'id sdi un altro documento, ma la relazione non e' neppure lontanamente enforced, puoi cancellare il documento referenziato senza alcun limite, e non deve manco esistere il documento referenziato quando popoli quella che in sql chiameresti foreign key
Ultima modifica:
facciamo un caso d'uso che mi invento ora
cerco di semplificare/banalizzare, altrimenti ci si perde dietro i dettagli
supponiamo tu voglia scrivere una agenda online
se tu usassi mysql per esempiop, creeresti una tabella "contatti" con i campi "nome", "email", "telefono"
se domani vuoi aggiungere lo stato dovresti modificare la struttura del mysql, e poi modificare l'applicazione per gestire il campo stato
se tu usassi invece mongo, non creeresti nulla, manco la collection "contatti"
semplicemente la useresti
e se devi aggiungere il campo stato, modifichi la applicazione, lo scrivi, lo usi, come esistesse
in mysql la tabella sarebbe
Codice:
= id = nome = email = telefono =
------------------------------------------------
= 1 = marc = marc@juvemerda = 30000 sul campo =in mongo sarebbe
Codice:
{
_id: ObjectId("123456789"),
nome: "marc",
email: "marc@juvemerda",
telefono: "30000 sul campo"
}la struttura del doc mongo puo' essere complessa a piacimento, array dentro oggetti, dentro array, ... e su quella struttura puoi fare query complesse in modo semplice, roba che in SQL ti uccidi
p.s. ho banalizzato in modo vergognoso l'importanza e i casi d'uso dei db nosql, me ne vergogno, ma non si puo' fare altrimenti per iniziare
Ultima modifica: