纯Java替代数据库/用于存储记录的缓存

Question

bounty到期在3天内。该问题的答案有资格获得+ 100声望赏金。Paul Taylor正在寻找来自信誉良好的来源的答案。

在我的Java应用程序中，我开始使用H2数据库存储所有数据。但是该软件必须在某些速度较慢的单个cpu服务器上运行，因此我想减少使用的cpu周期，而我想再次查看的一个领域是数据库。

[在许多情况下，我仅出于将数据保留在堆外的目的而将数据插入数据库，否则会耗尽内存，然后稍后我们检索数据，就不必更新数据了。

所以我考虑使用像ehCache这样的缓存，但这有两个问题：

• 不保证数据不会被丢弃（如果缓存已满）
• 我一次只能检索一个记录，而使用关系数据库可以检索一批记录，这看起来像是一个潜在的瓶颈。

解决这些问题的替代方法是什么？

Answer 1

一些有帮助的想法

1. 您说您正在单个CPU上运行，并且想要检查对H2的替换。因此，H2“消耗”了大量的CPU能力，并且声称该应用程序“缓慢”。但是，如果毕竟是由于磁盘速度慢而不是CPU引起的，数据库将其存储在磁盘上，并且磁盘速度可能会很慢。如果您想检查一下这个理论-将磁盘映射到某个ram后备驱动器（在Linux中，这是一项简单的任务），然后使用相同的CPU再次进行测量。

2. 如果得出结论，对于用例来说，H2确实是CPU密集型的，也许值得花一些时间来优化查询，这比替换数据库便宜得多。

3. 现在，如果您不能继续使用H2，请考虑针对此“仅追加”用例进行了真正优化的Lucene（我了解您拥有“仅追加”流程，因为您说“以后检索数据，我们就不必更新数据了。尽管如此，Lucene还应该有自己的线程来处理索引，所以无论如何都应该有一些CPU开销，但是在这种用例下，Lucene的速度可能会更快。代价是您不会得到“简单”的查询，因为lucene不会实现关系模型（嗯，也许部分是因为它应该更快），特别是您没有JOIN和事务管理。可以从单个表（如RDMBS）中按条件查询，您不必像描述的那样获得“热门”。

Answer 2

从您的问题以及对马克·布拉姆尼克斯的回答中我都理解这一点：

• CPU限制：CPU速度非常慢，解决方案不应占用大量CPU
• 内存限制：并非所有数据都可以在内存中
• 磁盘限制：非常慢的磁盘，解决方案不应从磁盘读取/写入大量数据

这些是非常严格的约束。通常，您将CPU与内存或内存与磁盘进行“交易”。在您的情况下，这些都是约束条件。您提到过您看过ehCache，但是我认为此解决方案（可能还有其他诸如memcached的解决方案）并不比H2轻巧。

您可以尝试的一种解决方案是MappedByteBuffer。此类使文件的某些部分可以在内存中，并在需要时交换这些部分。但这是有代价的，要驯服它并非易事。您将需要编写自己的算法来查找所需的数据。请考虑将其投入使用需要多少时间，而不是一台较大机器的额外成本。有时更好的硬件是解决方案。