database nosql: couchbase - ingegneria … · 3.1 couchbase lite ... sarà presentato in...
Post on 26-Jun-2018
234 Views
Preview:
TRANSCRIPT
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
Database NoSQL: CouchBase
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.
Database NoSQL: 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
Database NoSQL: CouchBase
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
Database NoSQL: CouchBase
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
Database NoSQL: CouchBase
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.
Database NoSQL: CouchBase
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.
Database NoSQL: CouchBase
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
Database NoSQL: CouchBase
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.
Database NoSQL: CouchBase
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.
Database NoSQL: CouchBase
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.
Database NoSQL: CouchBase
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.
Database NoSQL: CouchBase
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.
Database NoSQL: CouchBase
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
Database NoSQL: CouchBase
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
Database NoSQL: CouchBase
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.
Database NoSQL: CouchBase
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.
Database NoSQL: CouchBase
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ù.
Database NoSQL: CouchBase
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.
Database NoSQL: CouchBase
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
Database NoSQL: CouchBase
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.
Database NoSQL: CouchBase
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ò
Database NoSQL: CouchBase
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.
Database NoSQL: CouchBase
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.
Database NoSQL: CouchBase
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.
top related