NoSQL 还是 Ehcache 缓存？
我正在使用 Spring/Hibernate/Tomcat 和 mysql 数据库构建一个路线规划器 Web 应用程序， 我有一个包含只读数据的数据库，例如公交车站坐标、公交车时间，这些数据从未更新。我试图让应用程序运行得更快，每次运行应用程序时，它都会对数据库执行大约 1000 次读取来计算路线。
我设置了一个 Ehcache，它极大地提高了从数据库读取的时间。 我现在正在设置 terracotta + Ehcache 分布式缓存以与多个 Tomcat JVM 共享缓存。这似乎有点复杂。我尝试过 memcached，但它的执行速度不如 ehcache。
我想知道 MongoDb 还是 Redis 是否更适合。我没有使用 nosql 的经验，但如果有人有任何想法，我将不胜感激。我需要的是快速访问只读数据库。
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 to 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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
由于您的数据是只读的，我想说您可以没有 分布式和复制缓存< /a>，除非缓存初始加载的开销那么关键（在这种情况下，配置 Ehcache 并不难，你只需要知道你去了哪里）。因此，如果您认为确实需要这个，也许可以请求更具体的指导。
首先，如果您采用 NoSQL 方式，请忘记 Hibernate（不过可能不是问题）。其次，我真的想知道什么更复杂：（不是）将 Ehcache 配置为分布式（我仍然不相信你需要它）或改变你的方法以实现完全不同的东西（绝大多数企业业务不需要） 。第三，在同一个 JVM 中没有什么比从内存中读取数据更快的了。
总结一下：我会 1. 考虑不使用分布式缓存（并告别配置问题）或 2. 配置 Ehcache 进行分布式缓存（我认为这比改变整个方法要简单）。
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.
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).
如果您想尝试路由，您甚至可以查看 Neo4j，请参阅 关于使用 A* 算法的博客
if you want to try routing, you even might look at Neo4j, see the blog on using an A* algo for
首先，mongodb 本身并不是缓存。它是一个持久数据存储，就像 mysql 是一个持久数据存储一样。
所以现在你的问题归结为“我应该使用ehcache还是redis”。使用 ehcache 后，我可以告诉您，对于具有复制/集群、缓存失效、监控和检测功能的分布式缓存来说，这是一个非常好的解决方案。
由于您的数据是只读的，因此像 hazelcast 这样的简单分布式地图也可以工作。使用起来非常简单。
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.