NoSQL or Ehcache caching?

I'm building a Route Planner Webapp using Spring/Hibernate/Tomcat and a mysql database, I have a database containing read only data, such as Bus Stop Coordinates, Bus times which is never updated. I'm trying to make the app run faster, each time the application is run it will preform approx 1000 reads to the database t开发者_开发技巧o calculate a route.

I have setup a Ehcache which greatly improves the read from database times. I'm now setting terracotta + Ehcache distributed caching to share the cache with multiple Tomcat JVMs. This seems a bit complicated. I've tried memcached but it was not performing as fast as ehcache.

I'm wondering if a MongoDb or Redis would be better suited. I have no experience with nosql but I would appreciate if anyone has any ideas. What i need is quick access to the read only database.

I have setup a Ehcache which greatly improves the read from database times. I'm now setting terracotta + Ehcache distributed caching to share the cache with multiple Tomcat JVMs. This seems a bit complicated.

Since your data are read-only, I'm tempted to say that you could live without distributed and replicated caching, unless the overhead of the initial load of caches is that critical (and in that case, it is not that hard to configure Ehcache, you just need to know where you go). So, if you think you really need this, maybe ask for more specific guidance.

I'm wondering if a MongoDb or Redis would be better suited. I have no experience with nosql but I would appreciate if anyone has any ideas. What i need is quick access to the read only database.

First of all, if you go the NoSQL way, forget Hibernate (might not be an issue though). Secondly, I really wonder what is more complicated: (not) configuring Ehcache to be distributed (I'm still not convinced you need it) or changing your approach for something radically different (that the VAST majority of enterprise business don't need). Thirdly, nothing will be faster than reading data from memory in the same JVM.

To summarize: I would 1. consider not using distributed caching (and say goodbye to the configuration problem) or 2. configure Ehcache for distributed caching (I think this is less complicated than changing your whole approach).

if you want to try routing, you even might look at Neo4j, see the blog on using an A* algo for

First of all mongodb is not a cache per se. its a persistent data store just like mysql is a persistent data store.

so now your question boils down to "should i use ehcache or redis". having used ehcache i can tell you that is a pretty good solution for a distributed cache that does replication/clustering, cache invalidation, monitoring and instrumentation capability.

since your data is read only, a simple distributed map like hazelcast would work as well. its pretty simple to use.