Parleys.com Search Index |
|||
|
|||
|
Title: In-Memory Data Grids (Part 1/2)
Description: In-memory data grids are far from a silver bullet. We will also discuss the downsides, the challenges, and the comparison with other NoSQL solutions. Although the general architectural principles we will present are applicable to most products on the market (commercial and open source), the examples and demos will be focused on Infinispan, the in-memory data grid from JBoss. This open source product is in a way the successor of JBoss Cache, and the development roadmap looks very promising with a distributed execution framework and Object/Grid Mapping (OGM) under active development for version 5. Speaker(s): Johan Andries Keyword(s): Infinispan caching nosql JBoss Slide Content: 0) Our BeJUG Sponsors 1) In-Memory Data Grids Johan Andries Leuven, 15-09-2011 2) Agenda · · · · · · · Examples Caching Distributed Caching -> demo Clouds, NoSQL, CAP and DDD Querying Distributed ExecuKon -> demo OGM 3) Matching 4) CV Offered: · Language skills (NL,EN) · Diplomas (Master) · Driver license (B) · Experience (8 years) · CerKficates (SCJP, ...) Vacancy Offered: · Job (Java Developer) · Region (Leuven) · Regime (full-Kme) Wanted: · Job (Java Developer) · Region (Brussels) · Regime (part-Kme) ? Wanted: · Language skills (EN,FR) · Diploma (Bachelor) · Driver license (B) · Experience (5 years) 5) Balance and TransacKon ReporKng End-of-Day Statements Book Balance CalculaKon Value Balance CalculaKon 6) "Caching has tradiKonally been added to enterprise applicaKons a^er they fail in producKon rather than planned in the architecture" -- Greg Luck (Ehcache and JSR-107) on InfoQ 7) "Memory is the new disk and disk is the new tape" -- Jim Gray (Microso^ Research) 8) Side Cache ApplicaKon Cache DB or other Back-end 9) Inline Cache ApplicaKon Cache DB or other Back-end 10) Read-through Caching ApplicaKon get(k1) k1 v1 Cache Loader k1 v1 load data for k1 v1 DB or other Back-end 11) Write-through Caching ApplicaKon put(k1, v1) k1 v1 Cache Loader insert/update data for k1 DB or other Back-end 12) Write-behind Caching ApplicaKon put(k1, v1) k1 v1 Cache Loader bulk insert/update data DB or other Back-end 13) Distributed Caching get(k1) Client put(k4,v4') Node 1 Cache ParKKon A k1 v1 k2 v2 Node 2 Cache ParKKon C k5 v5 k6 v6 Node 3 Cache ParKKon B k3 v3 k4 v4 14) Distributed Caching get(k1) Client put(k4,v4') Node 1 ParKKon A k1 k2 v1 v2 Node 2 ParKKon C k5 k6 v1 v6 Node 3 ParKKon B k3 k4 v1 v4 Backup B k3 k4 v1 v4 Backup A k1 k2 v1 v2 Backup C k5 k6 v1 v6 15) Introducing Infinispan · www.infinispan.org · LGPL licensed JBoss project · Replaces JBoss Cache · org.infinispan.Cache 16) Distributed Caching get(k1) Client put(k4,v4') Node 1 ParKKon A k1 k2 v1 v2 Node 2 ParKKon C k5 k6 v1 v6 Node 3 ParKKon B k3 k4 v1 v4 Backup B k3 k4 v1 v4 Backup A k1 k2 v1 v2 Backup C k5 k6 v1 v6 17) Introducing Infinispan · www.infinispan.org · LGPL licensed JBoss project · Replaces JBoss Cache · org.infinispan.Cache 18) Infinispan: Replicated vs Distributed Replicated mode Every key is present on all nodes Limited to the heap of a single JVM Fast reads (in-process) Writes involve network access that increases linearly with #nodes Distributed mode Every key belongs to one and only one node "Unlimited" heap size Reads involve network access most of the Kme (but predictable and constant) Writes involve network access most of the Kme (but predictable and constant) 19) Infinispan embedded versus client/server JVM ApplicaKon Infinispan JGroups JVM ApplicaKon Infinispan Java ApplicaKon Client Python ApplicaKon Client JVM Server Infinispan JGroups JVM Server Infinispan 20) Distributed, Scalable, Fault Tolerant No central coordinator; Easy to setup and operate 21) Distributed, Scalable, Fault Tolerant Horizontally Scalable; Add commodity hardware to get more [throughput | processing | storage] 22) Distributed, Scalable, Fault Tolerant No Single Point of Failure Self-healing 23) Consistent Hashing 2 -1 31 0 Node 1 Node 3 Node 2 30 2 24) Consistent Hashing 2 -1 31 0 Node 1 Node 3 Node 2 30 2 25) Consistent Hashing 2 -1 Node 4 31 0 Node 1 Node 3 Node 2 30 2 26) 27) Cloud CompuKng 1.Offered through a web service interface 2.Pay-as-you-go (CapEx vs. OpEx) 3.Provisioning in minutes or seconds 28) NoSQL Trade-offs Trade in some of the comforKng aspects of transacKons, referenKal integrity (and other constraints), SQL queries in return for affordable scalability, fault tolerance, elasKcity, operaKonal simplicity 29) CAP Theorem for distributed systems In case of a communicaKon problem, do you go for Consistency (ACID) or Availability (BASE) 30) BR: no sales orders above 900 ORDERLINES Version 4 6 Unit Price 100 200 # 3 2 Total 300 400 ORDERLINES Version 5 7 Unit Price 100 200 # 4 3 Total 400 600 1000 700 31) Modelling with aggregates (DDD) A funcKonal cluster of objects that are treated as a whole: · business rules and consistency are enforced by the aggregate root · External references to non-root members are not allowed · a natural unit for opKmisKc locking and transacKons |
|||