database nosql: couchbase - ingegneria … · 3.1 couchbase lite ... sarà presentato in...

Scuola Politecnica e delle Scienze di Base Corso di Laurea Specialistica in Ingegneria Informatica

Elaborato in Basi di Dati

Database NoSQL: CouchBase

Anno Accademico 2016/2017

Relatore: Prof. Antonio Picariello

Candidato: Alessio Paolillo matr. N46001975

La mia dedica va a tutte le persone che mi hanno aiutato e sostenuto durante il mio percorso di laurea. In particolare vorrei ringraziare la mia famiglia, mia madre e mia sorella che fin dal principio mi hanno supportato e dato consigli su come affrontare quest’esperienza. Ai miei colleghi universitari, Andrea, Augusta ecc. Per ultima ma non meno importante vorrei ringraziare Simo che da ormai sei anni mi è vicino in ogni attimo della mia vita.

III

Indice

Indice III Introduzione ......................................................................................................................................... 4 Capitolo 1: NoSQL .............................................................................................................................. 5

1.1 Perché NoSQL?.......................................................................................................................... 5 1.1.1 BigData .......................................................................................................................... 5 1.1.2 Internet of Things ................................................................................................................ 7

1.2 Differenza col mondo relazionale .............................................................................................. 7 1.2.1 Database relazionali ............................................................................................................ 7 1.2.2 Database NoSQL................................................................................................................. 8 1.2.3 Vantaggi NoSQL ................................................................................................................ 8

1.3 Teorema CAP ............................................................................................................................. 9 1.4 Tipologia .................................................................................................................................. 12

1.4.1 Key-value .......................................................................................................................... 12 1.4.2 Column family .................................................................................................................. 12 1.4.3 Documents-oriented .......................................................................................................... 12 1.4.4 Graph ................................................................................................................................. 12

Capitolo 2: CouchBase Server ........................................................................................................... 14 2.1 Architettura .............................................................................................................................. 15

2.1.1 Cluster Manager ................................................................................................................ 16 2.1.2 Data Service ...................................................................................................................... 16 2.1.3 Index Service..................................................................................................................... 16 2.1.4 Managed Cache ................................................................................................................. 17 2.1.5 Storage Layer .................................................................................................................... 17 2.1.6 Aggiunta dei nodi .............................................................................................................. 17 2.1.7 Rimozione dei nodi ........................................................................................................... 18

2.2 Modello dei dati ....................................................................................................................... 18 2.3 Gestione dei dati....................................................................................................................... 18 2.4 Recupero e replicazione dei dati .............................................................................................. 19

2.4.1 Cross Data Center Replication (XDCR) ........................................................................... 20 2.5 Performance ............................................................................................................................. 21

Capitolo 3: Couchbase Mobile ........................................................................................................... 22 3.1 Couchbase Lite ......................................................................................................................... 24 3.2 Sync Gateway .......................................................................................................................... 26

Conclusioni ........................................................................................................................................ 27 Bibliografia ........................................................................................................................................ 28


4

Introduzione

Per anni i Database relazionali hanno dominato nell’ ambito dei sistemi di gestione di

basi di dati, con il passare degli anni e con lo sviluppo di nuove tecnologie (Internet

of things) accresce la necessità di gestire dati non strutturati ed il modello relazione

per definizione non è in grado di gestire dati di questo tipo.

Per far fronte a questi limiti nel 1998 Carlo Strozzi introdusse un nuovo termine:

NoSQL.

Con quest’ultimo presentò la nuova tipologia di DB, basati su un modello nel quale

non è presente un’interfaccia SQL standard. NoSQL acronimo di Not Only SQL non

tenta di eliminare i Database relazioni, ma li appoggia in pieno poiché ci sono

situazioni in cui il modello relazionale resta il più opportuno.

Di seguito nel primo capitolo verranno mostrate le caratteristiche dei DB NoSQL,

differenza con gli RDBMS, Teorema CAP e varie tipologie. Nel secondo capitolo

sarà presentato in particolare CouchBase.


5

Capitolo 1: NoSQL

1.1 Perché NoSQL? Le problematiche che hanno portato colossi di internet come Google, Amazon,

Facebook, ad abbandonare il classico modello relazionale e ad investire nella ricerca

e sviluppo dei NoSQL, le possiamo riassumere in quattro nuovi trend tra loro

correlati: BigUser, BigData, The Internet of Things, Cloud Computing.

1.1.1 BigData

L’effettiva quantità di dati oggi generati è abnorme: dai telefoni, alle carte di credito

usate per gli acquisti, dalla televisione agli storage necessari per le applicazioni dei

computer, dalle infrastrutture intelligenti delle città, fino ai sensori montati sugli

edifici, sui mezzi di trasporto pubblici e privati e via discorrendo. I dati vengono

generati con un flusso così crescente che tutte le informazioni accumulate nel corso


6

degli ultimi due anni ha superato l’ordine dei Zettabyte, segnando un record per

l’umana civiltà.

Il termine Big Data si riferisce proprio a cosa si può fare con tutta questa quantità di

informazioni, ossia agli algoritmi capaci di trattare così tante variabili in poco tempo

e con poche risorse computazionali. Uno scienziato, decenni di anni fa per analizzare

una montagna di dati che oggi definiremmo Small o Medium Data avrebbe impiegato

molto tempo e si sarebbe servito di computer mainframe da oltre 2 milioni di dollari.

Oggi, con un semplice algoritmo, quelle stesse informazioni possono essere elaborate

nel giro di poche ore, magari sfruttando un semplice laptop per accedere alla

piattaforma di analisi.

I Big Data non interessano solo il settore IT. Infatti, se l’Information Technology

rappresenta per i Big Data il grande starter da cui partire con gli strumenti necessari

come il cloud computing, gli algoritmi di ricerca e via discorrendo, d’altra parte i Big

Data sono necessari e utili nei mercati business più disparati. Nessun settore in cui

esiste un marketing e dei dati da analizzare può fare a meno dei Big Data.

Nel 2001 l’analista Doug Laney definì un modello di crescita tridimensionale

(volume, velocità, varietà), successivamente nel 2012 fu introdotta una quarta

variabile, la veridicità.

Caratteristiche BigData:

• Volume: rappresenta la dimensione effettiva del dataset. In realtà quello del

volume è un falso problema, in quanto cloud e virtualizzazione aiutano nella

gestione di grosse moli di dati.

• Velocità: si riferisce alla velocità di generazione dei dati

• Varietà: si riferisce alla tipologia dei dati (strutturati e non)

• Veridicità: attendibilità dell’informazione


7

1.1.2 Internet of Things

L'Internet delle cose è una possibile evoluzione dell'uso della Rete: gli oggetti (le

"cose") si rendono riconoscibili e acquisiscono intelligenza grazie al fatto di poter

comunicare dati su sé stessi e accedere ad informazioni aggregate da parte di altri.

Tutti gli oggetti possono acquisire un ruolo attivo grazie al collegamento alla Rete.

L'obiettivo dell'internet delle cose è far sì che il mondo elettronico tracci una mappa

di quello reale, dando un'identità elettronica alle cose e ai luoghi dell'ambiente fisico.

I campi di applicabilità sono molteplici: dalle applicazioni industriali (processi

produttivi), alla tutela ambientale.

Aziende leader del settore utilizzano Couchbase per gestire i loro dati.

• Verizon: con Couchbase, la rete IoT di Verizon consente ai clienti aziendali di

ricevere rapporti ad hoc per le intuizioni di trend e la gestione dei dispositivi.

• BD: BD utilizza dispositivi IoT a Couchbase per consentire ai pazienti di

condividere i dati del loro diabete con i loro medici in tempo reale, in modo che i

medici possano fornire diagnostica e assistenza in tempo reale.

• GE: GE utilizza Couchbase per alimentare la piattaforma Predix, una piattaforma

software IoT basata su cloud per le macchine industriali come turbine eoliche,

treni ecc.

1.2 Differenza col mondo relazionale 1.2.1 Database relazionali

Si basano su relazioni univoche tra i dati. In pratica, tutti i dati sono memorizzati in

forma tabellare, ogni dato contenuto in una tabella si trasforma in un’informazione

vera e propria, solo se associato al suo corrispondente attributo, il quale rappresenta

l’intestazione della colonna dove quest’ultimo è memorizzato.

Questo tipo di struttura implica una frammentazione delle informazioni su più tabelle,

anche quando i dati descrivono un medesimo oggetto per poter ricavare le

informazioni inerenti ad un oggetto bisogna utilizzare delle operazioni come il JOIN,

di conseguenza utilizzare questo modello con grandi moli di dati è sconsigliato, in


8

quanto anche sistemi con grandi capacità computazionali sono di difficile gestione.

1.2.2 Database NoSQL

I dati sono organizzati in documenti e non in tabelle. Un documento può essere di tipo

Key-Value o Document Store basati su semantica JSON. Ogni documento raccoglie

tutti i dati associati ad un’entità in modo tale da poter estrarre tutte le informazioni

senza dover effettuare JOIN che risultano costosi in termini di operazioni.

L’assenza di tabelle permette ai database non relazionali di essere schemaless,

vantaggio non trascurabile.

1.2.3 Vantaggi NoSQL

Di seguito verranno mostrati i vantaggi nell’usare NoSQL

• Leggerezza computazionale: non sono previste operazioni di aggregazione sui

dati, in quanto organizzati in documenti. Negli ambienti SQL la complessità di

queste operazioni cresce all’aumentare della base di dati mentre il NoSQL non ha

limiti di dimensioni. Questa caratteristica mi permettere di ottenere migliori

prestazioni in ambienti BigData. L’unico problema di questa proprietà è la

duplicazione dei dati.


9

• Assenza di schema: i database NoSQL sono privi di schema in quanto il

documento JSON contiene tutti i campi necessari, in questo modo si possono

inserire nuovi tipi di dati velocemente e senza rischi per l’integrità di quest’ultimi.

• Scalabilità orizzontale: la scalabilità è una caratteristica di un sistema che ne

indica la capacità di crescere o decrescere in risposta all’aumento o decremento

del carico di lavoro. I database NoSQL a differenza dei SQL che adottano la

tipologia verticale (vengono effettuati upgrade delle risorse hardware) adottano la

tipologia orizzontale (si aggiunge nuovo hardware, ossia nuovi nodi al sistema).

La scalabilità verticale ha raggiunto il limite da quando internet si è esteso

portando alla luce la necessità di avere un sistema distribuito, ma questo modo di

agire va in conflitto con alcune restrizioni alle ACID, in quanto ci sarebbero

problemi legati alla consistenza dei dati.

1.3 Teorema CAP Il Teorema CAP afferma che, sebbene sia altamente desiderabile per un sistema

software distribuito fornire simultaneamente consistenza, disponibilità e tolleranza

alle partizioni, ciò non è possibile e quindi bisogna stabilire volta in volta in funzione

ai requisiti, quali di queste tre garanzie sacrificare.

Il teorema è stato pensato inizialmente da Eric A. Brewer, fondatore di Inktomi e

chief scientist di Yahoo!, attualmente docente di Informatica presso UC Berkeley.


10

Brewer presentò per la prima volta il teorema all'ACM Symposium on the Principles

of Distributed Computing (PODC, Simposio sui principi della computazione

distribuita, 19 luglio 2000).Quella che inizialmente venne considerata una congettura,

due anni più tardi, nel 2002, divenne a pieno titolo un teorema grazie al lavoro di Seth

Gilbert e Nancy Lynch del MIT, i quali riuscirono a dimostrare formalmente che le

congetture di Brewer erano corrette: nessun sistema informatico può assicurare

consistenza, continua disponibilità e tolleranza alle partizioni allo stesso tempo.

Di seguito verranno descritte brevemente la definizione delle tre garanzie.

• Consistenza: un sistema è definito consistente quando, memorizzato un nuovo

stato nel sistema tutte le richieste nell’arco di tempo che intercorre tra uno stato e

quello successivo forniscono il medesimo risultato. Per esempio, quando si ha a

che fare con una cache con un singolo nodo, a meno di errori di codifica, la cache

è intrinsecamente totalmente coerente poiché lo stato è aggiornato in un nodo e

mantenuto esclusivamente nello stesso. Un singolo nodo quindi garantisce

intrinsecamente la totale consistenza e anche la tolleranza alle partizioni, ma non

una sufficiente disponibilità (e tolleranza ai guasti) e, in scenari non banali, tende

a presentare scarse performance. Quando invece la cache è distribuita e vi sono

due o più nodi, il sistema è pienamente consistente quando tutti i nodi sono in

grado di lavorare sullo stesso stato, ossia vedono gli stessi dati con gli stessi

valori. Queste configurazioni permettono di aumentare la disponibilità del

sistema, e come controparte si incrementa la complessità

• Disponibilità: un sistema è detto continuamente disponibile quando è sempre in

grado di soddisfare le richieste dell’utente. Nel contesto di cache distribuita, come

visto poc'anzi un singolo nodo non permette assolutamente di realizzare un

sistema molto disponibile: è sufficiente che il nodo vada giù affinché il sistema

non sia più disponibile. Qualora invece la cache distribuita funzioni su un

opportuno cluster di server, lo scenario in cui un singolo nodo si renda non

disponibile non generebbe alcuna perdita di informazioni, con l’aumentare dei


11

nodi aumenta la disponibilità del sistema. Come visto, la strategia standard

utilizzata per ottenere la continua disponibilità consiste nel ricorrere ad

un'opportuna ridondanza che nel caso della cache implica la presenza di

molteplici nodi. Ciò, oltre a richiedere opportuni meccanismi per garantire la

consistenza, aumenta le problematiche relative alla tolleranza alle partizioni.

• Tolleranza alle partizioni: proprietà di un sistema di continuare a funzionare

correttamente anche in presenza di una serie di fallimenti dell’infrastruttura fino a

che l’intero network fallisca.

Il teorema CAP ha un'importanza fondamentale nella progettazione di sistemi

software distribuiti: non conoscerlo nei dettagli può generare conseguenze disastrose

come per esempio imbattersi nei requisiti CAP senza rendersene conto finendo per

sprecare anni/budget significativi per cercare di risolvere problemi non risolvibili.

Quindi visto tali restrizioni bisogna adottare una soluzione di compromesso tra: AC,

AP e CP.


12

1.4 Tipologia Di seguito saranno elencate le diverse tipologie di database NoSQL.

1.4.1 Key-value

Sono costruiti come le strutture dati conosciute in informatica come dizionari o

mappe: al loro interno vengono inseriti due valori alla volta, una chiave e il valore ad

essa associato. Quest’ultimo contiene l’informazione vera e propria, mentre il primo è

l’identificatore che permette l’estrazione rapida del valore dal database, rappresentano

la forma più semplice dei sistemi di gestione di Database.

1.4.2 Column family

Le informazioni sono memorizzate per colonna e non per riga. Questi tipi di database

sfruttano spesso un’indicizzazione su due o più livelli, questo favorisce la velocità di

accesso alle informazioni che ci interessano di un determinato oggetto.

1.4.3 Documents-oriented

In queste soluzioni, la rappresentazione dei dati è affidata a strutture simili ad oggetti,

dette documenti, ognuno dei quali possiede un certo numero di proprietà che

rappresentano le informazioni. Un documento ha un formato riconosciuto (XML,

JSON…) che permette al server di effettuare le query.

1.4.4 Graph

Funzionano come i grafi, strutture dati che rappresentano una rete di nodi collegati tra

loro da archi. Le informazioni possono essere custodite sia nei nodi sia negli archi.


13

Gestire i grafi non è mai impresa troppo semplice, proprio per la loro struttura

intricata, ma il loro contributo è decisivo in casi d’uso in cui si hanno relazioni

fortemente correlate tra loro.


14

Capitolo 2: CouchBase Server

Couchbase Server è un database NoSQL open source, distribuito e document-oriented

ottimizzato per l’interazione tra applicazioni che offre un pieno supporto alle SDK

per Java, C#, PHP, C, Python e Ruby. Utilizza indici progettati appositamente per

effettuare query veloci. Per dispositivi mobile e IoT una particolare distribuzione di

Couchbase (Couchbase Lite) viene installata sul dispositivo stesso che lo rende in

grado di sincronizzarsi al server. Couchbase Server è specializzato per fornire bassi

tempi di risposta per applicazioni web interattive, mobile e IoT. Propone un modello

di dati flessibile con schema dinamico, consente di effettuare JOIN in modo da avere

una vasta gamma di modelli di dati disponibili.

È disponibile in tre versioni:

• Enterprise Edition: rappresenta la versione più stabile, consigliata per prodotti

commerciali.

• Community Edition: consigliata per prodotti non commerciali in cui sono

sufficienti i servizi di base.


15

• Open source project: versione in cui gli utenti possono contribuire allo sviluppo

di Couchbase.

2.1 Architettura L'architettura di base è stata progettata per semplificare la creazione di applicazioni

moderne con un modello di dati flessibile e una maggiore disponibilità, elevata

scalabilità, elevate prestazioni e sicurezza avanzata. È un sistema composto da un

cluster di server dove su ogni nodo sono disponibili dei servizi di sistema per gestire

la replicazione, l’immagazzinamento ed il caching dei dati. È possibile aggiungere (o

rimuovere) i server nel cluster con il clic di un pulsante adattando le risorse alle

mutevoli esigenze della applicazione in esecuzione. La semplice aggiunta di più

server realizza una scalabilità orizzontale del sistema con l’aggiunta di RAM e di

capacità di I/O.

Fornisce un monitoraggio avanzato grazie ad una ricca interfaccia web di

amministrazione. Gli utenti possono controllare l'intero cluster utilizzando un sistema

di monitoraggio che realizza grafici e statistiche in tempo reale.


16

2.1.1 Cluster Manager

È eseguito su ogni nodo del cluster ed è responsabile delle seguenti operazioni:

• Gestione dei nodi

• Posizionamento dei dati

• Autenticazione al cluster

2.1.2 Data Service

Fornisce l’accesso ai dati. Couchbase memorizza i dati in documenti, ogni documento

possiede una chiave per effettuare ricerche e per renderlo unico. Permette l’accesso

contemporaneo ai dati da molte applicazioni garantendo tempi di risposta brevi.

2.1.3 Index Service

Un indice è una struttura dati che fornisce metodi rapidi ed efficiente per l’accesso ai

dati. Possiamo distinguere gli indici in due classi, locali e globali. Gli indici locali

sono utilizzati sui singoli nodi in modo da ottimizzare l’efficienza della rete, invece

quelli globali possono essere partizionati in modo indipendente e non sono distribuiti

ugualmente tra i nodi.

Couchbase fornisce tre tipi di indici elencati di seguito:

• MapReduce view indexer: utilizza degli indici definiti dall’utente così da ridurre

i tempi di indicizzazione. Questo rende le viste una soluzione ottima per query

interattive di reporting che richiedono una riconfigurazione dei dati che possono

fornire risposte a basse latenze.

• Spatial view indexer: le viste vengono indicizzate in modo analogo al

MapReduce view indexer, tuttavia viene creato un R-tree che consente di

elaborare dati geografici con query multidimensionali.

• GSI indexer: utilizza indici simili a quelli usati nei database relazionali. È

un’ottima soluzione per le query di ricerca secondaria necessaria per applicazioni

interattive che richiedono basse latenze. Sono definiti secondo il comando

CREATE INDEX in N1QL. Elabora le modifiche del bucket (contenitore logico


17

per un insieme di elementi correlati come coppie di valore chiave e documenti) e

crea un B+ tree per ricerche veloci.

• Query Service: esistono diversi modi per effettuare query sui dati.

o Ricerca attraverso chiave: vengono fornite delle API per effettuare la ricerca

attraverso un valore chiave. La funzione restituisce l’intero documento, questo

metodo è utilizzabile solo se si conosce la chiave di un documento.

o Ricerca attraverso le viste: vengono fornite delle API per interrogare delle

viste.

o Ricerca utilizzando Spatial queries: vengono fornite delle API per effettuare

ricerche su delle Spatial view.

o Ricerca attraverso N1QL queries: si utilizza un linguaggio simile a SQL, a

differenza delle viste N1QL non richiede un indice dedicato e può generare

query specifiche sui dati.

2.1.4 Managed Cache

Ogni nodo utilizza una cache multithread che aiuta a velocizzare sia le operazioni sui

dati sia per il servizio di indicizzazione. Il Data service gestisce la cache come una

cache ad oggetti distribuiti basata su memcached, il supporto a questo tipo di cache è

inoltre fornito via API di varie piattaforme quali Google App Engine, Amazon Web

Services e Windows Azure. Tutte le operazioni key-value sono eseguite tramite

cache. Couchbase Server dispone di un servizio che automaticamente replica i dati su

cache quindi difficilmente un utente che accede al database non troverà un dato in

cache.

2.1.5 Storage Layer

È il livello che si occupa dello spostamento dei dati tra la RAM ed il disco e della loro

persistenza.

2.1.6 Aggiunta dei nodi

L’aggiunta di altri server ad un cluster si realizza facilmente per mezzo

dell’interfaccia di monitoraggio. I documenti vengono poi di nuovo bilanciati in


18

modo automatico sul cluster, secondo lo spostamento minimo di documenti.

Aggiornata la Cluster Map le chiamate alle App Database saranno distribuite su un

numero maggiore di server.

2.1.7 Rimozione dei nodi

Quando un cluster rileva il fallimento di un server, di conseguenza favorisce l’uso

delle repliche dei documenti persi e aggiorna la Cluster Map, quindi le richieste di

documenti da parte delle App devono essere indirizzate ai server di replica. Viene

quindi realizzato un ribilanciamento dei dati tra i nodi.

2.2 Modello dei dati Couchbase memorizza i dati in documenti formato JSON. JSON utilizza una

notazione semplice e compatta e supporta qualsiasi tipo di dato, atomici come interi

ma anche dati complessi come array. Diversi vantaggi scaturiscono dall’uso di JSON,

come ad esempio la sua compatibilità con le applicazioni per il web visto la sua

relazione con JavaScript.

Un documento rappresenta una singola istanza di un oggetto, in Couchbase i

documenti rappresentano le righe di una tabella, mentre ogni attributo la colonna.

2.3 Gestione dei dati Tutti i dati vengono immagazzinati in modo asincrono sul disco in modo da

consentire la memorizzazione di dataset più grandi della dimensione fisica della

RAM. Couchbase sposta automaticamente i dati tra la RAM e il disco e mantenendo

il “working set” nella cache a livello-oggetto. Garantisce l’atomicità a livello di

documento, un’operazione su un documento quindi sarà portata totalmente al termine

o cancellata.

Couchbase utilizza la restrizione CP (consistency, partition tolerance) del Teorema

CAP e viene eseguito come un singolo cluster affinché ad ogni accesso la richiesta

viene indirizzata al nodo che ospita il dato. In caso di guasto di un nodo, alcuni dati

saranno temporaneamente non disponibili per le scritture. Le letture, tuttavia, possono

continuare ad essere servite dalle copie di replica di dati altrove nel cluster.


19

2.4 Recupero e replicazione dei dati Per garantire un'elevata disponibilità delle applicazioni basate su Server CouchBase,

vengono memorizzate più copie dei dati all’interno del cluster. Le repliche dei dati

sono distribuite su tutti i nodi riducendo così l'impatto di un fallimento sui singoli

nodi.

Couchbase supporta una vasta gamma di strategie di recupero dati a seconda delle

esigenze aziendali. L’esatto tool da utilizzare dipende dai Recovery Point Objective

(RPO), un RPO è uno dei parametri usati nell'ambito delle politiche di distaster

recovery per descrivere la tolleranza ai guasti di un sistema informatico. Esso

rappresenta il massimo tempo che deve intercorre tra la produzione di un dato e la

sua messa in sicurezza (ad esempio attraverso backup) e, conseguentemente, fornisce

la misura della massima quantità di dati che il sistema può perdere a causa di guasto

improvviso. Al diminuire dell'RPO desiderato/specificato si rendono necessarie

politiche di sicurezza sempre più stringenti e dispendiose, che possono andare dal

salvataggio dei dati su supporti ridondanti tolleranti ai guasti fino alla loro pressoché

immediata replicazione su un sistema informatico secondario d'emergenza.

Un altro parametro considerato per la scelta della politica di gestione dei guasti è il

Recovery Time Objective(RTO). Il RTO è il tempo necessario per il pieno recupero

dell'operatività di un sistema o di un processo organizzativo in un sistema di analisi

Business Critical System. È in pratica la massima durata, prevista o tollerata, del

downtime occorso. Aspetto di primaria importanza riveste il fatto che il valore di

RTO sia definito, conosciuto e verificato, tenendo presente che se un downtime lungo

danneggia la possibilità di fruire del servizio più di uno breve, il danno maggiore

deriva dall'inconsapevolezza di quanto possa essere il tempo previsto per il ripristino

dei servizi danneggiati.


20

2.4.1 Cross Data Center Replication (XDCR)

XDCR replica i dati tra due o più cluster autonomi di Couchbase. Viene utilizzato in

genere per replicare i dati tra cluster di diverse regioni geografiche. Svolge un ruolo

importante per il recupero dati e la distribuzione del carico. Per il ripristino di

emergenza di un cluster vengono utilizzati cluster di emergenza remoti, il risultato è

simile al recupero dati da un backup.

XDCR migliora le prestazioni distribuendo i dati nei cluster di regioni geografiche in

cui vengono richiesti di più.


21

2.5 Performance Parlare delle incredibili performance che è in grado di raggiungere Couchbase è

molto semplice, infatti è sufficiente visualizzare l’immagine seguente che si riferisce

ad un benchmark effettuato su delle macchine fisiche Cisco usando una scheda di rete

da 10 Giga SolarFlare.

Come si può notare utilizzando un cluster 5 nodi si raggiunge la considerevole

velocità di oltre 1.5 Milioni di transazioni al secondo, 90 Milioni di operazioni al

minuto, il tutto con tempi di risposta sotto il millisecondo.

Anche dal confronto con i più conosciuti Document Database del mercato, MongoDB

e Cassandra, Couchbase ne esce vincitore. Uno studio di Altoros dimostra quanto

Couchbase sia più scalabile e mantenga performance più consistente nei confronti dei

diretti interessati.


22

Capitolo 3: Couchbase Mobile

Le applicazioni odierne si sono evolute oltre a trattare i soli dati basati su testo e

numeri incorporano una vasta gamma di dati multimediali. Ad esempio le

applicazioni per i social media, come Facebook e Twitter, consentono agli utenti di

condividere un numero crescente di tipi di dati sotto forma di testo, immagini e video.

La gestione di questi dati è diventata parte integrante della qualità delle applicazioni

mobile. Con la vecchia tipologia di database le applicazioni avevano sempre più

difficoltà di gestione.

Inoltre, un'applicazione ricca di dati può non funzionare correttamente se dipende

dalla connettività di rete. Altre applicazioni, cercano di colmare questo “vuoto”

attraverso delle Cache contenenti dati recentemente utilizzati. Potrebbe essere una

soluzione, ma funziona in sola lettura. Ciò significa che le apps devono utilizzare un

archivio locale per utilizzare al meglio i dati in modalità offline per poi sincronizzarli


23

al cloud quando si è online. Il database mobile più conosciuto è SQLite, utilizzabile

sia su iOS sia su Android. Tuttavia non incorpora le funzioni di sincronizzazione ed è

basato su un modello relazionale.

Couchbase Lite, insieme a Couchbase Sync Gateway e Couchbase Server, sono i tre

componenti della soluzione di database NoSQL JSON per mobile database offerto da

Couchbase, chiamato Couchbase Mobile. Una delle caratteristiche chiave di

Couchbase mobile è built-in di sincronizzazione (attraverso Couchbase Sync

Gateway) tra le banche dati locali (Couchbase Lite) e database nel cloud (Couchbase

Server), che allevia lo sviluppatore dall’onere di scrivere il proprio codice di

sincronizzazione. Al fine di supportare questa funzionalità, Couchbase Lite è dotato

di un meccanismo di risoluzione dei conflitti che è molto simile a quello usato da Git.

Con Couchbase Mobile, è possibile sviluppare applicazioni mobile che sono sempre

disponibili, sempre reattive e non dipendenti dalla disponibilità e velocità della rete.


24

3.1 Couchbase Lite Couchbase Lite è un database JSON embedded che può essere usato in maniera

standlone, in una rete P2P o come end point remoto per un Couchbase Server.

Supporta la replica peer-to-peer, aggiungendo un componente http l’applicazione

accetterà connessioni da altri dispositivi che dispongono di Couchbase Lite e lo

scambio di dati con essi. In contrasto con le tradizionali applicazioni dove per

accedere ai dati c’è bisogno di una connessione ad Internet, Couchbase Lite supporta

l’accesso ai dati anche in modalità offline siccome il database risiede proprio sul

dispositivo.

Dispone di API native, compatibili con Web App che fanno uso di JavaScript, per C#,

IOS e Android, con le quali è possibile mappare direttamente database a oggetti e che

alcune di esse verranno descritte di seguito.

Il Manager è l’oggetto al primo livello che gestisce una collezione di istanze

Couchbase Lite Database, in particolare crea una directory nel file system e

memorizza all’interno di esso il database. Su Android il path è reperibile attraverso

l’istruzione getFileDir() mentre su iOS e macOS utilizza path prestabiliti di default, è

possibile modificarli durante la creazione del DB. È necessario creare un’istanza della

classe Manager prima che sia possibile lavorare con oggetti Couchbase Lite.

Un Database è sia un contenitore sia un namespace per documenti, lo scope delle

query e il target della replica. Rappresenta il database vero e proprio.

La maggior parte delle applicazioni necessita solo di un database, ma è possibile

utilizzare il Manager per crearne più di uno. I database multipli sono indipendenti

l'uno dall'altro. Se l'applicazione supporta più utenti, ognuno con i propri contenuti e

le proprie impostazioni separate, è consigliabile utilizzare un database per ciascun

utente.

In un database a documenti le entità memorizzate sono chiamante Document. In

Couchbase Lite il corpo di un documento ha la forma di un oggetto JSON identificato

da un ID generato automaticamente o dall’applicazione. Inoltre, un documento può


25

contenere allegati denominati blob binari utili per la memorizzazione di file

multimediali o altri dati non testuali. Couchbase Lite supporta allegati di dimensioni

illimitate, anche se il gateway di sincronizzazione impone attualmente un limite di 20

MB per gli allegati sincronizzati.

Couchbase Lite utilizza le Revisions per risolvere conflitti durante la replica. Una

differenza significativa rispetto agli altri database è il versioning dei documenti che

gestisce conflitti tra più scrittori. Couchbase Lite utilizza una tecnica chiamata

Multiversion Concurrency Control (MVCC) per gestire i conflitti tra più scrittori.

Questa è la stessa tecnica utilizzata dai sistemi di controllo di versione come Git o

Subversion e da WebDAV. La versione dei documenti è simile al meccanismo di

controllo e di impostazione (CAS) di Couchbase Server, ad eccezione del fatto che in

versione Couchbase Lite è necessaria piuttosto che facoltativa e il token è un UUID

(identificativo univoco universale) anziché un numero intero. Ogni documento ha un

campo _rev che contiene l’ID della revisione, assegnato automaticamente ogni volta

che l’oggetto viene salvato o aggiornato. Quindi quando dobbiamo memorizzare un

documento aggiornandone uno esistente, è obbligatorio fornire l’ID della versione

corrente, se non coincide con quella effettiva l’aggiornamento viene interrotto. Le

Revisions formano una struttura ad albero.


26

Un oggetto Replication rappresenta un’attività di replicazione o sincronizzazione che

trasferisce modifiche tra un database locale ed uno remoto. La replica effettiva viene

eseguita in modo asincrono su un thread in background. È possibile monitorare il

processo osservando le notifiche inviate dall’oggetto Replication. Esistono varie

tipologie di Replication:

• Push vs Pull: Push effettua un upload del database locale su quello remoto

mentre un Pull effettua un download dei cambiamenti dal database remoto al

locale.

• One-shot vs Continuous: di default viene eseguita una replica One-shot, cioè

vengono trasferite tutte le modifiche dal database sorgente a quello destinazione.

Mentre una replica di tipo Continuous rimane attiva e ad ogni modifica effettua il

trasferimento.

• Filtered: le repliche possono avere dei filtri che limitano i documenti che

trasferiscono. Ciò può essere utile nel caso in cui il database remoto è molto

grande, con un filtro non viene scaricato tutto sul dispositivo mobile.

3.2 Sync Gateway Couchbase Sync Gateway rende i documenti memorizzati nel cloud disponibili per i

dispositivi mobile. È molto semplice da utilizzare per gli sviluppatori in quanto astrae

il livello rete occupandosi dello scambio di informazioni sulla rete. Utilizza dei canali

di sincronizzazione, ad esempio se un utente è registrato ad un determinato canale

potrà accedere ai dati memorizzati sul server di quel canale.


27

Conclusioni

L’elaborato è stato diviso in tre capitoli, ognuno dei quali evidenzia degli aspetti

fondamentali inerenti all’argomento assegnato.

Nella prima parte è stato evidenziato come i database NoSQL in alcune

circostanze hanno preso il posto del modello relazionale che nell’era dei Big Data

ha iniziato a mostrare i suoi limiti di fronte alle dimensioni ed alla dinamicità delle

informazioni. Dei database NoSQL sono state presentate tutte le caratteristiche e

i limiti, vedi Teorema CAP.

Nella seconda parte invece è stato presentato Couchbase Server, un database

NoSQL con ottime prestazioni in grado di tenere testa ad altri database NoSQL.

Infine nell’ultimo capitolo è stato descritto Couchbase Mobile,

soluzione di Couchbase per l’ambiente mobile. Diviso in tre prodotti

principali possiamo affermare che anche Couchbase Mobile rappresenta

un’ottima scelta per via delle prestazioni e caratteristiche.

28

Bibliografia

[1] developer.couchbase.com

[2] www.couchbase.com

[3] en.wikipedia.org/wiki/Couchbase_Server

[4] it.wikipedia.org/wiki/Teorema_CAP

[5] http://www.html.it/articoli/sql-e-nosql-a-documenti-il-confronto-2/