Embed Size (px)
Citation preview
Università degli Studi di Salerno Sistemi Informatici e Tecnologie del Software
Basi di Dati II
Anno 2013/2014
Prof.ssa G.Tortora Prof. G.Polese
Branca Carlo
Grano Giovanni
Merola Matteo
Scalabrino Simone
Cassandra
• Entrambi i tipi producono tabelle (con righe e colonne) come insieme di risultati.
• Entrambi i tipi risolvono le stesse query. • Entrambi i tipi hanno casi d’uso specifici in cui funzionano meglio.
Facile inserire o modificare
un record
Lettura di dati non
necessari
Lettura di soli dati rilevanti
La scrittura di tuple
necessita accessi multipli
Serializzano i dati in righe
Devono leggere i record per intero per poter accedere agli attributi
Spesso le query leggono più dati del necessario
Necessità di utilizzare indici addizionali, dati pre-aggregati e viste speciali
Gran parte dei tuning sono query-specific
Sono progettati per restituire record interi in modo efficiente, usando il minor numero di operazioni possibile.
Sono poco efficienti in operazioni che si applicano sull’intero dataset
Per migliorare le prestazioni si ricorre agli indici. Tuttavia la gestione degli indici
aggiunge un overhead al sistema, specialmente nelle operazioni di scrittura.
Lavorano su colonne
Ogni colonna viene trattata individualmente
I valori di ogni colonna vengono memorizzati contiguamente
Le righe possono essere ricostruite se necessario
I dati nelle colonne sono di tipo omogeneo.
Ciò permette di effettuare ottimizzazioni non possibili sui
database row-oriented Ad esempio sfruttare al meglio
schemi di compressione come LZW e run-length
La compressione riduce lo spazio su disco a discapito dell’efficienza
di recupero dei dati Più sono i dati adiacenti
compressi, maggiore sarà la difficoltà di accesso random
Il confronto tra row-based e column-based si basa principalmente sull’efficienza di
accesso al disco
I column-based sono più efficienti quando un aggregato deve essere calcolato su molte righe, ma solo per un sottoinsieme di tutte le
colonne
Sono efficienti quando vengono insieriti dati per una colonna intera, poiché possono
essere scritti più efficientemente
Se tutti gli attributi sono memorizzati su una singola riga, un column-oriented dovrà effettuare la ricerca più volte (una per ogni tabella presente
nella query) per leggere un singolo record.
Maggiore è il numero di accessi ai record, maggiore sarà il tempo di trasferimento, che inizierà a dominare sul tempo di ricerca, e di conseguenza l’approccio column-oriented inizierà a ad avere prestazioni maggiori rispetto l’approccio row-oriented.
I database column-oriented si adattano bene ad applicazioni read-mostly, read-intensive e su repository con grandi quantità di dati. Oltre ai benefici
nelle performance, hanno anche la qualità di poter comprimere i dati, come fanno i database multidimensionali e i data warehouse.
Sono una componente importante di un ambiente moderno ed eterogeneo. Muovendo il carico di lavoro su database a colonne, un’organizzazione può
sfruttare al meglio le informazioni.
Modello dei dati • Colonne larghe, array
sparsi • Alte performance
attraverso un veloce flusso di scrittura.
Infrastruttura: • Peer-to-Peer Gossip • Coppie Key-value • Consistenza regolabile
Dynamo Bigtable
2008: Open source release / 2013: Enterprise & Community editions
• Problema della Inbox Search
I nodi sono distribuiti all’interno di cluster, i
cluster sono a loro volta distribuiti su più data
center.
Il flusso di lettura e scrittura scala linearmente
con l’aggiunta di nuovi nodi senza alcuna
interruzione.
I dati vengono replicati automaticamente su piu’
nodi. La sostituzione dei nodi puo’ essere
effettuata senza downtime.
Cassandra supporta diversi linguaggi quali Java,
Python, Node.JS, Golang.
E’ l’equivalente di un database RDBMS, con la
differenza che possiede un fattore di replicazione.
E’ un insieme di colonne che forma una ‘tabella’,
può essere semplice o strutturata (super).
Una colonna è composta da nome, valore e
timestamp, rappresenta l’unità base.
RDBMS Cassandra
Dati strutturati, schema fisso Dati non strutturati, schema flessibile
‘’array di array’’ 2D: ROW x COLUMN
‘’coppie chiave-valore innestate’’ 3D: ROW key x COLUMN key x COLUMN value
DATABASE KEYSPACE
TABLE TABLE (COLUMN FAMILY)
ROW ROW (PARTIZIONE). Unità di replicazione.
COLUMN COLUMN (nome, valore, timestamp), CLUSTER. Unità di memorizzazione.
Chiavi esterne, Join, consistenza ACID No chiavi esterne, no join, CAP (coerenza, disponibilità, tolleranza alle partizioni).
CREATE TABLE songs (
id uuid PRIMARY KEY,
title text,
album text,
artist text,
data blob
);
CREATE TABLE playlists (
id uuid,
song_order int,
song_id uuid,
title text,
album text,
artist text,
PRIMARY KEY (id,
song_order)
);
Il nostro social music service richiede una tabella songs con titolo, album e artista, più una colonna chiamata audio che contiene il file audio. La tabella usa uuid come chiave primaria.
In un database relazionale avremmo creato una tabella playlists con chiave esterna verso canzoni ma in Cassandra denormalizziamo i dati. Per rappresentare le playlist creiamo la tabella nel seguente modo:
La combinazione di id e song_order nella tabella playlists identifica in modo univoco una riga nella tabella playlists. Possiamo avere più di una riga con lo stesso id e song_order finché la riga contiene valori differenti in song_order.
SELECT * FROM playlists;
id | song_order | album | artist | song_id | title
-------------+------------+-----------------------+----------------+-------------+--------------------
62c36092... | 1 | Tres Hombres | ZZ Top | a3e64f8f... | La Grange
62c36092... | 2 | We Must Obey | Fu Manchu | 8a172618... | Moving in Stereo
62c36092... | 3 | Roll Away | Back Door Slam | 2b09185b... | Outside Woman Blues
62c36092... | 4 | No One Rides For Free | Fu Manchu | 7db1a490... | Moving in Stereo
In un database relazionale, una query che filtra su artista richiede la scansione sequenziale di tutta la tabella playlists. Cassandra ci consente di creare un indice su artist, estraendo i dati in modo più efficiente:
CREATE INDEX ON playlists(artist);
SELECT * FROM playlists WHERE artist = 'Fu Manchu';
id | song_order | album | artist | song_id | title
-------------+------------+-----------------------+----------------+-------------+--------------------
62c36092... | 2 | We Must Obey | Fu Manchu | 8a172618... | Moving in Stereo
62c36092... | 4 | No One Rides For Free | Fu Manchu | 7db1a490... | Moving in Stereo
