您是否总是在Hibernate中使用二级缓存,或者您是否首先尝试使用它,并且仅在性能下降时才使用它?
答案 0 :(得分:8)
让它先工作,然后快速完成。如果您不需要缓存,请不要实现它。
答案 1 :(得分:3)
在我曾经使用的应用程序中,数据库在多个应用程序之间共享,其中一些应用程序根本不是Java。因此,在这些情况下,二级缓存不适合我,因为我从来不知道其他应用程序何时可以更新数据库。
答案 2 :(得分:2)
我对Hibernate的使用一直是在另一个框架(例如Spring)的上下文中,其中启用缓存几乎是微不足道的。其中一些项目通过ehcache对一些关键域类进行了缓存。
话虽如此,这是我们必须在资源之间进行权衡的另一个领域 - 平衡检索性能与内存使用。没有测量的优化一再被证明是不好的做法。
收集有关应用程序性能的指标。然后决定如何解决慢点问题。缓存可能是您最不担心的问题。
答案 3 :(得分:1)
如果你做的事情正确(谨防选择N + 1等),绝大多数情况下没有二级缓存的表现应该是可以接受的
答案 4 :(得分:1)
我们首先尝试不用,只在性能下降时使用它。
答案 5 :(得分:0)
引用着名的Donald Knuth的话:“程序员浪费了大量的时间来思考或担心程序中非关键部分的速度,而这些效率尝试实际上在考虑调试和维护时会产生很大的负面影响我们应该忘记小的效率,比如大约97%的时间:过早优化是所有邪恶的根源。然而,我们不应该把那个关键的3%的机会放弃。“
如果您看到性能问题,那么您才能开始优化。而且,您应该只优化最大的瓶颈,并在需要时逐步减少。
但是,在大多数情况下,在NHibernate中实现此优化对调试和维护的影响可以忽略不计,并且通常可以通过极少添加代码来实现。
如果您广泛依赖延迟加载,只读表,不必担心不使用NHibernate的应用程序的并发性,性能是一个问题,并且您了解如何使用二级缓存进行优化(意味着您已经知道这个问题的答案),那么你应该使用二级缓存。
答案 6 :(得分:0)
现在有一个与此相关的特定于hibernate的问题。而臭名昭着的LazyInitializationException。基本上,当实体附加到持久化上下文时,您需要初始化所有延迟关联。有两种方法可以做到这一点:
这两种方法会产生完全不同的代码片段,因此将这些代码片段迁移到另一个代码片段可能非常重要。问题是方法1.在不使用二级缓存时导致大量查询,因此人们可以决定使用导致发烧查询的方法2。但是,当您稍后打开第二级缓存时,方法2中的查询不会从缓存中加载数据,而是将结果实体放入其中,从而使查询执行速度比没有缓存时慢。这导致了复杂的事情,比如必须使用查询缓存。
因为这似乎更好地接近我(在这种特殊情况下)首先为所有实体启用缓存,这通常是微不足道的,然后在开发进行时为不需要它的实体禁用它。