JBoss Data Grid

Infinispan

Ugo Landini Solution Architect, Red Hat

versione 1.4 06 Aug 2014

Agenda

• NoSQL: introduzione

• Consistent Hashing e CAP Theorem

• Cos’è un Data Grid

• Infinispan/JDG features

Big Datanew generation of technologies ... designed to economically extract value from very large volumes of a wide variety of data, by enabling high velocity capture, discovery and/or analysis IDC, 2012

NoSQLNot Only SQL.!

Definizione A: un sistema di storage alternativo ad un RDBMS !

Definizione B: un qualsiasi sistema utilizzato in alternativa ad un RDBMS

Eventi chiave

• Google BigTable (2005, sviluppi iniziati nel 2004)

• Amazon rilascia il paper con il design di Dynamo (2007)

NoSQL

• K/V Store

• Document Store

• Column based DB

• Graph DB

• ma anche XML, Object DB, Multidimensional, Grid/Cloud, …

“Classic” NoSQLMongoDB CouchDB Redis Riak Infinispan LevelDB Voldemort Neo4J BigTable HBase Cassandra Elastic

Search

Document

K/V

Column Oriented

Graph

Grid & Cloud NoSQL

Infinispan/JDG

Coherence Gemfire HazelCast Gigaspaces

Grid & Cloud

NoSQL

• Impossibile categorizzare in maniera sistematica

• Moltissime sfumature

• Molti casi di “Convergenza Evolutiva”

CAP Theorem

CAP Theorem

• Tre caratteristiche di un Sistema Distribuito

• Consistency

• Availability

• Partition Tolerance

Consistency

• Tutti i nodi di un sistema distribuito vedono gli stessi dati allo stesso momento

Availability

• La garanzia che ogni richiesta riceverà una risposta (positiva o negativa)

Partition Tolerance• Il sistema è in grado di continuare ad

operare in caso di perdita di connettività fra i nodi (es: split brain)

CAP Theorem

CAP Theorem: la versione popolare

• CAP è stato formulato nel 2000

• La spiegazione semplice: C, A, P: scegline due è stata abusata in questi anni da diversi vendor ed è considerata una tautologia

• Nella realtà la questione è più complessa, e dipende dai vincoli e dai tradeoff del sistema

CAP Theorem: modern version

• In altre parole, è vero che è impossibile avere una Availability PERFETTA ed anche la consistenza dei dati in presenza di un partizionamento, che è però un evento raro

CAP Theorem: modern version

• I sistemi moderni possono prendere decisioni diverse rispetto a C ed A:

• per operazioni diverse

• per dati diversi

• in momenti diversi

CAP Theorem: modern version

• Inoltre, C, A e P non sono binarie:

• A è ovviamente continua

• C ha diversi livelli

• Anche P ha delle sfumature, per esempio ci può essere un disaccordo se in un sistema ci sia effettivamente un partizionamento o meno

CAP Theorem: modern version

• Più informazioni nell’articolo di Eric Brewer “CAP 12 anni dopo”

• http://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed

Storia di un’applicazione

Architettura con DB tradizionale

Limiti architetturali

• I Database non scalano e sono un SPF

• Tecnologia datata e tipicamente “conservativa”

• Non cloud-friendly e virtualization- friendly

• Di solito vuole hardware “speciale”

Come i programmatori risolvono il problema: local caching

Node

RDBMS

1. read AA

client 1

VM1

cache

2. write A to cache 3. reads A

Local caching

• Non scala al “livello successivo”

• poca memoria

• no HA

Local caching distribuito

Local caching distribuito

• Local caching distribuito su più nodi

• Gestione dei Dirty reads? (multiple writes, invalidation, ecc.)

• Gestione del Write behind?

“Clustering” della cache

“Clustering” della cache• Cache topology influisce sui client

• Startup time che aumentano

• start della cache, transfer state

• JVM tunings incompatibili

• GC

• Non JVM clients

Cache servers

RDBMS

cache

VM

client 1VM

client 2VM

client 3VM

cache

VM

1. Write2. Update Cache3. Read

cluster

Cache servers

• Protocolli

• open o proprietari

• Transazionalità

• Topologie: replica totale o dati distribuiti

• Smart routing

Consistent Hashing

Consistent Hashing• Hashing Wheel: una “ruota” matematica sulla

quale vengono effettuati gli hash delle K (chiavi)

• Ma anche gli hash dei nodi che partecipano al cluster

• La posizione della chiave sulla ruota, rispetto a quella dei nodi, determina chi è il nodo master per quella chiave (e quali nodi contengono le eventuali repliche)

Cos’è un Data Grid?

Cos’è un Data Grid?

• Motore per gestione di storage in memoria

• Tipicamente distribuito in un cluster

• “Networked memory”

• Una distributed cache “on steroids”

• Un NoSQL Transazionale

Perchè un Datagrid?

• Scalabilità superiore

• Minore latenza

• Ma…

• ... tecnologia nuova da imparare

• ... migrazione applicazioni

Caratteristiche di un Data Grid

• Un semplice key/value storage

• Motore di search per Document storage

• Scalabilità lineare, elasticità e fault tolerance grazie ad algoritmi distribuiti

• Spesso è memory-based, quindi low-latency

Data Grid > Distributed Cache

• Diverse Topologie

• Querying

• Task Execution e Map/Reduce

• Controllo sulla colocation dei dati per ottenere il massimo delle performance

Cos’è Infinispan/JDG?

• Open Source (Apache) data grid platform

• Basato su alcune delle idee di JBoss Cache

• Basato su alcune delle idee di Amazon Dynamo

• Progetto partito nel 2009

• Base per JBoss Data Grid (JDG)

Cos’è Infinispan/JDG?

• Può essere configurato in maniera ACID, privilegiando la consistenza e l’availability

• Può essere configurato in maniera BASE, sacrificando la Consistency

Topologie (Cluster modes)• LOCAL

• come una semplice cache locale (EHCache)

• INVALIDATION

• no sharing

• REPLICATED

• Tutti i nodi sono identici, la capacità totale è quella del singolo nodo. Ex: 2 nodi da 8Gb = 8Gb totali

• DISTRIBUTED

• La capacità totale è la somma dei singoli nodi meno le repliche. Ex: 10 nodi da 8Gb con 1 replica = 40 Gb totali

Esempi di topologie

Distributed senza replica

Distributed con una replica sync

Distributed con una replica async

Replicated

Come scegliere• Replicated:

• “Piccoli” set di dati con alte % di letture e pochi cambiamenti (Ex: Comuni, CAP)

• Distributed:

• Molti dati: scalare linearmente con il numero dei nodi

• effettuare M/R o Distexec

Come scegliere

• Importante: la modalità di clustering si applica per Cache e non per Grid (CacheManager)

• In uno stesso cluster è dunque possibile avere diverse Cache, ognuna con la sua topologia

Consistent Hashing in Infinispan

• Self healing

• No single point of failure

• Highly concurrent

• MVCC locking

Consistent Hashing• Algoritmo di hashing di default per il

Distributed mode: MurmurHash3.

• Può essere modificato o sostituito: ottima idea se la K è un valore che già di per se individua un criterio di partizionamento.

• Può essere “ottimizzato” tramite Server Hinting, Virtual Servers, Grouping e Key Affinity

Hashing: Server Hinting

• Server Hinting

• una tripla di valori (site, rack, server)

• E’ un “Aiuto” al consistent hashing per aumentare l’Availability complessiva del sistema

• Utile per esempio per evitare che le repliche di un dato risiedano nello stesso rack

Hashing: Virtual Servers

• Numero di “segmenti” in cui si partiziona logicamente un cluster

• Migliora la distribuzione dei nodi sull’hashing wheel e dunque la ripartizione delle chiavi stesse

• Default: 60

Hashing: Grouping• Colocation dei dati: lo stesso nodo contiene

il dato X ma anche i dati afferenti ad X (es: anagrafica cliente e suoi movimenti sul conto)

• Si definisce un “gruppo” per il quale il Data Grid garantisce che gli oggetti appartenenti saranno presenti sullo stesso nodo

• Si lavora sui pattern di accesso ai dati più frequenti

Hashing: Key Affinity• Scopo simile alle Grouping API: il Key

Affinity Service è un servizio attraverso il quale possiamo richiedere un ID di cui siamo certi che verrà gestito da un particolare nodo

• Grouping e/o Key Affinity sono fondamentali se si vuole raggiungere il Nirvana del Data Grid

Nirvana del Data Grid

• Tutti i dati che servono ad una applicazione sono disponibili in locale, e dunque alla distanza di una singola chiamata Java

• Cache Store

• Non solo in memoria!

• Write through e write behind (ACK sincrono o asincrono)

• Pluggable “drivers” per diversi store

• File System, JDBC, LevelDB

• MongoDB, JPA, Cassandra, BerkeleyDB, ecc.

Persistenza dei dati

Eviction dei dati• Evita al sistema degli Out Of Memory

• Le entry possono anche essere “passivate” su disco (in diverse modalità, vedi CacheStore)

Expiry dei dati• Si assegna una “vita” al dato stesso (lifespan) o un

tempo massimo di “non utilizzo” (max idle time)

• Dopodiché superati questi valori il dato verrà invalidato e rimosso dal Data Grid (senza passivazione)

• Evita di doversi scrivere job “spazzini”

• Evita degli Out Of Memory

Eviction/Expiry: differenze

• Tutte e due le tecniche servono fondamentalmente per evitare gli Out Of Memory

• I dati “Evicted” a differenza di quelli “Expired” possono essere mantenuti nel Grid per usi futuri con la Passivazione

Transactions

• A differenza della maggior parte dei Database “NoSQL”, Infinispan ha un full support per le transazioni

• Local Transactions

• Global Transactions (XA): individua il TX Manager dell’AS che lo ospita e lo usa

• Batching (come le Global, fra diversi cluster Infinispan)

Listeners / Notifications

• Capacità di ricevere eventi

• A livello di Cache o di CacheManager

• Cambio di topologia

• Aggiunta/Rimozione/Modifica di oggetti

Querying the Grid

• Modulo Infinispan-query

• utilizza Hibernate Search e Lucene

• Querying via DSL

• Gli indici di Lucene possono essere in memoria, su disco o anche essi nella griglia

Map / Reduce

• Map/Reduce è un algoritmo reso famoso da Google per l’implementazione del suo famoso algoritmo di ricerca distribuito

• M/R permette di effettuare delle operazioni “globali” sulla griglia

• Ogni nodo lavora sui dati di sua competenza (Map)

• I risultati vengono poi aggregati (Reduce)

Map / Reduce

Map / Reduce

Distexec: Distributed Execution

• Distexec permette di sottomettere dei “task” alla griglia

• Il task può essere eseguito su tutti i nodi o su un sottoinsieme dei nodi

• Il task può modificare i dati stessi del Grid

Cross Site Replication

Cross Site Replication

• Architetture Follow the Sun

• Permette di avere più Cluster che si sincronizzano fra loro

• In sync o async

Management Tooling

• Infinispan Command Line Console

• JMX

• RHQ/JON Plugin

• Hawt.io plugin (si, la stessa console di Fuse :) )

Modi di utilizzo• Embedded mode / Library mode

• Direttamente dalla JVM

• Client/Server mode

• REST

• Memcached

• Hot Rod

Library Mode

Il Library mode da accesso a tutte le API e le feature

• Map-like key/value store

• Querying, JPA-like layer (Hibernate OGM)

• Listener e Notification

• Transazioni Locali e Globali, Batching

• Map/Reduce e Distexec

Library Mode

Client/Server mode

Protocolli supportati

• REST • Memcached • Hot Rod

• Non tutte le API sono a disposizione su protocolli remoti

• Ci sono differenze di feature per le diverse API

• Il grid può però scalare indipendentemente ed essere accessibile a diversi sistemi

Client/Server Mode

REST

• Utile per client non Java per i quali non esista un protocollo

• HTTP Transport: Firewall friendly • E’ ovviamente più lento delle alternative

Memcached protocol• Protocollo text based molto diffuso • Clustering • State sharing

• Non ha configurazione dinamica: se un nodo cade va riconfigurata la lista dei server

• Utile per swap-in di Memcached, CouchDB o CouchBase

Hot Rod• Wire protocol per

comunicazioni client server • Open Source • Language independent • Built-in failover e load

balancing • Smart routing

Confronto protocolli

ProtocolClient Libs

Smart Routing

Load Balancing/Failover

TX Listeners M/R Dist SearchCluster

separato

Library mode

inVM N/A Yes Dinamico Yes Yes Yes Yes Yes No

REST Text HTTP NoQualsiasi

HTTP load balancer

No No No No No Yes

Memcached Text Molte NoSolo con

predefined server list

No No No No No Yes

Hot Rod BinaryJava/

Python/ C++

Yes Dinamico Locali con MVCC Yes (6.4) No No Yes (6.3) Yes

Confronto protocolli

ProtocolClient Libs

Smart Routing

Load Balancing/Failover

TX Listeners M/R Dist SearchCluster

separato

Library mode

inVM N/A Yes Dinamico Yes Yes Yes Yes Yes No

REST Text HTTP NoQualsiasi

HTTP load balancer

No No No No No Yes

Memcached Text Molte NoSolo con

predefined server list

No No No No No Yes

Hot Rod BinaryJava/

Python/

C++Yes Dinamico Locali con

MVCC Yes (6.4) No No Yes (6.3) Yes

Esempio di ciclo virtuoso OSS

Chi usa

?

Chi usa i Data Grids?

• Chiunque abbia bisogno di:

• massive data volumes

• high transactional throughput

• strict performance characteristics

• uptime elevati

Link e risorse

JDG JBoss Data Grid • Product page: http://www.redhat.com/products/jbossenterprisemiddleware/data-grid/ !

Infinispan • Project page: http://www.infinispan.org • Blog: http://blog.infinispan.org • Twitter: http://twitter.com/infinispan • Community wiki e docs: http://community.jboss.org/wiki/Infinispan