5 Reasons to Use a Java Data Grid in Your Application
By
·
·
Interview
Likes
(0)
Likes
There are no likes...yet! 👀
Be the first to like this post!
It looks like you're not logged in.
Sign in to see who liked this post!
Comment
Save
7.1K Views
Join the DZone community and get the full member experience.
Join For FreeIn this post we explore 5 reasons to use a Java Data Grid for caching
Java objects in-memory in your applications. In a later post we will
explore some of the other data grid capabilities, beyond data storage,
that can revolutionize your Java architectures, like on-grid computation
and events.
Memory is Fast
Java Data Grids store Java objects in memory. Memory access is fast with
low latency. So if access to data storage either disk or database is
the primary bottleneck in your application then using a data grid as an
in-memory cache in front of your storage tier will give you a
performance boost.
Scale out your Application Shared State
If you need to share state across JVMs to scale out your application
then using a Java Data Grid rather than a database will increase your
scalability. A typical shared state architecture is shown below, the
application server tier stores shared Java objects in the data grid and
these objects are available to all application server nodes in your
architecture.
Separating the data grid tier from the application server tier has a number of advantages;
- Applications can be redeployed and restarted without losing the shared state
- Data Grid JVMs and Application JVMs can be tuned separately
- State can be shared across multiple different applications.
- Each tier can be scaled horizontally separately depending on work load
Typical use cases for shared state include; PCI compliant storage of
card security codes; In-game state in online games; web session data;
prices and catalogues in ecommerce. Anything that needs low latency
access can be stored in the shared data grid.
High Availability for In-Memory Data
As well as low latency access and scaling out shared state. Java Data
Grids also provide high availability for your in-memory data. When
storing Java objects in a data grid a primary object is stored in one of
the Data Grid JVMs and secondary back up copies of the object are
stored in different Data Grid JVM node, ensuring that if you lose a node
then you don't lose any data.
Clients of the data grid do not need to know where data is to access it so high availability is transparent to your application.
Scale Out In-Memory Data Volumes
Java objects, in data grids, aren't fully replicated across all Data
Grid JVMs but are stored as a primary object and a secondary object.
This means the more Data Grid JVM nodes we add the more JVM heap we have
for storing Java objects in-memory (and remember memory is fast).
For example if we build a Data Grid with 20 JVMs each with 4Gb free heap
(after per JVM overhead) we could theoretically store 80Gb (4 times 20)
of shared Java objects. If we assume we have 1 duplicate for high
availability this cuts our storage in half so we can store 40Gb (.5 time
4 times 20 ) of Java Objects in memory.
Native Integration with JPA
Java Data Grids have native integration with JPA frameworks like TopLink
and Hibernate whereby the Data Grid can act as a second level cache
between JPA and the database. This can give a large performance boost to
your database driven application if latency associated with database
access is a key performance bottleneck.
Data grid
Data (computing)
application
Java (programming language)
Published at DZone with permission of Steve Millidge, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments