MongoDB - UniNa STiDuEunina.stidue.net/Basi di Dati 2/Materiale/tesina mongo db.pdfla descrizione...

MongoDB

Poccia Silvestro, Trevisani Luca

11 gennaio 2011

Abstract

Nel presente documento si presenta MongoDB, una relativamente nuova tecno-logia per l’implementazione di un DBMS document-oriented.

Il testo nasce dalla curiosita di approfondire un approccio completamentesenza schemi, molto lontano dalle classiche implementazioni relazionali chenegli anni ci hanno rassicurato con le loro ben definite strutture ma allo stes-so tempo imbrigliato in logiche rigide, difficilmente alterabili dopo la fase diprogetto.

Il nostro documento si articola in tre capitoli fondamentali:

1. Panorama Tecnologico. In questo capitolo si analizza a volo d’uccello il pa-norama odierno in merito alle tecnologie impiegate per la realizzazione deiDBMS moderni. In particolare si elencano e discutono le caratteristichepeculiari degli approcci relazionali ed ad oggetti.

2. MongoDB. In questo capitolo si presenta il modello document-orientedrelativo al MongoDB, per poi introdurre ulteriori scelte architetturali efunzionalita proprie del MongoDB.

3. MongoDB HowTo. In questo capitolo si presentano le principali operazio-ni effettuabili sul DBMS attraverso le interfacce messe a disposizione daMongoDB, con un approccio pratico, a supporto di un eventuale utilizzodel sistema da parte di un nuovo utente.

4. Conclusioni. Nel capitolo conclusivo si tirano le somme di un eventualeimpiego di MongoDB in un sistema reale.

Ad integrare il testo due appendici illustrano sinteticamente l’impiego dellasintassi JSON per interagire con il sistema e le principali differenze e similitudinicon il linguaggio SQL ed il database relazionale MySQL.

Indice

Elenco delle figure iii

Elenco delle tabelle v

1 Panorama Tecnologico 11.1 RDBMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 ODBMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 OODBMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.4 ORDBMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 MongoDB 92.1 Document-oriented storage . . . . . . . . . . . . . . . . . . . . . 92.2 Supporto completo Indici . . . . . . . . . . . . . . . . . . . . . . 112.3 Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.4 Auto-Sharding . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.5 Querying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3 MongoDB HowTo 153.1 Installazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.1.1 Utilizzo avanzato del demone mongod . . . . . . . . . . . 163.2 Gestione Database . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2.1 Selezione del database . . . . . . . . . . . . . . . . . . . . 183.2.2 Creazione del database . . . . . . . . . . . . . . . . . . . . 183.2.3 Eliminazione del database . . . . . . . . . . . . . . . . . . 18

3.3 Gestione Utenti . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.3.1 Creazione Utente . . . . . . . . . . . . . . . . . . . . . . . 203.3.2 Modifica Utente . . . . . . . . . . . . . . . . . . . . . . . 203.3.3 Eliminazione Utente . . . . . . . . . . . . . . . . . . . . . 203.3.4 Autenticazione Utente . . . . . . . . . . . . . . . . . . . . 21

3.4 Gestione Collezioni . . . . . . . . . . . . . . . . . . . . . . . . . . 243.4.1 Creazione Collezione . . . . . . . . . . . . . . . . . . . . . 253.4.2 Creazione Oggetto . . . . . . . . . . . . . . . . . . . . . . 253.4.3 Modifica Oggetto . . . . . . . . . . . . . . . . . . . . . . . 263.4.4 Eliminazione Oggetto . . . . . . . . . . . . . . . . . . . . 283.4.5 Eliminazione Collezione . . . . . . . . . . . . . . . . . . . 29

4 Conclusioni 31

i

ii INDICE

5 Appendice 335.A Sintassi JSON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335.B Migrare da SQL a MongoDB . . . . . . . . . . . . . . . . . . . . 35

Bibliografia 37

Elenco delle figure

1.1 Tecnologie OODBMS . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.1 Avvio demone mongod . . . . . . . . . . . . . . . . . . . . . . . . 153.2 Avvio della shell mongo . . . . . . . . . . . . . . . . . . . . . . . 16

iii

Elenco delle tabelle

3.1 Tabella delle opzioni di modifica . . . . . . . . . . . . . . . . . . 27

5.1 Tabella tecnica SQL MongoDB . . . . . . . . . . . . . . . . . . . 355.2 Tabella comparativa SQL-MongoDB . . . . . . . . . . . . . . . . 36

v

Capitolo 1

Panorama Tecnologico

Di necessita virtu e forse l’espressione che meglio riassume i contenuti diquesta introduzione, perche si trattera l’evoluzione dei DBMS - Database Ma-nagement System - dagli RDBMS - Relational DBMS - agli ODBMS - ObjectDBMS. Cosa hanno in comune? Perche sono nati?In sostanza alla base di un’evoluzione c’e sempre una necessita.

Grazie allo sviluppo di internet, i database oggi sono usati piu che mai permemorizzare ed accedere alle informazioni in contesti sempre piu dinamici e conuna forte esigenza di interoperabilita tra sistemi, devono quindi:

� permettere alle applicazioni di mutare ed evolvere velocemente.

� consentire alle applicazioni di essere conformi ai nuovi standard de factoo de iure.

� garantire in ogni caso i capisaldi delle proprieta ACID.

Questo ha dato una forte spinta allo sviluppo di tecnologie per i database.Il panorama odierno e dominato da tre classi principali e le zone grigie che ledividono:

� Relazionale

� Object-Oriented

� Object-Relational

In questa introduzione ci occuperemo di discutere questi tre modelli eviden-ziandone i punti di forza ed i loro talloni d’Achille. Nel capitolo successivo sitrattera un ulteriore modello: il Document-Oriented dbms, che esalta le neces-sita di performance e polimorfismo delle applicazioni di nuova generazione, dovel’utente - non piu strettamente vincolato dal sistema - riveste un ruolo centralenella creazione e gestione dei dati (tipico nel paradigma del web 2.0) e forniscesupporto alle problematiche attuali di labeling delle risorse (fondamentale peril web 3.0 in arrivo).

1

2 CAPITOLO 1. PANORAMA TECNOLOGICO

1.1 RDBMS

Si deve ad Edgar F. Codd negli oramai lontani anni 70 la nascita dei databa-se relazionali ; il primo prototipo fu sviluppato da IBM in collaborazione conl’Universita di Berkley; vari vendors poterono cosı offrire database relaziona-li, costruendo la rete di database relazionali che gia si prestavano al supporto diapplicativi complessi e per i quali era richiesta una certa affidabilita e consistenzadei dati, come quelli di ambito finanziario.

Un database e un archivio strutturato in modo tale da consentire l’accessoe la gestione dei dati stessi (l’inserimento, la ricerca, la cancellazione ed il loroaggiornamento) da parte di particolari applicazioni software ad essi dedicate.

Il database e un insieme di informazioni, di dati che vengono suddivisi perargomenti in ordine logico (tabelle) e poi tali argomenti vengono suddivisi percategorie (campi). Le tabelle, in un RDBMS, sono collegate fra loro da relazioni.

L’uso della teoria degli insiemi consente di strutturare i dati in serie di tabellecomposte da colonne (domini).

� ogni colonna corrisponde a un attributo di quella relazione

� ogni riga corrisponde a un record che contiene i dati valorizzati per unentita (tupla).

Gli RDBMS si basano sui 3 elementi cardini - secondo Ted Codd - perun sistema relazionale: il concetto di relazionale, l’integrita e la normalizzazio-ne. Inoltre e previsto uno standard per l’interrogazione della base dati: SQL -Standard Query Language.

Lo sviluppo rapidissimo del database relazionale e strettamente legato alleapplicazioni per le quali tale modello ha fatto da padrone ovvero quelle finan-ziarie–bancarie, dove i tipi di dato semplici ed una forte strutturazione delletabelle in binari vincolanti ben si sposavano con le caratteristiche del modello.

Nelle applicazioni d’oggi questa eccessiva rigidita che negli albori del modellorappresentava una caratteristica rassicurante e diventato - in taluni casi - unpesante fardello, se non un vero e proprio limite: pensiamo ad un blog, ci bastagestire dati semplici?

� stringhe

� numeri

� valori booleani

� date

Caratteristica dei blog e che l’utente al centro del processo creativo: mostra sestesso e la propria personalita.

Come e possibile fornire in un db relazionale la flessibilita a ciascuna personaper creare contenuti completamente diversi da post a post, siano essi semplici ocomplessi, piu o meno articolati?

Certo un database relazionale ha molti vantaggi:

� il sistema e semplice, flessibile e produttivo, poiche le tabelle sono semplici,i dati sono semplici per cui facili da capire e da comunicare con gli altri.

� l’SQL e un linguaggio facile da imparare e soprattutto e uno standard.

1.2. ODBMS 3

I database relazionali hanno pero dei limiti, come gia affermato, gestisconosolo dati semplici per cui si prestano male alla gestire dati complessi, strutturatial di fuori degli schemi o con un alto tasso evolutivo. Ma questo non basta, unaltro limite dei database relazionali e l’inadeguatezza ad operare con linguaggial di fuori di SQL.

Dopo lo sviluppo iniziale degli RDBMS, sono nate applicazioni - scritte mag-giormente in c++ e javascript - basate su RDBMS, per le quali era comunquenecessario passare per SQL per ottenere i dati e poi trasportarli all’interno deglioggetti dell’applicativo.

Questo mismatch lascia un pesante gap tra linguaggio applicativo ed ilDBMS relazionale, per cui i database relazionali non funzionano in modo ef-ficiente con questi linguaggi, questo e accettato per aumentare l’astrazione(portabilita).

Altro limite e l’esigenza che le informazioni debbano essere in tabelle in cuile relazioni tra entita siano realizzate usando dei valori (vincoli di integritareferenziali, che introducono una complessita strutturale maggiore).

Oggi, il modello relazionale e il modello delle basi di dati dominante cosı comela base per i prodotti di punta DBMS.

1.2 ODBMS

Sebbene gli RDBMS siano ormai insostituibili nell’ambito delle applicazionifinanziarie, in altri ambiti si sono sviluppati dei modelli piu flessibili capaci digestire dati complessi: gli ODBMS - Object DBMS.

I sistemi classici relazionali hanno consentito di realizzare ottimi sistemigestionali (banche e finanza) caratterizzati da persistenza, condivisione ed af-fidabilita. Per questi sistemi bastava gestire dati semplici (stringhe, caratteri,numeri).

I sistemi relazionali permettevano con la loro sintassi di realizzare queryanche molto complesse.

Causa la rapida evoluzione tecnica, sono nate delle aree applicative per cuigli RDBMS non erano propriamente adatti. Basti pensare all’archiviazione diimmagini, volendo usare un RDBMS le alternative sarebbero:

� inserire in un campo di una tabella il path dell’immagine.

� valorizzare un campo col corrispettivo binario dell’immagine.

Se questo e il problema che si ritrova per un’immagine pensiamo a quanto crescein scala se ci occupiamo di

� archiviazione di foto

� gestione di codici parlanti

� videosorveglianza

oppure in generale di applicazioni che nella maggior parte dei casi necessitanodi gestire dati a struttura complessa.


Se poi si tratta di applicazioni dove l’utente deve poter gestire tipi predefinitie tipi definiti dall’utente stesso in un approccio dove l’utente diventa centralenell’applicazione, risulta evidente che l’utilizzo di un RDBMS non sia ottimale.

Tutti questi sistemi hanno una caratteristica in comune: tutte le unita fon-damentali sono oggetti. Gli oggetti nel paradigma relazionale sono splittati sumolte tabelle, pertanto il divario tra oggetto e struttura relazionale e riempitoda query molto complesse. L’utilizzo di un paradigma che coinvolga oggetti puorisolvere problemi come:

� la specifica di strutture complesse con relazioni unitarie tra i dati.

� la descrizione dei dati integrata e le operazioni per il loro recupero.

� Un rapporto 1:1 con i linguaggi di programmazione ad oggetti.

Una base di dati ad oggetti e una collezione di oggetti in cui ogni oggettoha un identificatore, uno stato ed un comportamento.

� Stato: insieme dei valori assunti dalle proprieta dell’oggetto.

� Comportamento: insieme dei metodi che possono essere applicati al-l’oggetto.

� OID: identificativo dell’oggetto (in genere non e gestito dall’utente ma glie invisibile).

Nel paradigma ad oggetti ci sono due approcci che, sebbene presentino dellecaratteristiche comuni, si presentano rispetto agli schemi relazionali in manieradissimile:

� OODBMS - Object-oriented DBMS

� ORDBMS - Object-relational DBMS

Nel paradigma ODBMS un oggetto e un’istanza di un certo tipo.

Un tipo definisce le proprieta statiche (attributi) e dinamiche (metodi) del-l’oggetto. La complessita strutturale che questo modello offre e garantita pro-prio dall’uso di costruttori di tipo. Pertanto oggetti che nel mondo reale sonocomplessi vengono rimarcati dalla strutturazione di un tipo complesso.

Una classe e un raccoglitore di oggetti dello stesso tipo. In genere la defini-zione di una classe si articola in due passi:

� Interfaccia

� Implementazione

Alla base di un approccio orientato agli oggetti c’e il principio di incapsu-lamento: l’interfaccia descrive solo le operazioni applicabili sull’oggetto mentrel’implementazione nasconde la struttura dati e il codice interno ai metodi.

La persistenza in questi sistemi e una caratteristica trasparente al program-matore.

1.3. OODBMS 5

1.3 OODBMS

Gli OODBMS estendono i DBMS a partire dalle caratteristiche dei linguaggi diprogrammazione ad oggetti, pertanto superano il disadattamento di impeden-za che esiste nelle basi di dati relazionali tra i linguaggi in cui sono scritte leapplicazioni e l’SQL con cui sono scritte le query per il recupero degli oggetti.

Gia dai primi anni ’80 per combattere le limitazioni del RDBMS e affrontarela sfida della crescita crescente di Internet e il Web, i programmatori hannosviluppato database object-oriented.

L’obiettivo principale degli Object-Oriented Database Management System,sinteticamente noti come OODBMS, e quello di fornire dati coerenti, indipen-denti, sicuri, controllati e servizi estensibili di gestione dati per sostenere ilmodello orientato agli oggetti.

Tra le caratteristiche fondamentali dei database o-o, l’unione di programma-zione object-oriented con tecnologia del database fornisce un sistema integrato disviluppo di applicazioni, portando in questo modello principi distintivi della pro-grammazione orientata agli oggetti: eredita, incapsulamento dei dati, identitadell’oggetto e polimorfismo.

L’ereditarieta permette di sviluppare soluzioni a problemi complessi in mo-do incrementale attraverso la definizione di nuovi oggetti in termini di oggettiprecedentemente definiti.

L’incapsulamento dei dati permette di nascondere lo stato interno deglioggetti. Gli oggetti incapsulati sono quegli oggetti che possono essere valuta-ti solo utilizzando i loro metodi, invece di accedere direttamente ai loro statiinterni. Per realizzare l’incapsulamento bisogna riferirsi alle parti pubbliche eprivate di una classe.

Parti private sono gli stati interni della classe che appartengono alla classee non possono essere acceduti direttamente dall’esterno.

Parti pubbliche sono i comportamenti, i metodi, che facendo parte di unaclasse hanno visibilita degli attributi della stessa e quindi possono accedervi inlettura e scrittura, permettendo cosı di esporre in maniera controllata lo statointerno agli altri oggetti dell’ambiente.

L’identita dell’oggetto permette agli oggetti del database di essere indipen-denti l’uno dall’altro.

Il Polimorfismo ed il binding dinamico permettono di definire le opera-zioni per un oggetto e poi di condividere la specifica della cooperazione con altrioggetti. Questo permette agli utenti e/o programmatori di comporre oggetti,di fornire soluzioni senza dover riscrivere il codice comune a piu classi. Un lin-guaggio per OODBMS si compone di una parte per la definizione dei dati edun’altra per la manipolazione del linguaggio (DDML = odl + oql). L’uso diquesto linguaggio permette di creare dati persistenti, aggiornarli, cancellarli e


recuperarli. Un OODBMS ha insito un vantaggio computazionale rispetto a undatabase relazionale, perche evita il disadattamento (mismatch) di impedenza.

Il DDML - Document Definition Markup Language - permette agli utenti didefinire una base di dati, inclusa la creazione, modifica ed eliminazione di oggettie di stabilirne le relazioni. Inoltre i linguaggi DDML vengono utilizzati pereffettuare operazioni di mantenimento e di interrogazione di un database, cioe,operazioni come l’aggiornamento, l’inserimento, la modifica e l’interrogazionedei dati.

Gli OODBMS presentano molti vantaggi:

� sono orientati agli oggetti pertanto permettono di rappresentare la realtail modo piu naturale.

� le operazioni definite su questi tipi di sistemi non dipendono dalla parti-colare applicazione di database che e in esecuzione in un dato momento.

� i tipi di dati trattati dai database orientati agli oggetti possono essereestesi per supportare dati complessi.

� derivati dall’object-oriented sono la riusabilita, la stabilita e l’affidabilita.

� le relazioni sono rappresentate in modo esplicito, spesso sostenendo sial’accesso alla navigazione che l’accesso associativo alle informazioni. Que-sto si traduce in un miglioramento delle prestazioni di accesso ai datirispetto al modello relazionale a scapito comunque della manutenibilita.

� gli utenti sono autorizzati a definire i propri metodi di accesso ai dati ecome i dati saranno rappresentati e/o manipolati in maniera flessibile.

Lo svantaggio maggiore degli OODBMS e che manca un modello comunedi dati.

La tecnologia dei database object-oriented e un matrimonio di programma-zione orientata agli oggetti e tecnologie di database, la figura 1.1 mostra comequesti concetti di programmazione e di database si siano uniti per offrire cio cheoggi chiamiamo i database object-oriented.

Tutte queste funzionalita si uniscono sinergicamente a fornire significativivantaggi di produttivita per gli sviluppatori di applicazioni basate su database.Quando la complessita delle interrelazioni tra le informazioni all’interno deldatabase aumenta, cosı fanno anche i vantaggi che si ricavano dal rappresentarele relazioni in modo esplicito.

Un altro vantaggio di rappresentare relazioni in modo esplicito e il miglio-ramento delle prestazioni di accesso ai dati in confronto ai database relazionaliche basano tutto sul valore.

Una caratteristica unica degli oggetti e che hanno un’identita che e indipen-dente dallo stato dell’oggetto. Per esempio, su un oggetto macchina possiamorimodellare la macchina e cambiare il suo aspetto, il motore, la trasmissione, ele gomme in modo che appaia completamente diverso, sebbene venga comunquericonosciuto come lo stesso oggetto che avevamo inizialmente.

L’Object-identita consente agli oggetti di essere condivisi su di un sistemadistribuito.

1.4. ORDBMS 7

Figura 1.1: Tecnologie OODBMS

Tutti questi vantaggi applicativi rendono i database object-oriented preferi-bili per supportare problemi di gestione delle informazioni, caratterizzati dallanecessita di gestire:

� un gran numero di tipi di dati diversi,

� un gran numero di relazioni tra gli oggetti,

� oggetti con comportamenti complessi.

Le aree applicative dove questo tipo di complessita esiste comprendono l’inge-gneria, la fabbricazione, le simulazioni, l’office automation.

1.4 ORDBMS

Gli ORDBMS - Object-Relational Database Management System - sono sistemiil cui punto focale e “il tentativo di estendere i sistemi di database relazionali conle funzionalita necessarie per supportare una classe piu ampia di applicazioni e,in molti modi, fornire un ponte tra i paradigmi relazionali e object-oriented”.

Gli ORDBMS sono stati creati per gestire nuovi tipi di dati complessi inrisposta al paradigma OODBMS, di fatto il loro sviluppo fu spinto dal maggioreutilizzo dei linguaggi di programmazione object-oriented per la gestione dei daticomplessi.

Il vantaggio fondamentale dei sistemi ORDBMS e permettere alle aziende dicontinuare a utilizzare i sistemi esistenti, senza dover fare grandi cambiamenti,


proponedosi come una estensione – naturale evoluzione – dei database relazio-nali. Un secondo vantaggio e che permettono agli utenti e programmatori diiniziare a utilizzare sistemi orientati agli oggetti in parallelo all’utilizzo dei dbrelazionali.

Il modello dei dati offerto dagli ORDBMS e compatibile col modello dei datirelazionali, cosı da consentire la definizione di tabelle e vincoli di integrita SQL.

Ad ogni modo e suggerito utilizzare un approccio diverso tramite la defi-nizione di tipi cosı da avere un maggiore riutilizzo delle strutture create colmeccanismo delle gerarchie. L’uso di costruttori complessi rimarca una primasostanziale differenza dai database relazionali classici. I tipi possono essere:

� tipi distinti: corrispondono ai domini di SQL.

� tipi strutturati: sono usati per creare le strutture delle tuple da inserirenelle tabelle.

Oltre ai tipi questi dbms offrono la possibilita di scrivere delle procedure di-rettamente nel linguaggio applicativo di riferimento (c++, java, ecc.) in accordoalle caratteristiche degli odbms.

Una relazione, utilizzando questa tecnologia, si riduce, dal punto di vistatecnico, ad una relazione unaria le cui tuple corrispondono ad oggetti. La com-plessita del linguaggio consente di produrre tuple con all’interno varie sottotuple,offrendo la possibilita di descrivere in maniera complessa oggetti complessi.

Gli ORDBMS offrono la possibilita di riusare gli oggetti con il meccanismodelle gerarchie che possono essere di Tipo o di Tabella, in accordo a quantoavviene nel paradigma object-oriented.

La tecnologia degli ORDBMS sebbene, come gia detto, non rivoluzionariaha avuto grande successo, in quanto molti dei maggiori produttori di RDBMSse ne sono interessati, favorendo cosı il suo rapido sviluppo. Ad oggi i databaseOracle, Microsoft SQL Server e l’IBM col suo DB2 suportano questa tecnologia.

Capitolo 2

MongoDB

MongoDB e un’implementazione in C++ di un DBMS document-oriented. Sulsito ufficiale di riferimento (http://www.mongodb.org) le caratteristiche chiavedel sistema portano ad una rassicurante tagline:

MongoDB (from “humongous”) is a scalable, high-performance,open source, document-oriented database.

Nei prossimi paragrafi si scendera nel dettaglio delle caratteristiche del siste-ma, grazie alle quali questo riesce a coprire il vuoto tra i sistemi chiave-valore -veloci e altamente scalabili - ed i classici RDBMS - che presentano un set com-pleto di funzionalita e ricchezza di query, a fronte di una maggiore complessitae pesantezza.

2.1 Document-oriented storage

E’ possibile implementare database doc-oriented realizzando uno strato soft-ware da porre su un database ad oggetti relazionale (ORDBMS) oppure par-tendo da un database orientato agli oggetti (OODBMS). Nel primo caso glioggetti prenderanno posto direttamente nel database e saranno resi disponibiliattraverso query in un apposito linguaggio.

MongoDB segue il secondo approccio, quello in cui si utilizzano oggetti per-sistenti in un linguaggio di programmazione orientato agli oggetti ed un set diAPI per memorizzare e recuperare gli oggetti stessi.

Dal paradigma doc-oriented eredita il meccanismo di storage: non si memo-rizzano i dati in tabelle con campi uniformi per ogni record come nei databaserelazionali, ma ogni record e memorizzato come un documento (un oggetto per-sistente, quindi) che possiede determinate caratteristiche. Qualsiasi numerodi campi con qualsiasi lunghezza puo essere aggiunto al documento. I campipossono anche contenere pezzi multipli di dati.

Un esempio concreto di documento contenente informazioni su di un viaggio,potrebbe essere il seguente:

{” i d ” : ”9 a826400d60073813c6f62508f9260e5 ” ,

” r ev ” : ”1−1915117622” ,

9

10 CAPITOLO 2. MONGODB

” type” : ”Travel ” ,

” d e s t i n a t i on ” : ”Tokio” ,

” dates ” : {” from” : ”15/07/2010” ,

” to ” : ” 10/08/2010”

} ,” p a r t i c i p an t s ” : [ ” S i l v e s t r o ” , ”Luca” , ”Pippo” ]

}

Per inquadrare subito le potenzialita di un simile approccio immaginiamo divoler aggiungere in un secondo momento, in una applicazione gia in produzionesu i viaggi effettuati, informazioni relative ad i mezzi di trasporto usati ed ilclima incontrato. Basterebbe estendere in questo modo il documento:

{” i d ” : ”9 a826400d60073813c6f62508f9260e5 ” ,

” r ev ” : ”1−1915117622” ,

” type” : ”Travel ” ,

” d e s t i n a t i on ” : ”Tokio” ,

” dates ” : {” from” : ”15/07/2010” ,

” to ” : ” 10/08/2010”

} ,” p a r t i c i p an t s ” : [ ” S i l v e s t r o ” , ”Luca” , ”Pippo” ] ,

” us ing ” : [ ” car ” , ”bus” , ” a i r p l an e ” ] ,

”weathers ” : [ ”sunny” , ” cloudy ” ]

}

Normalizzazione vs Incorporamento In un modello relazionale sinonimodi qualita di un database e il livello di normalizzazione adottato per le sue ta-belle (salvo poi rinunciarvi a favore di maggiori performance). Proprieta di unacerta rilevanza per l’applicativo vengono quindi solitamente promosse ad Entitaseparate, referenziate con l’Entita originaria, in modo da non perderne seman-tica e contenuto informativo. Nei doc-oriented si segue un indirizzo opposto,accorpando quanto piu possibile gli oggetti, creando macro-entita dal massimocontenuto informativo, che risucchiano/incorporano tutte le informazioni di cuinecessitano per una determinata semantica.

Collezioni e linee guida Quando un oggetto viene promosso nel mondo doc-oriented viene creata una collezione per tutti gli oggetti dello stesso tipo. Cisono alcune semplici considerazioni che possono chiarire in quali caso l’incorpo-ramento di oggetti in altri oggetti o la creazione di collezioni possa condurre aduna sensibile variazione positiva in termini di performance:

� gli oggetti progettati per contenere altri oggetti, incorporano questi ultimi

� le relazioni molti a molti sono generalmente risolte per riferimento

� collezioni con pochi oggetti possono non essere accorpate se l’applicazionepermette un buon livello di caching

� gli oggetti incorporati, diversamente da quelli di primo livello nella rootdella collezione, difficilmente possono essere referenziati

2.2. SUPPORTO COMPLETO INDICI 11

� incorporare oggetti rende difficile realizzare viste di livello piu profondo diquello principale per la collezione

� c’e un limite di natura fisica (gli oggetti sono salvati in file) che limita ledimensioni per un singolo oggetto

� se l’applicazione richiede performance elevate, l’incorporamento e unasoluzione efficace

2.2 Supporto completo Indici

Come in tutti i DBMS che si rispettino anche ai doc-oriented e richiesta lapresenza di indici. Cosı, in MongoDB:

� il campo id e indicizzato automaticamente

� i campi sui quali e tipico eseguire ricerche o acceduti di frequente andreb-bero indicizzati

� i campi su cui sono definiti ordinamenti generalmente andrebbero indiciz-zati

MongoDB fornisce strumenti in grado di suggerire su quali campi sia op-portuno definire indici, dove non ve ne fossero. Vale ovviamente come regoladel pollice alto privileggiare campi di collezioni con un alto rapporto letture/-scritture (applicazioni read-intensive), avendo gli indici peso prestazionale nellescritture ed esaltando le letture.

Resta comunque vero che gli indici vanno utilizzati preferibilmente se ilcampo e realmente selettivo.

Gli indici sono utilizzati per migliorare le performance delle interrogazioni deldatabase. E’ importante pianificare che tipo di interrogazioni saranno effettuatesul sistema per scegliere il giusto indice.

In MongoDB, un indice e una struttura dati che cataloga le informazionicirca i valori dei campi specificati nei documenti in una collezione.

La struttura dati che realizza l’indice e utilizzata dall’ottimizzatore dellequery per ordinare velocemente i documenti all’interno della collaction trattandoun insieme di dati piu leggero (l’indice appunto, invece che l’intera collaction).In MongoDB la struttura dati utilizzata per implementare gli indici e il B-Tree.

Una volta definito un indice su uno o piu campi sara compito del siste-ma provvedere a mantenere aggiornato l’indice e di riflesso fornire performancemaggiori sulle letture che interrogano i campi chiave.

Direttamente dalla shell di Mongo e possibile definire chiavi:

semplici realizzate indicando il campo di una collection come campo indice.

composta realizzate indicando come campo indice un insieme di due o piucampi.

documento realizzate indicando come campo dell’indice un campo checontiene oggetti. In questo caso solo interrogazioni con ordinamento casualeavranno senso, mentre per interrogazioni ordinate converra considerare chiavicomposte.

array realizzate indicando come campo dell’indice un campo che contieneun array. In questo caso ogni elemento dell’array sara ordinato.


E’ possibile inoltre definire un indice sparso su un determinato campo, cosıfacendo nell’indice saranno compresi solo gli oggetti che presentano il campoindicato, mentre quelli che non lo presentano verranno filtrati.

Definire un indice univoco permettera di esser sicuri che non sia possibileper due oggetti differenti memorizzare lo stesso valore per il campo definitocome chiave univoca.

Caratteristica peculiare di MongoDB e la possibilita di utilizzare indici geo-spaziali bidimensionali. Una volta definito un indice geospaziale sara pos-sibile interrogare la collezioni con query basate sulla posizione geospaziale deltipo trova gli N elementi piu vicini alla mia posizione o criteri piu specifici deltipo trovami gli N musei piu vicini alla mia posizione.

2.3 Replication

La replicazione e utilizzata per rimediare a malfunzionamenti ed introdurreridondanza dei dati nella base dati, sempre a scopo di prevenzione.

MongoDB realizza la replicazione in due modalita:

Master-Slave solo il nodo che funge da master modifica direttamente la basedati, lo slave viene periodicamente sincronizzato con il master ed utilizzato perle letture. In questo modo in ambito distribuito si assicura una consistenzaassoluta sul master ed una consistenza relativa sullo slave, nel senso cheprima o poi lo slave risultera sincronizzato con il master.

Replica Sets e una elaborazione del modello Master-Slave che aggiunge ilripristino automatico dopo un malfunzionamento ed il supporto di cluster diserver con membri primari (master) e secondari (slave).

2.4 Auto-Sharding

Lo sharding e una tecnica utilizzata all’interno dei database per il partizio-namento orizzontale. Nel partizionamento verticale - la normalizzazione - unatabella viene splittata in piu tabelle dividendo i domini (campi) della tabellastessa in modo da separare ed isolare semantiche omogenee. Nel partizionamen-to orizzontale lo split e realizzato in modo da ottenere due o piu insiemi di tupleda sistemare in due o piu tabelle.

Lo sharding estende il concetto di partizionamento orizzontale permettendodi avere agli shard - ovvero le partizioni ottenute dal db di partenza - di essereslegati completamente gli uni dagli altri. In particolare:

� ogni shard puo vivere in una istanza dello schema logico totalementeseparato;

� il server fisico del database che ospita lo shard puo essere diverso da quellodegli altri;

� il data center puo essere qualsiasi, addirittura trovarsi in un altro conti-nente.

2.4. AUTO-SHARDING 13

I vantaggi del partizionamento realizzato sulla base dati iniziale sono diversi:

� e ridotto il numero totale di righe di ogni tabella coinvolta;

� le dimensioni degli indici e ridotto, le ricerche risultano piu efficienti;

� ogni shard puo essere posizionato su hardware differente, permettendo cosıdi ottenere performance superiori grazie al parallelismo;

� la segmentazione dei dati puo seguire in maniera piu naturale quello delmondo reale per una migliore gestione e separazione.

Un esempio su un reale utilizzo dello sharding ne puo chiarire l’utilita. Taletecnica infatti si presta particolarmente per tabelle che prevedno intrinseca-mente un raggruppamento per l’ambito applicativo di interesse. Possiamo alloraconsiderare un portale di commercio elettronico di vaste proporzioni con duemercati relativamente separati come Europa e Stati Uniti.

In un contesto simile lo sharding prevede di realizzare due tabelle separate -identiche strutturalemente - con i dati relativi ai prodotti destinati al mercatostatunitense e quelli relitivi al mercato europero.

E’ possibile addirittura prevedere che tali tabelle siano fisicamente imple-mentate su due server distinti, geograficamente localizzati in modo da aumen-tare le performance - quindi probabilmente uno negli U.S.A e uno nel vecchiocontinente.

Una soluzione del genere e auspicabile sia che vi sia una netta separazionetra i due mercati - politiche aziendali potrebbero ad esempio proibire spedizioniintercontinentali e quindi avrebbe perfettamente senso non permettere acquistidi articoli americani in Europa e viceversa - sia che sia possibile fare richiestead un continente diverso dal proprio.

La logica si complicherebbe ma i vantaggi sarebbero comunque esaltati. Im-maginando infatti che le richieste per prodotti in un altro continente - o su scalamondiale - siano meno frequenti si puo immaginare uno scenario nel quale serverslave continentali aggiornino periodicamente un master globale che ha visionequindi completa sul reale stato del magazzino mondiale dello store.

E’ chiaramente una gestione che comporterebbe un maggior carico di lavoroed una visione non in tempo reale dello stato del sistema, ma che permetterebbecomunque di ottimizzare le operazioni piu frequenti del sistema senza rinunciarealla visione - differita - globale.

Auto-Sharding e il meccanismo attraverso il quale MongoDB segmenta au-tomaticamente una collezione una volta impostata una chiave sulla quale ese-guire lo sharding. La collezione viene riallocata in piu collezioni strutturalmenteidentiche cercando di fare in modo che le dimensioni in termini di oggetti o oc-cupazione di spazio siano bilanciate tra gli shard - le collezioni in cui e statasegmentata la collezione iniziale.

Supponiamo di avere una collezione con un migliaio di oggetti al suo inter-no e di volere eseguire lo sharding su di un campo a della collezione iniziale.MongoDB provvedera a realizzare m collezioni shard ognuna con un numerobilanciato di oggetti. Quando sara necessario effettuare ricerche sulla collezio-ne iniziale MongoDB interroghera un’apposita tabella per sapere a quali shardrivolgersi per ottenere i corrispondenti oggetti.


2.5 Querying

Una delle piu importanti caratteristiche di MongoDB e la sua capacita di sup-portare query dinamiche (ad hoc). I sistemi che supportano le query dinamichenon richiedono degli indici speciali per trovare i dati; gli utenti possono trova-re i dati usando un qualsiasi criterio. Le query dinamiche sono caratteristichedei database relazionali, pertanto, se si decide di migrare dati da un databa-se relazionale verso un MongoDB si scoprira che molte query SQL verrannotrasformate facilmente in query del linguaggio document-based.

Il mongodb supporta varie query-object per recuperare dati. Utilizza unpattern modellato su BSON document. MongoDB supporta una vasta gammadi selettori per i documenti.

Tra le possibili query effettuabili notiamo:

Selettore di campo e possibile specificare di mostrare nei risultati solo unsottoinsieme di campi. In maniera analoga a quanto avviene nella SELECTdi SQL, l’unica differenza e che il campo id e sempre ritornato, anche quandonon specificato.

Selezione e possibile indicare criteri attraverso i quali recuperare un sottoin-sieme dei documenti in una collection. In maniera uguale a quanto si fa in SQLcon la WHERE. E’ possibile ovviamente utilizzare per la selezione, come inSQL:

� operatori condizionali (and, or, nor, in, nin, all, exists, mod, size, type,ne)

� espressioni regolari

� valori in array

� valori negli oggetti embedded

� meta operatori (not)

� operatore di aggregazione (group)

Ordinamenti le query in MongoDB possono ritornare risultati ordinati inmaniera crescente o decrescente, specificando oppurtanamente su quale campoeseguire l’ordinamento. In maniera analoga a quanto avviene con la clausolaORDER BY in SQL.

Skip & Limit sono le opzioni tramite le quali effettuare la paginazione deirisultati in maniera semplice. In maniera equivalente in SQL si trovano gli stessioperatori.

E’ importante sottolineare come i risultati di una query vengano gestiti.MongoDB utilizza la tecnica dei cursori, questi sono usati per recuperareiterativamente tutti i documenti ritornati dalla query eseguita.

Capitolo 3

MongoDB HowTo

3.1 Installazione

In questo capitolo si illustra la procedura di installazione per MongoDB e leoperazioni comuni che ci si aspetta da un DBMS.

1. Download dei file all’indirizzo http://www.mongodb.org/display/DOCS/Downloads

2. Estrazione dei file in una directory qualsiasi (da questo momento talecartella sara indicata come install dir)

3. Creazione della directory root per i dati del database, di default taledirectory e C:\data\db

4. Lancio del demone mongod.exe dalla cartella install dir\bin

Figura 3.1: Avvio demone mongod

15

16 CAPITOLO 3. MONGODB HOWTO

5. Lancio della shell di comando mongo.exe dalla cartella install dir\bin

Figura 3.2: Avvio della shell mongo

NOTA: nella versione a 32bit sussistono alcune limitazione in terminidi dimensioni di file che incidono sulle dimensioni del db stesso.

3.1.1 Utilizzo avanzato del demone mongod

E’ possibile specificare parametri al lancio del demone mongod:

logging Per ridirezionare il logging del server e sufficiente indicare dove loca-re il file di log e come appendere i dati di log semplicemente con il comandoseguente:

> . /mongod −−f o rk −−logpath /var / log /mongodb . l og −−logappend

path db Puo risultare comodo decidere esplicitamente dove salvare tutti i datirelativi a database e collezioni con il seguente comando:

> . /mongod −−dbpath /var / l i b /mongodb/

porta E’ inoltre possibile modificare la porta di ascolto del server con ilcomando:

> . /mongod −−port 12345

3.2. GESTIONE DATABASE 17

3.2 Gestione Database

La shell di mongoDB permette di interrogare i database ed il sistema attra-verso semplici comandi, elencabili attraverso il comando db.help()

> db . he lp ( )

DB methods :

db . addUser ( username , password [ , readOnly=f a l s e ] )

db . auth ( username , password )

db . c loneDatabase ( fromhost )

db . commandHelp (name) r e tu rn s the he lp f o r the command

db . copyDatabase ( fromdb , todb , fromhost )

db . c r e a t eCo l l e c t i o n (name , { s i z e : . . . , capped : . . . , max : . . . })

db . currentOp ( ) d i s p l a y s the cur rent opera t i on in the db

db . dropDatabase ( )

db . eva l ( func , args ) run code se rver−s i d edb . g e tCo l l e c t i o n ( cname ) same as db [ ' cname ' ] or db . cname

db . getCol lect ionNames ( )

db . getLastError ( ) − j u s t r e tu rn s the e r r msg s t r i n g

db . getLastErrorObj ( ) − r e turn f u l l s t a tu s ob j e c t

db . getMongo ( ) get the s e r v e r connect ion ob j e c t

db . getMongo ( ) . setSlaveOk ( ) a l low t h i s connect ion to read from the

nonmaster member o f a r e p l i c a pa i r

db . getName ( )

db . getPrevError ( )

db . g e tP r o f i l i n gL e v e l ( ) − deprecated

db . g e tP r o f i l i n g S t a t u s ( ) − r e tu rn s i f p r o f i l i n g i s on and slow

thre sho ld

db . g e tRep l i c a t i on In f o ( )

db . getSisterDB (name) get the db at the same s e r v e r as t h i s one

db . i sMaster ( ) check r e p l i c a primary s t a tu s

db . k i l lOp ( opid ) k i l l s the cur rent opera t i on in the db

db . listCommands ( ) l i s t s a l l the db commands

db . p r i n tCo l l e c t i o nS t a t s ( )

db . p r i n tRep l i c a t i o n I n f o ( )

db . p r i n t S l a v eRep l i c a t i o n I n f o ( )

db . pr in tShard ingStatus ( )

db . removeUser ( username )

db . repa i rDatabase ( )

db . r e s e tE r r o r ( )

db . runCommand(cmdObj) run a database command . i f cmdObj i s a

s t r i ng , turns i t i n to { cmdObj : 1 }db . s e rv e rS t a tu s ( )

db . s e tP r o f i l i n gL e v e l ( l e v e l ,<slowms>) 0=o f f 1=slow 2=a l l

db . shutdownServer ( )

db . s t a t s ( )

db . v e r s i on ( ) cur rent ve r s i on o f the s e r v e r

db . getMongo ( ) . setSlaveOk ( ) a l low que r i e s on a r e p l i c a t i o n s l av e

s e r v e r


3.2.1 Selezione del database

Per poter gestire i database il primo comando da utilizzare e show dbs, inmodo da avere la lista dei database disponibili per il demone in running. Grazieal comando use e possibile selezionare un database sul quale lavorare.

> show dbs

admin 0.078125GB

l o c a l ( empty )

t e s t 0 .078125GB

>use t e s t

switched to db t e s t

>

3.2.2 Creazione del database

Per creare un database in MondoDB e necessario selezionare il database chesi vuole creare (mydb) tramite il comando use mydb per poi creare al suointerno una prima collezione db.createCollection(nome collezione)

> use mydb

switched to db mydb

> show dbs

admin 0.078125GB

l o c a l ( empty )

t e s t 0 .078125GB

> db . c r e a t eCo l l e c t i o n ( ”myco l l e c t i on ” )

{ ”ok” : 1 }> show dbs

admin 0.078125GB

l o c a l ( empty )

mydb 0.078125GB

t e s t 0 .078125GB

> db . getCol lect ionNames ( )

[ ”myco l l e c t i on ” , ” system . indexes ” ]

>

3.2.3 Eliminazione del database

Per eliminare un database in MondoDB e necessario selezionare il databaseche si vuole creare (mydb) tramite il comando use mydb per poi utilizzare ilcomando db.dropDatabase()

> show dbs

admin 0.078125GB

l o c a l ( empty )

mydb 0.078125GB

t e s t 0 .078125GB

> db . dropDatabase ( )

{ ”dropped” : ”mydb” , ”ok” : 1 }> show dbs

3.2. GESTIONE DATABASE 19

admin 0.078125GB

l o c a l ( empty )

t e s t 0 .078125GB

>


3.3 Gestione Utenti

3.3.1 Creazione Utente

Per creare un utente in un database e necessario selezionare il database perpoi utilizzare il comando db.addUser(nome, password [, readOnly=false])

> db . addUser ( ”Cavani” , ”matador” , t rue )

{” user ” : ”Cavani” ,

” readOnly” : true ,

”pwd” : ” c4c6 f5d2e8ae95a85ac04 f f980c99055 ”

}

Il campo readOnly se settato su true specifica che l’utente avra solo permessidi lettura sul database.

Utenti Globali per associare un utente a tutti i db e sufficiente aggiungeretale utente al db admin

3.3.2 Modifica Utente

Per modificare un utente e sufficiente utilizzare nuovamente il comando db.addUser(nome,password [, readOnly=false])

> db . addUser ( ” Lavezz i ” , ”pocho” , t rue )

{” user ” : ” Lavezz i ” ,

” readOnly” : true ,

”pwd” : ”70 f7bd6b68e8c41fe612c68be865b912 ”

}> db . system . u s e r s . f i nd ( )

{ ” i d ” : ObjectId ( ”4d0e4b6ca738000000004c8a” ) , ” user ” : ”Cavani” ,

” readOnly” :

true , ”pwd” : ” c4c6 f5d2e8ae95a85ac04 f f980c99055 ” }{ ” i d ” : ObjectId ( ”4d0e4bfba738000000004c8b” ) , ” user ” : ” Lavezz i ” ,

” readOnly” :

true , ”pwd” : ”70 f7bd6b68e8c41fe612c68be865b912 ” }> db . addUser ( ” Lavezz i ” , ” go l eador ” )

{” i d ” : ObjectId ( ”4d0e4bfba738000000004c8b” ) ,

” user ” : ” Lavezz i ” ,

” readOnly” : f a l s e ,

”pwd” : ” c1c46bf fec917a30c4d7d23b676ea648 ”

}>

Da osservare come il sisteama riporti l’id del record utente in oggetto e comela password venga per sicurezza salvata con un hash.

3.3.3 Eliminazione Utente

Per eliminare un utente e possibile utilizzare il comando db.removeUser(nome)

3.3. GESTIONE UTENTI 21

> db . system . user . f i nd ( )


[ ” system . indexes ” , ” system . u s e r s ” ]

> db . system . u s e r s . f i nd ( )

{ ” i d ” : ObjectId ( ”4d0de3cb5b18000000003afc ” ) , ” user ” : ”admin” , ”

readOnly” : f a l s e , ”pwd” : ” c532b4c1965addae1c9345e62826fb52 ” }{ ” i d ” : ObjectId ( ”4d0dea2b5b18000000003aff ” ) , ” user ” : ”admin1” ,

” readOnly” : true , ”pwd” : ”5 adae9a7b768fda4fdd2430f8f23d777 ” }> db . removeUser ( ”admin1” )

> db . system . u s e r s . f i nd ( )

{ ” i d ” : ObjectId ( ”4d0de3cb5b18000000003afc ” ) , ” user ” : ”admin” , ”

readOnly” : f a l s e , ”pwd” : ” c532b4c1965addae1c9345e62826fb52 ” }

3.3.4 Autenticazione Utente

MongoDB prevede due modalita di accesso: senza e con autenticazione. Chia-ramente senza autenticazione si da la possibilita a chiunque di accedere indi-scriminatamente alle informazioni. E’ quindi buona norma prevedere l’autenti-cazione per gli utenti, in modo da scongiurare accessi non autorizzati.

Ci si puo autenticare con username e password di un utente in un particolaredatabase, e l’utente stesso con il login ha attribuiti dei privilegi che possonoessere di sola lettura o di lettura-scrittura, a seconda del profilo dell’utenteassociato all’username e password inseriti.

Il database admin e speciale, in quanto, un utente con determinati pri-vilegi nel db admin e un utente con quei privilegi per ogni db, inoltre ha lapossibilita di eseguire delle operazioni di amministrazione che altrimenti nonpotrebbe eseguire. Per abilitare questi controlli di sicurezza bisogna lanciareil demone mongod con l’ opzione –auth, per farlo si deve aver creato prece-dentemente un utente nel database admin di amministrazione. Per effettuare illogin di amministrazione si deve selezionare il db admin e digitare il comandodb.auth(username, password) nella consolle mongo. Una volta fatto questosi potra accedere ad ogni altro db come se vi avessimo fatto il login.

% Lancio i l demone mongod

E:\mongodb−win32−i386 −1.7.3\mongo\bin>mongod −−auth. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

connect ing to : t e s t

> show dbs

Mon Dec 27 14 : 05 : 22 uncaught except ion : l i s tDa taba s e s f a i l e d :{” a s s e r t i o n ” : ” unauthor ized db : admin lock type :−1 c l i e n t

: 1 2 7 . 0 . 0 . 1 ” ,

” asse r t ionCode ” : 10057 ,

” errmsg” : ”db a s s e r t i o n f a i l u r e ” ,

”ok” : 0

}% non posso f a r e i l l o g i n in t e s t

> db . auth ( ”admin” , ” admin i s t ra to r ” )

0

> show dbs

Mon Dec 27 14 : 06 : 18 uncaught except ion : l i s tDa taba s e s f a i l e d :{


” a s s e r t i o n ” : ” unauthor ized db : admin lock type :−1 c l i e n t

: 1 2 7 . 0 . 0 . 1 ” ,



”ok” : 0

}% r i e s c o a loggarmi ne l dbs admin

> use admin

switched to db admin

> db . auth ( ”admin” , ” admin i s t ra to r ” )

1

> show dbs

admin 0.078125GB

l o c a l ( empty )

mydb 0.078125GB

mydb1 0.078125GB

t e s t 0 .078125GB

%una vo l ta loggato da amministratore vado e vedo c i o che vog l i o

> use mydb

switched to db mydb



>

Se si desidera creare un amministratore non dell’intero sistema ma solo di unparticolare db basta creare un utente al suo interno. Le credenziali di loggingdi questo utente gli daranno dei privilegi solo all’interno del db stesso.

connect ing to : t e s t

> use mydb

switched to db mydb

> db . auth ( ”Localadmin” , ” amministratore ” )

1



% lammin i s t ra to re l o c a l e non ha v i s i b i l i t a ' d e g l i a l t r i dbs

> show dbs

Mon Dec 27 14 : 27 : 53 uncaught except ion : l i s tDa taba s e s f a i l e d :{” a s s e r t i o n ” : ” unauthor ized db : admin lock type :−1 c l i e n t

: 1 2 7 . 0 . 0 . 1 ” ,



”ok” : 0

}% anche se c i puo ent ra r e non ne ha v i s i b i l i t a ' de i contenut i

> use mydb1

switched to db mydb1


Mon Dec 27 14 : 25 : 54 uncaught except ion : e r r o r : {” $ e r r ” : ” unauthor ized db :mydb1 lock type :−1 c l i e n t : 1 2 7 . 0 . 0 . 1 ” ,

” code” : 10057

}>

3.3. GESTIONE UTENTI 23


3.4 Gestione Collezioni

Come per i database e disponibile un helper specifico per le collection, utiliz-zando il comando db.nome collection.help()

> db . myco l l e c t i on . he lp ( )

DBCollect ion help

db . myco l l e c t i on . f i nd ( ) . he lp ( ) − show DBCursor he lp

db . myco l l e c t i on . count ( )

db . myco l l e c t i on . dataS i ze ( )

db . myco l l e c t i on . d i s t i n c t ( key ) − eg . db . myco l l e c t i on . d i s t i n c t ( '

x ' )

db . myco l l e c t i on . drop ( ) drop the c o l l e c t i o n

db . myco l l e c t i on . dropIndex (name)

db . myco l l e c t i on . dropIndexes ( )

db . myco l l e c t i on . ensureIndex ( keypattern , opt ions ) − opt ions should

be an ob j e c t with these p o s s i b l e f i e l d s : name , unique ,

dropDups

db . myco l l e c t i on . reIndex ( )

db . myco l l e c t i on . f i nd ( [ query ] , [ f i e l d s ] ) − f i r s t parameter i s an

op t i ona l query f i l t e r . second parameter i s op t i ona l s e t o f

f i e l d s to re turn . e . g . db . myco l l e c t i on . f i nd ( { x : 77 } , {name : 1 , x : 1 } )

db . myco l l e c t i on . f i nd ( . . . ) . count ( )

db . myco l l e c t i on . f i nd ( . . . ) . l im i t (n)

db . myco l l e c t i on . f i nd ( . . . ) . sk ip (n)

db . myco l l e c t i on . f i nd ( . . . ) . s o r t ( . . . )

db . myco l l e c t i on . findOne ( [ query ] )

db . myco l l e c t i on . findAndModify ( { update : . . . , remove : bool [ ,

query : {} , s o r t : {} , 'new ' : f a l s e ] } )

db . myco l l e c t i on . getDB ( ) get DB ob j e c t a s s o c i a t ed with c o l l e c t i o n

db . myco l l e c t i on . ge t Indexes ( )

db . myco l l e c t i on . group ( { key : . . . , i n i t i a l : . . . , reduce : . . . [ ,

cond : . . . ] } )

db . myco l l e c t i on . mapReduce ( mapFunction , reduceFunct ion , <

op t i ona l params> )

db . myco l l e c t i on . remove ( query )

db . myco l l e c t i on . renameCol l ect ion ( newName , <dropTarget> )

renames the c o l l e c t i o n .

db . myco l l e c t i on . runCommand( name , <opt ions> ) runs a db command

with the g iven name where the f i r s t param i s the c o l l e c t i o n

name

db . myco l l e c t i on . save ( obj )

db . myco l l e c t i on . s t a t s ( )

db . myco l l e c t i on . s t o r a g eS i z e ( ) − i n c l ud e s f r e e space a l l o c a t e d to

t h i s c o l l e c t i o n

db . myco l l e c t i on . t o t a l I nd exS i z e ( ) − s i z e in bytes o f a l l the

indexes

db . myco l l e c t i on . t o t a l S i z e ( ) − s t o rage a l l o c a t e d f o r a l l data and

indexes

db . myco l l e c t i on . update ( query , ob j e c t [ , upse r t boo l , mu l t i boo l ] )

db . myco l l e c t i on . v a l i d a t e ( ) − SLOW

db . myco l l e c t i on . getShardVers ion ( ) − only f o r use with shard ing

3.4. GESTIONE COLLEZIONI 25

NOTA: e possibile utilizzare un qualsiasi nome di collezione, anche di noncreate, ottenendo ugualmente un help su di una generica collezione, completodi tutti i comandi di default eseguibili sulle collezioni.

3.4.1 Creazione Collezione

Per creare una nuova collezione in un database e sufficiente selezionare il data-base di interesse ed invocare il metodo db.createCollaction(nome collezione)

> use mydb

switched to db mydb


[ ]

> db . c r e a t eCo l l e c t i o n ( ” Ca l c i a t o r i ” )

{ ”ok” : 1 }> db . getCol lect ionNames ( )

[ ” Ca l c i a t o r i ” , ” system . indexes ” ]

>

3.4.2 Creazione Oggetto

Per creare un oggetto si puo procedere in diversi modi:

In modo esplicito si crea l’oggetto - usando la sintassi JSON - e poi perrenderlo persistente nel database lo si inserisce all’interno di una collection, per-tanto l’oggetto appena creato sara visibile a tutti solo all’atto dell’inserimentonella collection. Un oggetto creato resta utilizzabile a livello della sessione diconnessione finche l’utente resta connesso, pertanto se lo si vuole e modificabilee per eliminarlo lo si deve cancellare esplicitamente. L’ oggetto resta utilizzabileanche se si cambia db come vedremo nella sezione Eliminazione Oggetto.

> c a l c i a t o r e = {nome : ”Marco” , cognome : ”Materazz i ” , prezzo : ”10000

” }{ ”nome” : ”Marco” , ”cognome” : ”Materazz i ” , ” prezzo ” : ”10000” }

> db . Ca l c i a t o r i . i n s e r t ( c a l c i a t o r e )

> db . Ca l c i a t o r i . f i nd ( )

{ ” i d ” : ObjectId ( ”4d0e535ca738000000004c8c ” ) , ”nome” : ” Ezequ ie l ”

, ”cognome” : ” Lavezz i ” , ” a l i a s ” : ”Pocho” }{ ” i d ” : ObjectId ( ”4d0e541ba738000000004c8d” ) , ”nome” : ”Edinson” ,

”cognome” : ”Cavani” , ” a l i a s ” : ”Matador” , ”bomber” : ” t rue ” }{ ” i d ” : ObjectId ( ”4d148829610f000000001b33” ) , ”nome” : ”Marco” , ”

cognome” : ”Materazz i ” , ” prezzo ” : ”10000” }

> db . Ca l c i a t o r i . save ( c a l c i a t o r e )




”cognome” : ”Cavani” , ” a l i a s ” : ”Matador” , ”bomber” : ” t rue ” }


{ ” i d ” : ObjectId ( ”4d148829610f000000001b33” ) , ”nome” : ”Marco” , ”

cognome” : ”Materazz i ” , ” prezzo ” : ”10000” }{ ” i d ” : ObjectId ( ”4d148842610f000000001b34” ) , ”nome” : ”Marco” , ”

cognome” : ”Materazz i ” , ” prezzo ” : ”10000” }

In modo implicito si puo creare un oggetto direttamente all’interno di unacollection, in questo caso l’oggetto non ha una vita propria ma la sua esistenzae legata alla collection in cui lo si crea.

> db . Ca l c i a t o r i . i n s e r t ({nome : ”Pippo” , cognome : ” Inzagh i ” , ruo lo : ”

a t taccante ” })> db . Ca l c i a t o r i . f i nd ( )





cognome” : ”Materazz i ” , ” prezzo ” : ”10000” }{ ” i d ” : ObjectId ( ”4d148889610f000000001b35” ) , ”nome” : ”Pippo” , ”

cognome” : ” Inzagh i ” , ” ruo lo ” : ” a t taccante ” }> db . Ca l c i a t o r i . save ({nome : ”Pippo” , cognome : ” Inzagh i ” , ruo lo : ”

a t taccante ” })> db . Ca l c i a t o r i . f i nd ( )





cognome” : ”Materazz i ” , ” prezzo ” : ”10000” }{ ” i d ” : ObjectId ( ”4d148889610f000000001b35” ) , ”nome” : ”Pippo” , ”

cognome” : ” Inzagh i ” , ” ruo lo ” : ” a t taccante ” }{ ” i d ” : ObjectId ( ”4d14889c610f000000001b36 ” ) , ”nome” : ”Pippo” , ”

cognome” : ” Inzagh i ” , ” ruo lo ” : ” a t taccante ” }>

3.4.3 Modifica Oggetto

Un oggetto puo esistere a livello di sessione o all’interno di una collection:

� Nel primo caso l’oggetto esiste a livello di sessione e le modifiche avvengonotramite la ridefinizione di tutti gli attributi dell’oggetto stesso.

> c a l c i a t o r e

{”nome” : ”Marco” ,

”cognome” : ”Materazz i ” ,

” prezzo ” : ”10000” ,


” i d ” : ObjectId ( ”4d148842610f000000001b34” )

}> c a l c i a t o r e = {nome : ”Marco” , cognome : ”Materazz i ” , prezzo : ”

1000000” }{ ”nome” : ”Marco” , ”cognome” : ”Materazz i ” , ” prezzo ” : ”

1000000” }> c a l c i a t o r e = { prezzo : ”100” }{ ” prezzo ” : ”100” }> c a l c i a t o r e

{ ” prezzo ” : ”100” }

� Nel secondo caso si accede ad un oggetto contenuto in una collection,esistente indipendentemente dalla sessione, questo si puo modificare colcomando: update(query, obj [, upsert bool, multi bool])

{ ” i d ” : ObjectId ( ”4d148842610f000000001b34” ) , ”nome” : ”

Marco” , ”cognome” : ”Materazz i ” , ” prezzo ” : ”10000” }{ ” i d ” : ObjectId ( ”4d148889610f000000001b35” ) , ”nome” : ”

Pippo” , ”cognome” : ” Inzagh i ” , ” ruo lo ” : ” a t taccante ” }{ ” i d ” : ObjectId ( ”4d14889c610f000000001b36 ” ) , ”nome” : ”

Pippo” , ”cognome” : ” Inzagh i ” , ” ruo lo ” : ” a t taccante ” }> db . Ca l c i a t o r i . update ({nome : ”Pippo” } ,{ $ s e t :{ cognome : ”

Esempio” }})> db . Ca l c i a t o r i . f i nd ( )

{ ” i d ” : ObjectId ( ”4d148842610f000000001b34” ) , ”nome” : ”

Marco” , ”cognome” : ”Materazz i ” , ” prezzo ” : ”10000” }{ ” i d ” : ObjectId ( ”4d148889610f000000001b35” ) , ”nome” : ”

Pippo” , ”cognome” : ”Esempio” , ” ruo lo ” : ” a t taccante ” }{ ” i d ” : ObjectId ( ”4d14889c610f000000001b36 ” ) , ”nome” : ”

Pippo” , ”cognome” : ” Inzagh i ” , ” ruo lo ” : ” a t taccante ” }>

Il mongodb prevede varie opzioni di modifica (3.1) per il comando update:

Opzione Azione

$addToSet aggiunge il valore all’array solo se questo non e gia presente

$set setta il valore di un determinato campo

$unset elimina un campo

$inc incrementa di un particolare valore partendo dall’ammontare iniziale

$push aggiunge un valore ad un array

$pushAll aggiunge piu valori ad un array

$pull rimuove un valore ad un array

$pullAll rimuove piu valori da un array

$pop rimuove l’ultimo valore dall’array

$rename rinomina il campo con un nuovo nome

Tabella 3.1: Tabella delle opzioni di modifica


Inoltre si possono effettuare modifiche semplici con il comando save()che permette di modificare un oggetto usando l’opzione upsert, se l’oggettoesiste lo modifica se non esiste lo inserisce nella collection.

3.4.4 Eliminazione Oggetto

Per quanto riguarda la cancellazione va distinto il caso in cui l’oggetto sia internoo meno ad una collection:

� Nel caso in cui un oggetto sia definito all’interno di una sessione per venireusato piu volte, si puo ottenere la cancellazione dell’oggetto in due modi:

1. direttamente: si cancella l’oggetto usando direttamente la delete.

> c a l c i a t o r e = {nome : ”Marco” , cognome : ”Materazz i ” ,

prezzo : ”1000000” }{ ”nome” : ”Marco” , ”cognome” : ”Materazz i ” , ” prezzo ” : ”

1000000” }> c a l c i a t o r e

{ ”nome” : ”Marco” , ”cognome” : ”Materazz i ” , ” prezzo ” : ”

1000000” }> de l e t e c a l c i a t o r e

t rue


Fr i Dec 24 13 : 11 : 46 Refe renceError : c a l c i a t o r e i s not

de f ined ( s h e l l ) : 0

>

2. indirettamente: l’oggetto viene eliminato automaticamente alla chiu-sura della sessione. Nell’esempio e mostrato come l’oggetto persistagrazie alla sessione, anche su database diversi, essendo un ogget-to allocato globalmente nella sessione. Una volta chiusa la sessionel’oggetto non risulta piu disponibile.

> c a l c i a t o r e = {nome : ”Marco” , cognome : ”Materazz i ” ,

prezzo : ”1000000” }{ ”nome” : ”Marco” , ”cognome” : ”Materazz i ” , ” prezzo ” : ”

1000000” }> c a l c i a t o r e


1000000” }> use t e s t

switched to db t e s t



1000000” }. . To mydb . . .



1000000” }> e x i t

bye

E:\mongodb−win32−i386 −1.7.3\mongo\bin>mongo


MongoDB s h e l l v e r s i on : 1 . 7 . 3

connect ing to : mydb


Fr i Dec 24 13 : 16 : 56 Refe renceError : c a l c i a t o r e i s not

de f ined ( s h e l l ) : 0

>

� Nel secondo caso si deve cancellare un oggetto inserito in una collection,per realizzare questa operazione si procede usando la remove(query). Ilmetodo in base alla query passata, effettuera una scansione della collec-tion, eliminando tutti gli oggetti che rispettino le condizioni della query.


{ ” i d ” : ObjectId ( ”4d0e535ca738000000004c8c ” ) , ”nome” : ”

Ezequ ie l ” , ”cognome” :

” Lavezz i ” , ” a l i a s ” : ”Pocho” }{ ” i d ” : ObjectId ( ”4d0e541ba738000000004c8d” ) , ”nome” : ”

Edinson” , ”cognome” :

”Esempio” , ” a l i a s ” : ”Matador” , ”bomber” : ” t rue ” }{ ” i d ” : ObjectId ( ”4d148889610f000000001b35” ) , ”nome” : ”

Pippo” , ”cognome” : ”E

sempio” , ” ruo lo ” : ” a t taccante ” }> db . Ca l c i a t o r i . remove ({ cognome : ”Esempio” })> db . Ca l c i a t o r i . f i nd ( )

{ ” i d ” : ObjectId ( ”4d0e535ca738000000004c8c ” ) , ”nome” : ”

Ezequ ie l ” , ”cognome” :

” Lavezz i ” , ” a l i a s ” : ”Pocho” }

3.4.5 Eliminazione Collezione

L’eliminazione di una collection comporta l’eliminazione di tutti gli oggettiinterni alla collection stessa, si effettua tramite il comando drop().

> db . co l lProva . i n s e r t ({nome : ”prova” })> db . co l lProva . prova interna1 . i n s e r t ({nome : ”prova” })> db . getCol lect ionNames ( )

[

” Ca l c i a t o r i ” ,

” co l lProva ” ,

” co l lProva . prova interna1 ” ,

” system . indexes ”

]

> db . co l lProva . drop ( )

t rue


[

” Ca l c i a t o r i ” ,

” co l lProva . prova interna1 ” ,

” system . indexes ”

]

>

Capitolo 4

Conclusioni

Il MongoDB e giunto ormai alla versione 1.6.5. Nel corso degli anni ha raf-forzato le sue potenzialita, raggiungendo oggi una certa stabilita e diversi puntidi forza che lo caratterizzano:

� l’auto-sharding e la possibilita di scalare in maniera orizzontale;

� l’alta disponibilita dai dati;

� il ripristino automatico dai guasti.

Nel corso degli anni le esigenze applicative relative alle basi di dati si sonospostate dalla semplice catalogazione di file di testo, a delicate transazioni ban-carie per poi arrivare oggi ad avere utilizzatori finali che non solo utilizzanol’applicazione, ma dinamicamente, ogni giorno, la ridisegnano a proprio uso econsumo.

E’ proprio questa forte spinta all’user-centric del web 2.0 che ha fatto esplo-dere il fenomeno di database meno tradizionali e nati proprio per le nuove gene-razioni di applicazioni. Oggi siamo molto vicini a quella che si profila essere lanuova era del web, la sua terza generazione, con tutta l’attenzione posta sullasemantica.

In un tale scenario le applicazioni che vedranno sempre piu la luce sarannoapplicazioni con un forte indice di evoluzione, in cui non solo nuove tipologie direlazioni saranno all’ordine del giorno - se non dell’ora - ma persino il piu piccoloframmento di dato dovra gravitare attorno ad oggetti flessibili ed in grado dimodellare realta sempre diverse.

In tale ottica ecco venire alla luce soluzioni innovative come i document-oriented di cui MongoDB e un rappresentante di spicco, grazie anche a particolipunti di forza sui quali puo contare:

� un driver client in ogni linguaggio: protocolli socket nativi per le interfacceclient/server (non REST);

� uso di file memory mapped per la memorizzazione dei dati;

� memorizzazione collection-oriented (le collezione sono archiviati in modocontiguo);

� consente l’update-in-place (non MVCC);

� e scritto in C++.

31

32 CAPITOLO 4. CONCLUSIONI

Tutto questo accompagnato da scelte architetturali ed una implementazio-ne che ne garantisce performance superiori ad altri sistemi analoghi ed un setcompleto di funzionalita che lo pongono nel panorama attuale come una sceltasicuramente vincente, se cio di cui si ha bisogno e una piattaforma sufficiente-mente stabile ed al tempo stesso attenta a seguire strettamente i trend evolutividel mercato delle applicazioni.

Data questa sua propensione ad essere un sistema malleabile ed al tempostesso performante, il MongoDB potrebbe essere una buona scelta per suppor-tare problemi come:

1. problemi in cui si vogliono avere delle prestazioni elevate come possonoessere quelli per la memorizzazione dei profili utenti di un sito web;

2. problemi in cui e richiesto un tasso di aggiornamento alto come avviene,ad esempio, nell’aggiornamento dei contatori per l’analisi in tempo realedei siti web;

3. problemi in cui il labeling delle risorse e fondamentale e diversificato.

Capitolo 5

Appendice

5.A Sintassi JSON

JSON (JavaScript Object Notation) e un semplice formato per lo scambio didati. Per le persone e facile da leggere e scrivere, mentre per le macchine risultafacile da generare e analizzarne la sintassi.

I tipi supportati sono:

� booleani (true e false);

� interi, reali, virgola mobile;

� stringhe racchiuse da doppi apici ( );

� array (sequenze ordinate di valori, separati da virgole e racchiusi in pa-rentesi quadre [ ] );

� array associativi (sequenze coppie chiave-valore separate da virgole rac-chiuse in parentesi graffe);

� null.

E’ possibile combinare tali tipi di dati in due strutture fondamentali:

� un insieme di coppie nome/valore. In diversi linguaggi, questo e realizzatocome un oggetto, un record, uno struct, un dizionario, una tabella hash,un elenco di chiavi o un array associativo.

� un elenco ordinato di valori. Nella maggior parte dei linguaggi questo sirealizza con un array, un vettore, un elenco o una sequenza.

Oggetto e una serie non ordinata di nomi/valori. Un oggetto inizia con {(parentesi graffa sinistra) e finisce con } (parentesi graffa destra). Ogni nome eseguito da : (due punti) e la coppia di nome/valore sono separata da , (virgola).

var car = {” engine ” : ” d i e s e l ” , ”wheels ” : 4}

Array e una raccolta ordinata di valori. Un array comincia con [ (parentesiquadra sinistra) e finisce con ] (parentesi quadra destra). I valori sono separatida , (virgola).

33

34 CAPITOLO 5. APPENDICE

var f r u i t s = [ ” apple ” , ” orange ” , ”banana” ]

Valore puo essere una stringa tra virgolette, o un numero, o vero o falso onullo, o un oggetto o un array. Queste strutture possono essere annidate.

Stringa e una raccolta di zero o piu caratteri Unicode, tra virgolette; per lesequenze di escape utilizza la barra rovesciata. Un singolo carattere e rappre-sentato come una stringa di caratteri di lunghezza uno. Una stringa e moltosimile ad una stringa C o Java.

Strutture composte e possibile combinare tutti i tipi di dati in strutturecomplesse.

var car = {” engine ” : ” d i e s e l ” ,

”wheels ” : 4 ,

” op t i ona l s ” : [ ” abs” , ” eps ” , ” a i rbag ” : {” d r i v e r ” : true , ” s i d e ” :

true , ”baby” : f a l s e } ]

}

5.B. MIGRARE DA SQL A MONGODB 35

5.B Migrare da SQL a MongoDB

Nella tabella 5.1 si mostra cosa offre mongo rispetto ad un database relazionalecome mysql.

MongoDB MySQL

Modello dei Dati Document-Oriented (BSON) Relazionale

Tipi di Dato string, int, double, boolean,

date, bytearray, object, array,

others

tipi numerici, tipi date and time,

tipi string (character)

Supporto Files Si ?

Schema di partizio-

namento orizzonta-

le

Auto-Sharding(v1.6) ?

Replicazione Master-slave (e replica sets) Master-slave

Memorizzazione

Oggetti (Righe)

Basata sulle Collection Basata sulle tabelle

Metodi di Query Linguaggio di query object-based SQL

Indici secondari Si Si

Atomicita Documenti Singoli Si, avanzata

Interfacce Driver Nativi ed add-on tipo

Rest

Driver Nativi

Scritto in C++ C++

Controllo di Con-

correnza

modifica sul posto ?

Indici Geospaziali Si (da giugno 2010 il sistema

di coordinate e cartesiano, le

coordinate sferiche sono in corso

d’opera)

Supportati parzialmente

Modello di Consi-

stenza Distribuito

Consistenza rigida, sono disponi-

bili le letture consistenti da siti

secondari

Consistenza rigida, sono disponi-

bili le letture consistenti da siti

secondari

Tabella 5.1: Tabella tecnica SQL MongoDB

La tabella 5.2 riporta alcune query Sql con il rispettivo equivalente in Mon-goDB, in cui e possibile notare l’uso degli oggetti JSON per le query.

36 CAPITOLO 5. APPENDICE

SQL Statement Mongo Query Language State-

ment

CREATE TABLE USERS (a Number, b Number) implicito; puo essere fatto

direttamente

INSERT INTO USERS VALUES(1, 1) db.users.insert({“a”: 1, “b”: 1})

SELECT a, b FROM users db.users.find({}, {“a”: 1, “b”: 1})

SELECT * FROM users db.users.find()

SELECT * FROM users WHERE age = 33 db.users.find({“age”: 33})

SELECT a,b FROM users WHERE age = 33 db.users.find({“age”: 33}, {“a”: 1, “b”:

1})

SELECT * FROM users WHERE age = 33

ORDER BY name

db.users.find({“age”:

33}).sort({“name”: 1})

SELECT * FROM users WHERE age>33 db.users.find({“age”: {$gt: 33}})

SELECT * FROM users WHERE age<33 db.users.find({“age”: {$lt: 33}})

SELECT * FROM users WHERE name

LIKE “%Joe%”

db.users.find({“name”: /Joe/})

SELECT * FROM users WHERE name

LIKE “Joe%”

db.users.find({“name”: /ˆJoe/})

SELECT * FROM users

WHERE age>33 AND age<=40

db.users.find({“age”: {$gt: 33, $lte:

40}})

SELECT * FROM users ORDER BY name DESC db.users.find().sort({“name”: -1})

CREATE INDEX myindexname ON users(name) db.users.ensureIndex({“name”: 1})

CREATE INDEX myindexname

ON users(name, ts DESC)

db.users.ensureIndex({“name”:1, “ts”:-

1})

SELECT * FROM users WHERE a=1 and b = ‘q’ db.users.find({“a”: 1, “b”: ‘q’})

SELECT * FROM users LIMIT 10 SKIP 20 db.users.find().limit(10).skip(20)

SELECT * FROM users WHERE a=1 or b=2 db.users.find(

{ $or : [ {“a”: 1 } , {“b”: 2 } ] } )

SELECT * FROM users LIMIT 1 db.users.findOne()

EXPLAIN SELECT * FROM users WHERE z=3 db.users.find({“z”: 3}).explain()

SELECT DISTINCT last name FROM users db.users.distinct(“last name”)

SELECT COUNT(*) FROM users db.users.count()

SELECT COUNT(*) FROM users

WHERE AGE > 30

db.users.find({“age”:{$gt:30}}).count()

SELECT COUNT(AGE) FROM users db.users.find(

{“age”:{$exists: true}}).count()

UPDATE users SET a = 1 WHERE b = ‘q’ db.users.update(

{“b”: ‘q’}, {$set: {“a”: 1}}, false, true)

UPDATE users SET a = a+2 WHERE b = ‘q’ db.users.update(

{“b”: ’q’}, {$inc:{“a”: 2}}, false, true)

DELETE FROM users WHERE z = ‘abc’ db.users.remove({“z”: ‘abc’});

Tabella 5.2: Tabella comparativa SQL-MongoDB

Bibliografia

[1] P.Atzeni ed Altri. Basi di Dati. Architetture e linee di evoluzione. McGrawHill

[2] Wikipedia. Document-oriented Database. [http://en.wikipedia.org/wiki/Document-oriented database]

[3] Documentazione MongoDB [http://www.mongodb.org/display/DOCS]

[4] Dropping ACID with MongoDB [http://www.slideshare.net/kchodorow/dropping-acid-with-mongodb]

[5] Wikipedia. MongoDB. [http://en.wikipedia.org/wiki/MongoDB]

37

MongoDB - UniNa STiDuEunina.stidue.net/Basi di Dati 2/Materiale/tesina mongo db.pdfla descrizione...

Documents

Transcript of MongoDB - UniNa STiDuEunina.stidue.net/Basi di Dati 2/Materiale/tesina mongo db.pdfla descrizione...