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

Question

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

1. 我不能使用Hibernate或任何ORM框架，因为我正在使用第三方API来加载数据库，它自带数据库（它是一个产品）。我不认为一次加载数据不是一个大问题。
2. 如果有可能微调业务逻辑，我不会在这里问这个问题。

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

建议我，如果你有更好的想法，你知道。谢谢./

Answer 1

  

建议我，如果你有更好的想法，你知道。

是的，修复业务逻辑，使每条记录不需要1到2秒。这是一个非常漫长的时间。

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

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

Answer 2

听起来你正在重新发明轮子。我想要使​​用hibernate。除了简化访问数据库的代码之外，hibernate还具有内置缓存和延迟加载数据，因此它只在您请求时创建对象。因此，您上面描述的很多内容已经到位，您可以专注于整理您的业务逻辑。我怀疑一旦你解决了业务逻辑性能问题，就没有必要做复杂的缓存系统和hibernate默认就足够了。

Answer 3

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

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

Answer 4

jdbm有一个漂亮的，持久的地图实现（http://code.google.com/p/jdbm2/） - 可以帮助你进行本地缓存 - 它肯定比将POJO序列化为XML并将它们写回SQL数据库要快得多。 / p>

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