infinispan codemotion - codemotion rome 2015
Post on 15-Jul-2015
611 Views
Preview:
TRANSCRIPT
JBoss Data Grid
Tech Lab
Ugo Landini Solution Architect, Red Hat
versione 1.729 Jan 2015
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
• “Networked memory”
• Storage distribuito
• 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 al Consistent Hashing
• Memory-based, quindi low-latency
• ma possibile anche gestione persistenza
Data Grid > Distributed Cache
• Diverse Topologie
• Querying
• Task Execution e Map/Reduce
• Partition Handling
• 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
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 configurazione
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: ha senso 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
• Nota: nessuna relazione con la virtualizzazione :)
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
DEMO Time: Consistent Hashing
• Abilitando il Partition Handling, quando il JDG “sospetta” uno split brain, le partizioni possono entrare in “Degraded mode”
• Una partizione in Degraded mode può leggere/scrivere solo le chiavi che sono “fully owned”,
• Le richieste per chiavi che non sono “fully owned” risulteranno in una Availability Exception
• Il Partition Handling è disponibile sia in Library mode che in Client/Server mode
Partition Handling
• Cache Store
• Non solo in memoria!
• Write through e write behind (ACK sincrono o asincrono)
• Pluggable “drivers” per diversi store
• File System, JPA, LevelDB (supported)
• MongoDB, Cassandra, BerkeleyDB, ecc. (community)
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)
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
Expiry dei dati
Eviction/Expiry: differenze
• Tutte e due le tecniche evitano gli Out Of Memory
• I dati “Evicted” a differenza di quelli “Expired” possono essere mantenuti nel Grid per usi futuri con la Passivazione
• Eviction è una configurazione per “cache”, Expiration per dato (e dunque globale)
• Expiration è una caratteristica di business, Eviction una di sistema
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 API
Listeners / Notifications
• Capacità di ricevere eventi
• A livello di Cache o di CacheManager
• Cambio di topologia
• Aggiunta/Rimozione/Modifica di oggetti (cluster wide ed anche su Hotrod)
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
Map / Reduce
• Prossimamente Infinispan/JDG sarà utilizzabile come Hadoop store
• Implementerà le api HDFS
• Coming soon… in JDG 7
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
Standardizzazione API
• JSR-107
• Java Temporary Caching API
• Confermato a Gennaio 2015
• In roadmap per JDG 6.5
• JSR-347
• Data Grids for the Java Platform
• JSR Ritirato a Gennaio 2015
Management Tooling
• Infinispan Command Line Console
• JMX
• RHQ/JON Plugin
• Hawt.io plugin (si, la stessa console di Fuse :) )
• Side Cache
• Inline Cache
• Compute Grid
Data Grid Usage Patterns
• In una side cache, è l’applicazione che gestisce direttamente la cache e lo store principale
• Esempio: accesso alla cache, se K non è presente l’applicazione effettua una richiesta al DB e poi inserisce K
Side cache
• In una inline cache, l’applicazione dialoga solo con la cache
• La cache ha uno store configurato via Cache Store
• Esempio: accesso alla cache, se K non è presente la cache stessa chiede al DB ed inserisce K
Inline cache
• Cache distribuita
• Utilizzo della griglia per sottomettere Distributed Task e/o Map/Reduce
• Possibilità di processare terabyte di dati molto velocemente
• multiple nodes, multiple cores, “piccoli” set di dati per ogni nodo
Compute Grid
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
• 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 QueryingCluster
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 QueryingCluster
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
DEMO Time: Advanced features
Data Security
• User Authentication• SASL
• Role Based Access Control (RBAC)• Utenti, Ruoli e mapping fra ruoli ed operazioni su Cache e
Cache-Manager• Node authentication & Authorisation• Evitare che nodi “malevoli” possano fare join del cluster
• Encrypted communication fra i nodi del cluster
Supporto Enterprise per JDG 6.4
Supported JDK
• Oracle,OpenJDK ed IBM JDK• 1.6, 1.7 ed 1.8
• Azul ZVM• 14.09
Container supportati (Library Mode)
Container supportati (Client/Server)
More details…
• Molti Database relazionali (Oracle, DB2, ecc.)• Modulo camel-jbossdatagrid per Fuse 6.1• Modulo infinispan-spring3 (Spring 3.2.9)• Modulo infinispan-spring4 (Spring 4.1.0)
https://access.redhat.com/articles/115883
Chi usa
?
Chi usa i Data Grids?• Chiunque abbia bisogno di:
• massive data volumes
• high transactional throughput
• strict performance characteristics
• uptime elevati
• offloading DB (anche per risparmi su licensing)
Chi usa i Data Grids?
• Telco
• Real-time, Global routing, tracking information: geolocation, user data, user authorization, ecc.
• Retail
• Cataloghi Online per milioni di utenti concorrenti (user tracking, user personalization, listini, sconti, promozioni, ecc.)
Chi usa i Data Grids?
• Transportation and logistics
• Real-time, Global routing, tracking information: geolocation, delivery priority, routing, ecc.
• Financial Services
• Stock Trading simulations
Chi usa i Data Grids?
• Media and entertainment
• Gaming online, On-demand streaming video, user data
• Generic offloading
• Diminuire workload dei Database (e costi di licenza)
Chi usa i Data Grids?• Telco: caso d’uso di Softbank in Giappone
• Inline cache
• circa 300 nodi di JDG con 64GB ciascuno
• 500 diverse cache
• 50% heap, circa 10 TB di dati online
• prossimo upgrade a 500 nodi (16 TB)
Corso di formazione JB453
• Corso specifico per sviluppatori JBoss Data Grid (Gennaio 2015)
• ILT (Instructor Led Training)
• https://www.redhat.com/it/services/training/jb453-red-hat-jboss-data-grid-development
Link e risorseJDG JBoss Data Grid • Product page: http://www.redhat.com/products/jbossenterprisemiddleware/data-grid/
• JDG JB 453https://www.redhat.com/it/services/training/jb453-red-hat-jboss-data-grid-development
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
top related