为java应用程序缓存只读数据

我有一个数据库，它有大约150K条数据记录，表上有一个主键。每个记录的数据大小将小于1kB。从DB记录构造POJO的处理时间约为1-2秒（有些业务逻辑需要花费太多时间）。这是只读数据。因此，我计划实现数据缓存。我想做的是。在子集中加载数据（每次200条记录），并创建一个线程，该线程将构造POJO并将它们保存在哈希表中。在加载缓存时（当我启动应用程序时），用户将看到等待标志。因为在HashTable中存储数据是一个问题，我将实际将处理后的数据存储到另一个DB表中（将POJO转换为xml）。 我使用第三方API从数据库加载数据。加载记录后，我将加载数据，我将加载加载数据的关联，然后加载顶层找到的关联的关联。这就像载入家谱

我不能使用Hibernate或任何ORM框架，因为我正在使用第三方API加载数据库自带的数据（这是一个产品）。再说一遍，我不认为一次加载数据不是一个大问题

如果有可能微调业务逻辑，我就不会在这里问这个问题

按需缓存数据是一种选择，但我正在尝试看看是否可以做得更好

如果你知道有更好的主意，请告诉我。多谢各位/

如果你知道有更好的主意，请告诉我

是的，修复业务逻辑，使每个记录不需要1到2秒。那是一段可笑的长时间

在执行此操作之前，请对应用程序进行概要分析，以确保导致记录加载缓慢的真正原因是业务逻辑，而不是其他原因。（例如，可能是病理数据结构或数据库问题。）

---

一旦修复了记录加载缓慢的根本原因，缓存只读记录仍然是一个好主意，但您可能不需要预加载缓存。相反，只需按需加载记录。

听起来你是在重新发明轮子。我想用hibernate。除了简化访问数据库的代码外，hibernate还内置了缓存和延迟加载数据，因此它只在您请求时创建对象。因此，您上面描述的很多内容已经准备就绪，您可以集中精力整理您的业务逻辑。我怀疑，一旦您解决了业务逻辑性能问题，就不需要做任何事情，例如复杂的缓存系统和hibernate默认值就足够了。

jdbm有一个很好的持久映射实现（）-这可能有助于您进行本地缓存-这肯定比将POJO序列化为XML并将其写入SQL数据库快得多

---

如果您的数据确实是只读的，那么我认为最好的解决方案是将源数据库视为输入队列，为您的应用程序数据库提供数据。创建一个后台进程（见鬼，一个服务会更好），让它监视源数据库并保持应用程序数据库同步。

正如maximdim在评论中所说，预加载整个过程将花费大量时间。如果您的系统不是很奇怪，那么用户不会同时需要所有数据。只需按需缓存即可。我还建议使用一个已建立的缓存解决方案，例如，它通过DiskStore实现持久性——唯一的问题是，在这种情况下，缓存的内容必须是可序列化的。既然您可以将其打包为XML，我打赌您也可以将其序列化，这应该会更快

---

在过去的一个项目中，为了组装其中一个实体，我们必须查询在非现场大型机中运行的非常繁忙、非常缓慢的服务。我们应用程序的平均响应时间主要由此查询决定。由于我们检索到的数据大多是只读缓存，因此使用EHCache解决了我们的问题。

“有些业务逻辑占用了太多时间”是的！所以用户将等待150K*1秒~=40小时？我真的不喜欢那些建立在提问者没有做显而易见的事情的前提下的答案。虽然我同意每条记录2秒是很长的时间，但可能有一些限制你没有意识到。第三方系统必须被查询，你不能改变，这只是一个例子。@andref-我不在乎你喜欢或不喜欢什么。我会回答我认为合适的问题。冷静点，伙计。别把它当回事。我可能说得不好——对不起，英语不是我的第一语言——我喜欢什么和不喜欢什么真的没人关心。我只是认为，如果我们不猜测提问者，假设每个人都做了功课，讨论会朝着更好、更有成效的方向发展。祝您有个美好的一天。