Infinispan/JDG (JBoss Data Grid) Tech Lab.

1. JBoss
Data Grid
Tech Lab
Ugo Landini
Solution Architect, Red Hat
versione 1.7
29 Jan 2014

3. Agenda
• NoSQL: introduzione
• Consistent Hashing e CAP Theorem
• Cos’è un Data Grid
• Infinispan/JDG features

4. Big Data
new 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

5. NoSQL
Not Only SQL.
Definizione A: un sistema di storage
alternativo ad un RDBMS
Definizione B: un qualsiasi sistema
utilizzato in alternativa ad un RDBMS

6. Eventi chiave
• Google BigTable (2005, sviluppi iniziati nel
2004)
• Amazon rilascia il paper con il design di
Dynamo (2007)

7. NoSQL
• K/V Store
• Document Store
• Column based DB
• Graph DB
• ma anche XML, Object DB,
Multidimensional, Grid/Cloud, …

8. “Classic” NoSQL
MongoDB CouchDB Redis Riak Infinispan LevelDB Voldemort Neo4J BigTable HBase Cassandra
Elastic
Search
Document
K/V
Column
Oriented
Graph

9. Grid & Cloud NoSQL
Infinispan/
JDG
Coherence Gemfire HazelCast Gigaspaces
Grid & Cloud

10. NoSQL
• Impossibile categorizzare in maniera
sistematica
• Moltissime sfumature
• Molti casi di “Convergenza Evolutiva”

11. CAP Theorem

12. CAP Theorem
• Tre caratteristiche di un Sistema Distribuito
• Consistency
• Availability
• Partition Tolerance

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

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

15. Partition Tolerance
• Il sistema è in grado di continuare ad
operare in caso di perdita di connettività
fra i nodi (es: split brain)

16. CAP Theorem

17. 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

18. 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

19. 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

20. 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

21. 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

22. Storia di
un’applicazione

23. Architettura con DB
tradizionale

24. 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”

25. Come i programmatori risolvono
il problema: local caching
Node
RDBMS
1. read A
A
client 1
VM1
cache
2. write A to cache3. reads A

26. Local caching
• Non scala al “livello successivo”
• poca memoria
• no HA

27. Local caching distribuito

28. Local caching distribuito
• Local caching distribuito su più nodi
• Gestione dei Dirty reads? (multiple writes,
invalidation, ecc.)
• Gestione del Write behind?

29. “Clustering” della cache

30. “Clustering” della cache
• Cache topology influisce sui client
• Startup time che aumentano
• start della cache, transfer state
• JVM tunings incompatibili
• GC
• Non JVM clients

31. Cache servers
RDBMS
cache
VM
client 1
VM
client 2
VM
client 3
VM
cache
VM
1. Write
2. Update Cache
3. Read
cluster

32. Cache servers
• Protocolli
• open o proprietari
• Transazionalità
• Topologie: replica totale o dati distribuiti
• Smart routing

33. Consistent Hashing

34. 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)

38. Cos’è un Data Grid?

39. Cos’è un Data Grid?
• Motore per gestione di storage in memoria
• “Networked memory”
• Storage distribuito
• Una distributed cache “on steroids”
• Un NoSQL Transazionale

40. Perchè un Datagrid?
• Scalabilità superiore
• Minore latenza
• Ma…
• ... tecnologia nuova da imparare
• ... migrazione applicazioni

41. 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

42. 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

44. 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

45. 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

46. Esempi di topologie

47. Distributed senza replica

48. Distributed con una replica
sync

49. Distributed con una replica
async

50. Replicated

51. 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

52. 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

53. Consistent Hashing in
Infinispan
• Self healing
• No single point of failure
• Highly concurrent
• MVCC locking

54. 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

55. 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

56. 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 :)

57. 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

58. 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

59. 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

60. DEMO Time:
Consistent Hashing

61. • 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

62. • 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

63. Eviction dei dati
• Evita al sistema degli Out Of Memory
• Le entry possono anche essere “passivate” su
disco (in diverse modalità, vedi CacheStore)

64. Eviction dei dati
• Evita al sistema degli Out Of Memory
• Le entry possono anche essere “passivate” su
disco (in diverse modalità, vedi CacheStore)

65. 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

66. Expiry dei dati

67. 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

68. 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

69. 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)

70. 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

71. 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)

72. Map / Reduce

73. Map / Reduce

74. Map / Reduce
• Prossimamente Infinispan/JDG sarà
utilizzabile come Hadoop store
• Implementerà le api HDFS
• Coming soon… in JDG 7

75. 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

76. Cross Site Replication

77. Cross Site Replication
• Architetture Follow the Sun
• Permette di avere più Cluster che si
sincronizzano fra loro
• In sync o async

78. 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

79. Management Tooling
• Infinispan Command Line Console
• JMX
• RHQ/JON Plugin
• Hawt.io plugin (si, la stessa console di
Fuse :) )

80. • Side Cache
• Inline Cache
• Compute Grid
Data Grid Usage
Patterns

81. • 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

82. • 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

83. • 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

84. Modi di utilizzo
• Embedded mode / Library mode
• Direttamente dalla JVM
• Client/Server mode
• REST
• Memcached
• Hot Rod

85. Library Mode

86. 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

87. Client/Server mode
Protocolli
supportati
• REST
• Memcached
• Hot Rod

88. • 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

89. REST
• Utile per client non Java per i quali non
esista un protocollo
• HTTP Transport: Firewall friendly
• E’ ovviamente più lento delle alternative

90. 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

91. Hot Rod
• Wire protocol per
comunicazioni client server
• Open Source
• Language independent
• Built-in failover e load
balancing
• Smart routing

92. Confronto protocolli
Protocol
Client
Libs
Smart
Routing
Load
Balancing/
Failover
TX Listeners M/R Dist Querying
Cluster
separato
Library
mode
inVM N/A Yes Dinamico Yes Yes Yes Yes Yes No
REST Text HTTP No
Qualsiasi
HTTP load
balancer
No No No No No Yes
Memcached Text Molte No
Solo con
predefined
server list
No No No No No Yes
Hot Rod Binary
Java/
Python/
C++
Yes Dinamico
Locali con
MVCC
Yes (6.4) No No Yes (6.3) Yes

93. Confronto protocolli
Protocol
Client
Libs
Smart
Routing
Load
Balancing/
Failover
TX Listeners M/R Dist Querying
Cluster
separato
Library
mode
inVM N/A Yes Dinamico Yes Yes Yes Yes Yes No
REST Text HTTP No
Qualsiasi
HTTP load
balancer
No No No No No Yes
Memcached Text Molte No
Solo con
predefined
server list
No No No No No Yes
Hot Rod Binary
Java/
Python/
C++
Yes Dinamico
Locali con
MVCC
Yes (6.4) No No Yes (6.3) Yes
Esempio di ciclo virtuoso OSS

94. DEMO Time:
Advanced features

95. 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

96. Supporto Enterprise
per JDG 6.4

97. Supported JDK
• Oracle,OpenJDK ed IBM JDK
• 1.6, 1.7 ed 1.8
• Azul ZVM
• 14.09

98. Container supportati
(Library Mode)

99. Container supportati
(Client/Server)

100. 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

101. Chi usa
?

102. 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)

103. 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.)

104. Chi usa i Data Grids?
• Transportation and logistics
• Real-time, Global routing, tracking
information: geolocation, delivery priority,
routing, ecc.
• Financial Services
• Stock Trading simulations

105. 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)

106. 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)

107. 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

108. Link e risorse
JDG JBoss Data Grid
• Product page:
http://www.redhat.com/products/jbossenterprisemiddleware/data-grid/
• JDG JB 453
https://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