H2数据库适合作为大表的嵌入式数据库吗？

Question

我们的应用程序目前使用 H2 作为嵌入式数据库，我们有以下场景：

H2 用作“临时数据库”。插入到 H2 中的数据每 30 分钟由应用程序任务定期发送/插入到 Oracle 数据库（“官方”数据库），并从 H2 中删除；
这个主要的“临时表”在一个表中平均每小时插入 183 行。
我们还有另外两个大表（分别有 2100 万和 150 万条记录），主要用于查询。还有另一个应用程序任务从 Oracle 增量更新这些表，更新自上次同步以来在 Oracle 中创建/更新/删除的 H2 行。它也每 30 分钟发生一次。

到目前为止，我们已经使用 H2 1.5 年了，没有出现任何问题，但我们在Red Hat 官方文档中发现了以下关于 H2 的警告：

但是，它不应在生产环境中使用。它是一个非常小的、自包含的数据源，支持测试和构建应用程序所需的所有标准，但对于生产使用来说不够健壮或可扩展。

在这样的场景中，H2 是否设计并可靠地用于生产环境？

是否有任何基准支持这一点？该H2正式性能基准测试显示执行时间和性能的使用，但不要说有关数据量什么。

Answer 1

嵌入式 H2 数据库是内存中的还是持久化的？我主要关心的是故障转移。如果您的 JVM 出现故障，您将丢失自上一个 Oracle 同步点以来的所有数据。

除此之外，嵌入式 H2 数据库只能在与您的应用程序相同的 JVM 中使用。因此，您将无法扩展到具有多个 JVM 的高可用性架构，每个 JVM 将拥有自己的 H2 数据库，您将无法跨 JVM 共享该数据。

最后，还有堆的问题。如果您使用的是内存 JVM，那么您的堆将随着数据量的增加而增长，并且最终您可能会耗尽 RAM 并导致抖动，因为垃圾收集器试图阻止您耗尽堆。