Introduzione

All’analisi teorica sinora condotta vogliamo a questo punto affiancare un caso di studio reale, abbiamo infatti eseguito numerosi test per mettere alla prova le funzionalità offerte da MongoDB e le performance che questo DBMS permette effettivamente di ottenere, sia su singolo server sia in ambito distribuito. Per fare questo abbiamo considerato un database contenente una sola collection (tranne “system.indexes”, creata automaticamente dal sistema in ogni db) chiamata “clip” di dimensione pari a 8,54063 gigabyte e contente esattamente 1.431.090 documents. I dati considerati derivano dall’ascolto delle discussioni avvenute on-line relativamente alle elezioni europee del maggio 2014, si tratta pertanto di documenti che contengono post di blog, commenti, articoli di giornali ed ogni altra forma di informazione testuale legata ai temi della politica e dell’attualità. Fra gli altri abbiamo i campi “TITLE” e “CONTENT”, due campi testuali che contengono rispettivamente il titolo ed il contenuto dello specifico intervento rappresentato in un certo document. Ad essi si affiancano molti altri campi in cui si raccolgono alcune informazioni che è stato possibile reperire circa l’autore di quel particolare testo (ad esempio il genere, rappresentato nel campo "AUTHOR_GENDER", o la sua età, riportata in "AUTHOR_AGE"), la fonte da cui il testo considerato è stato reperito (in campi quali “SOURCE” e “SOURCECHANNEL”) e molti altri metadati. I dati qui considerati sono infatti parte integrante di un ampio progetto di Social Business Intelligence che si ripropone un’analisi estremamente più avanzata e complessa di quella condotta per questo studio di tesi, che si prefigge semplicemente di testare, confrontare e valutare le

82 funzionalità offerte da un DBMS NoSQL di grande diffusione ed attrattiva come MongoDB che mette a disposizione strumenti interessanti, potenzialmente fruttuosi ed apprezzabili nonché pratici ed agevoli nell’utilizzo, come le ricerche di testo. Dopo aver proposto una presentazione complessiva di MongoDB e delle sue caratteristiche è proprio sulle ricerche di testo e sui benefici che si possono effettivamente trarre dalla costruzione di uno sharded cluster, e dunque dall’operare in un ambito distribuito, che abbiamo voluto concentrare la nostra attenzione ed i nostri studi. Per condurre i nostri test abbiamo considerato quattro calcolatori aventi la medesima architettura hardware e software descritta nella tabella 3.1, confrontando i risultati ottenuti operando dapprima su singolo server e poi su un cluster costituito da un numero crescente di nodi, da due fino a quattro.

Sistema Operativo Microsoft Windows 7 Professional 64bit Processore Intel(R) Pentium(R), 2 core, 3.40GHz

RAM 4,00 GB

Hard Disk

Hitachi GST Deskstar T7K500

HDT725025VLA380 (0A33423) 250GB 7200 RPM

8MB Cache SATA 3.0Gb/s 3.5" Hard Drive Bare Drive

Tabella 3.1. Caratteristiche delle quattro macchine utilizzate per l’esecuzione dei test.

Dato il ridotto numero di macchine a disposizione e la tipologia di progetto che avevamo intenzione di impostare ed affrontare abbiamo optato per un’architettura più semplice di quella consigliata in ambito professionale, realizzando un cluster in cui:

 ogni shard non è costituito da un replica set ma da un’istanza mongod stand alone,

 si ha a disposizione un unico query router ed un solo config server. La scelta della shard key è stata effettuata a partire dall’analisi delle operazioni che avremmo dovuto effettuare e dei dati considerati, ovvero della struttura dei document raccolti nella collection “clip” e dei valori ad essi assegnati (la loro distribuzione e l’esistenza o meno di document in cui quei campi non fossero stati settati, acquisendo così valore null, o fossero

83 completamente assenti). Come sappiamo la shard key si dovrebbe comporre dei campi più utilizzati nelle query che verranno lanciate sulla collection, cercando così di ottenere i benefici che possono derivare dalla query isolation. Nel nostro caso al centro delle interrogazioni da eseguire si trovavano le ricerche di testo, operate sui campi “CONTENT” e “TITLE”, con qualche condizione di selezione posta a volte sul campo “SOURCE”. Fra quelli elencati l’unico campo sinceramente candidato ad entrare a far parte della shard key è proprio il campo “SOURCE”, poiché sui campi restanti non vengono posti dei filtri, sono oggetto esclusivamente di ricerche di testo, che non traggono benefici dalla costruzione di indici di tipologie comuni (quali sono gli indici costruiti sulla shard key) ma unicamente dall’esistenza di indici di testo, di cui non possono fare a meno. Tali campi inoltre non sempre nei document della collection “clip” risultano valorizzati. La distribuzione dei valori assunti da “SOURCE”, che specificano la fonte (la “sorgente”) da cui sono state tratte le informazioni racchiuse in quel particolare documento, appare però estremamente sbilanciata, per questo motivo abbiamo scelto di adottare una shard key composta, costituita dalla sorgente e dal campo _id che, assumendo un valore distinto in ogni document, assicura il raggiungimento di un’elevata cardinalità. Se da un lato l’alta cardinalità, ossia la capacità di assumere una gran quantità di valori distinti suddivisibili in modo equo fra gli shard, è un ingrediente fondamentale per l’ottenimento di una distribuzione bilanciata dei dati, al contempo essa non assicura il conseguimento di altri due importanti obiettivi, cioé: query isolation e write scaling. Nel nostro caso, a dire il vero, la capacità del sistema di suddividere equamente le operazioni di inserimento fra i nodi del cluster gioca un ruolo secondario, poiché non abbiamo bisogno di inserire nuovi documenti ma solo di interrogare un database già costituito. Ciò che ci interessa è dunque per lo più tentare di ottimizzare le prestazioni in lettura. Proprio per favorire, laddove possibile, la query isolation scegliamo dunque di adoperare come prima componente della shard key il campo “SOURCE”, così che il filtro posto in alcune query su tale campo costituisca una condizione di selezione specificata su un prefisso della shard key, favorendo l’isolamento di tali interrogazioni

84 esclusivamente sulla porzione del cluster effettivamente interessata da ciascuna query.

Come vedremo in realtà fra le interrogazioni che abbiamo testato figurano anche delle query che includono delle condizioni di uguaglianza poste su un campo differente da “SOURCE”, ovvero “SOURCECHANNEL”. L’esecuzione di questo gruppo di interrogazioni è stata però decisa in un momento successivo, quando la costruzione del cluster era già stata avviata, per questo motivo il campo “SOURCECHANNEL” non è stato preso in considerazione al momento della scelta della shard key, che è stata definita nel modo seguente: {SOURCE:1, _id:1}.

Alcune delle interrogazioni eseguite sono state ripetute anche su un secondo cluster, caratterizzato da un’architettura hardware più avanzata. Le macchine che fanno parte di tale cluster sono quattro personal computer HP aventi le caratteristiche riportate nella tabella 3.2

Processore Intel Core i7 (quad-core), 3.6GHz

RAM 32GB

Hard Disk 4TB, 15'000rpm

Tabella 3.2. Caratteristiche HW dei nodi del secondo cluster.

Anche in questo caso l’architettura del cluster è minimale, prevede infatti:

 4 shard costituiti ciascuno da un singolo server,

 1 solo query router,

 1 solo config server.

Dato che i test che sono stati condotti e dei quali si vogliono ora presentare i risultati si concentrano sull’attuazione di ricerche di testo crediamo opportuno dedicare dapprima un po’ di spazio ad un piccolo approfondimento su tale argomento.