I am putting together a regular Java EE application on jboss7 that will use JPA in the data tier. I would like to make this application such that it scales up with load. While it is pretty clear how to scale up the web tier: create more machines and throw them behind a load balancer, scaling up the data tier is less so.
I can probably cluster my database (MySQL). Stil, that leaves the JPA layer unclustered. Ideally, JPA will scale up by using in (clustered) memory caching backed by MySQL.
When I look around, all information around JPA scaling seems to be 3-4 years old. People talk about ehcache, memcached and infinispan. I am not sure if this is still current.
Can someone tell me the state of the art in Java EE clustering and scaling, especially in the data tier.
Various caching strategies are still the way to scale JPA/Hibernate (you basically named the most popular options in your question). Nothing extraordinary happend since 4-5 years in this field, as far as I know. One more option you haven't mentioned is JBoss Cache. So the Second Level Cache for JPA/Hibernate still rules in this area.
Why no progress here? My wild guess is that first of all people, who need scalable application tend to ignore JPA and Hibernate in areas where high performance is needed. Usually people go with SQL dressed in Spring Framework JDBCTemplate helpers and transaction management. Then scalability is the matter of database capabilities in this area.
The other trend is to use No-SQL databases. There is plany of solutions: MongoDB, CouchoDB, Cassandra, Redis, to name a few. These are usually Google BigTable like key-value storages (this is oversimplification, but it is more or less the idea behind that approach) and they scale as hell, if you accept their limitations (relations are no longer managed easily, etc.).
There are many solutions, the two main categories of solutions are:
scaling the database
using a clustered cache to reduce database load
EclipseLink supports data partitioning for sharding data across a set of database instances,
see:
http://java-persistence-performance.blogspot.com/2011/05/data-partitioning-scaling-database.html
You can also use MySQL Cluster,
see:
http://www.mysql.com/products/cluster/
Oracle TopLink Grid provides EclipseLink JPA support for integration with Oracle Coherence as a distributed cache,
see:
http://www.oracle.com/technetwork/middleware/ias/tl-grid-097210.html
EclipseLink's cache supports clustering through cache coordination,
see:
http://wiki.eclipse.org/EclipseLink/Examples/JPA/CacheCoordination
Related
We have a solution which uses the Apache Ignite-provided In-Memory Data Grid as a distributed cache. For newer projects, we ended up using Spring, and as such we wished homogenize our software ecosystem and using Spring for the first solution as well. In addition, we do not use all the features of Ignite to excuse its use (discovery, caching).
Since we currently only use a limited subset of features from Ignite, we are basically looking for a self-managed application-level distributed cache solution (similar to what Ignite provides). This means that dedicated caching infrastructure like Redis, Memcached, etc. is not what we want.
I've researched the topic somewhat and found that there are some possible alternatives like:
Tayzgrid - Last update seems to be quite some time ago, not sure if still actively maintained
Druid - Still incubating, and I have also read that new releases being somewhat broken was not that uncommon
Hazelcast - Seems like the best choice given its maturity and the existence of Spring Data Hazelcast, though I am unsure what the level of support is here.
Has anyone has experience with integrating one of the above IMDGs (aside from Ignite) with Spring Cache? Any pointers in the right direction would be greatly appreciated.
You can use Redisson - Redis Java client with features of
In-Memory Data Grid. It also implements Spring Data support. Here is the documentation.
Hazelcast has official support for Spring Data Hazelcast and also this module has many users as now. I can also suggest you to have a look at the resources below:
Using Hazelcast with Spring Data
Getting Started with Microservices Using Hazelcast IMDG and Spring Boot
I have worked on spring cahing using ehcache . To me it is like same with different set of API exposed and their implementation.
What's the difference in terms of features provided between them
apart from API/implementation ?
Update:- I have already seen Hibernate EHCache vs MemCache but that question is mainly from hibernate perspective but my question is in general for any caching service . Answer to that question also states there is not much difference in terms of features
Aside from the API differences you noted, the major difference here is going to be that memcached lives in a different process while Ehcache is internal to the JVM - unless configured to store on disk or in a cluster.
This mainly means that with Memcached you always need a serialized version of your objects and you always interact with a different process, remote or not.
Ehcache, and other JVM based caching solutions, start with a on-heap based cache initially which allows lookups to be simply about handling references to your Java objects.
Of course this means that the objects keep living in the Java heap, increasing memory pressure. In the case of Ehcache 3.x you have the option to move to offheap memory and more, allowing to grow the cache without impacting JVM heap.
At this point, the benefit of Memcached may be that you want non Java clients to access it.
And the final decision really is in your hands. Caches are consuming memory to provide reduced latency. What works for you may be different than what works for others. You have to measure and decide.
I need to cache different user and application data on a daily basis.
Context:
no experience with caches
working on a java web application that sends news articles to users displayed in a user-feed format
MySQL backend
Java middle tier using Hibernate and Jersey
I've checked out different cache technologies, and it seems like Memcached or Redis are the most used technologies in use cases similar to mine -- many reads and writes i.e. Facebook, Twitter, etc.
But I have to serialize objects before I cache them using the two above cache systems. It seemed like an unnecessary step to cache just a POJO, so I checked out POJO caches and stumbled upon JBOSS's Infinispan.
Does anyone have any good reasons why I shouldn't use Infinispan over Memcached or Redis over the serialization, and subsequent deserialization, overhead concern?
When Infinispan works in clustered mode, or when it has to offload data to external stores, it will have to face Serialization.
The good news is:
- you'll avoid any serialization costs unless it has to go somewhere else
- its own serialization mechanism is far more efficient than Java's standard serialization mechanism (and nicely customizable)
Memcached and Redis are "external" caching solutions, while with Infinispan you can keep the same Java instance cached. If this is a good or bad thing depends on your architecture specifics.
Although commonly you'll want to use a hybrid solution: use Infinispan for your in-JVM needs, cap its memory usage, have it offload what can't be fit locally to an external store, and it's easy to have it offload the extra stuff to either Redis, Memcached, another Infinispan cluster, or several other alternatives.
Your benefit is transparent integration with some popular frameworks (i.e. Hibernate) and that it can handle the serialization efficiently for you - if and when it's needed as it might need to happen in background.
Is it sensible to use Spring in the server side of an in memory data grid based application?
My gut feeling tells me that it is nonsense in a low latency high performance system. A colleague of mine is insisting on including Spring in it. What are the pros and cons of such inclusion?
My position is that Spring is OK to be used in the client but it is too heavy for the server, it brings too many dependancies and is one more leaky abstraction to think of.
Data Grid systems are memory and I/O intensive in general. Using Spring does not affect that (you may argue that Spring creates a lot of beans but with proper Garbage Collection tuning this is not a problem).
On the other hand using Spring (or any other DI) helps you structure and test your code.
So if you are using implementing some sort of server based on Data Grid systems, pay attention to properly adjusting GC, sockets in your OS (memory buffers and socket memories). Those will give you much more benefits than cutting down DI.
First, I'm surprised by the "leaky abstraction" comment. I've never heard anyone criticize Spring for this. In fact, it's just the opposite. Spring removes the implementation details of infrastructure such as data grids from your application code and provides a consistent and familiar programming model, allowing you to focus on business logic. Spring does a lot to enhance configuration and access to data grids, especially Gemfire, and generally does not create any runtime overhead per se. During initialization of a Spring application, Spring uses tools like reflection and AOP internally which may increase the start up time of an application, but this has no impact on runtime performance. Spring has been proven in many high-throughput, low-latency production applications. In extreme cases, things like network latency and serialization, concerns external to Spring, are normally the biggest factors affecting performance.
"Spring brings in too many dependencies" is a common complaint, but is a fallacy. I would say Spring brings in the exact right amount of dependencies for what it needs to do. Additionally, Spring Boot starters and the platform BOM do a lot to simplify dependency management so you don't need to worry about version incompatibilities or explicitly declaring common dependencies. I'll have to side with your colleague on this one.
I have not used Spring Data before but I've used Hibernate ORM a number of times for MySQL based application. I just don't understand which framework to choose between the two for a MongoDB based application.
I've tried searching for the answer but I can't find the answer which does a comparison between the two in a production environment. Has anyone found problems working with these two frameworks with MongoDB ?
Disclaimer: I am the lead of the Spring Data project, so I'll mostly cover the Spring Data side of things here:
I think the core distinction between the two projects is that the Hibernate OGM team chose to center their efforts around the JPA while the Spring Data team explicitly did not. The reasons are as follows:
JPA is an inherently relational API. The first two sentences of the spec state, that it's an API for object-relational mapping. This is also embodied in core themes of the API: it talks about tables, columns, joins, transactions. Concepts that are not necessarily transferable into the NoSQL world.
You usually choose a NoSQL store because of its special traits (e.g. geospatial queries on MongoDB, being able to execute graph traversals for Neo4j). None of them are (and will be) available in JPA, hence you'll need to provide proprietary extensions anyway.
Even worse, JPA features concepts that will simply guide users into wrong directions if they assume them to work on a NoSQL store like they were defined in JPA: how should a transaction rollback be implemented reasonably on top of a MongoDB?
So with Spring Data, we chose to rather provide a consistent programming model for the supported stores but not try to force everything into a single over-abstracting API: you get the well-known template implementations, you get the repository abstraction, which works identical for all stores but lets you leverage store-specific features and concepts.
Disclaimer: I'm one of the Hibernate OGM developers so I'll try to provide some of the reasons behind it.
Hibernate OGM provides Java Persistence (JPA) support for NoSQL solutions. It reuses Hibernate ORM’s engine but persists entities into a NoSQL datastore instead of a relational database. It also aims to provide access to specific datastore features when JPA does not have a good fit.
This approach is interesting for several reasons:
Known semantic and APIs. Java developers are already familiar with JPA, this means that one won't have to learn lower level API. It also supports both HQL and native backend-queries.
Late backend choice. Choosing the right NoSQL datastore is not trivial. With Hibernate OGM you won't have to commit to a specific NoSQL solution and you will be able to switch and tests different backends easily.
Existing tools and libraries. JPA and Hibernate ORM have been around for a while and you will be able to reuse libraries and tools that uses them underneath.
Most of JPA logical model fits. An example of a good fit is #Embedded, #EmbeddedCollection and #Entity (that can be a node, document or cache based on the datastore of choice). Admittedly, annotation names might be strange because you will also have to deal with #Table and #Column.
JPA abstracts persistence at the object level, leaving room for a lot of tricks and optimizations. We have several ideas planned, like polyglot persistence: storing data in several data stores and use the best one for a specific read job.
The main drawback is that some of the concepts of JPA are not easily mapped to the NoSQL world: transactions for example. While you will have access to transaction demarcation methods, you won't be able to rollback on data stores that don't support transactions natively (transactions, in this case, will be used to group operations and try to optimize the number of calls to the db).
Also, if your dataset is by nature non domain model centric, then Hibernate OGM is not for you.
One can Just go with SpringData. If you recall Spring ORM also uses some JPA things such as Entity, Transaction and provided best commination of things from JPA and Hibernate APIs a. Spring community will take care in future versions if JPA is getting more matured for NoSQL.
Though it is not the main reason. Most of reasons are described by #Oliver Drotbohm.
Read more documentation of SprinData and further analyse your data model, scalability on continuity/growth of data store, find best fit for your solution and consider suggestion given by #Davide.
Many cases SpringData has got more success rate than JPA while integrating with MongoDB.