java - H2和其他内存数据库专家的挑战

Question

我有一个有趣的场景，我相信，这是imdb（比如H2）的一个优秀应用，而且可能还有jOOQ。然而，也出现了一些有趣的挑战和问题。
我们开发了一个专门的、基于java的etl平台，用于保险数据转换，现在已经进入第四代。在不涉及不必要的细节的情况下，我们通常从源系统（如sql server、db2等）中提取不同程度规范化的数据。保险数据转换有两个与此高度相关的特征：
我们通常一次转换一个保险实体（即保单、申请、索赔等）（除非它是包或其他事务分组的一部分，在这种情况下，我们可能一次转换几个实体）。因此，重要的是，给定的转换事务一次很少涉及甚至1 MB的数据。事实上，一个典型的事务只涉及不到5万个数据，而这些数据以任何现代衡量都是微不足道的。
由于源系统和目标系统在模式、粒度甚至底层语义上的差异非常大，因此转换可能非常复杂。在源代码处理方面，查询数量众多且复杂，经常连接多个表，使用子查询等，因此，获得合理的性能意味着以某种方式保存查询结果。到目前为止，我们还依赖于一种涉及“保险地图”的专有方法，这是一种专门的Java地图。我们知道这种方法最终是不够的，但它最初满足了我们的需要。
现在我有时间思考，我正在考虑一个长期的方法。如果我们只考虑上述基本特性，那么像h2这样的imdb似乎是完美的：
预先对源数据库（如SQL Server）执行所有复杂查询，创建表，执行插入/更新，以便创建与单个转换事务（如单个保险单）相关的所有数据的IMDB表示。顺便说一句，我可以看到jooq在这里（和其他地方）对于简化和提高这些查询的类型安全性有多大帮助。
对imdb执行所有复杂的转换查询。同样，jooq可能会有显著的好处。
为每个保险转换事务丢弃并重新创建imdb。
我喜欢这种方法（至少在h2中是这样）的一个地方是，在基于java的存储过程中封装查询的能力比编写t-sql存储过程要好得多。它是否会再次使对imdb使用jooq而不是本机h2存储的proc api变得更容易/更安全？
不过，我有两个担心：
序列化——这实际上是一个分布式平台（为了便于讨论，我已经简化了上面的描述），我们大量使用服务和消息队列来传递/排队数据。当我们处理XML数据源时，这一切都非常有效，这是经常发生的情况。这对imdb有多好？对于给定的保险事务imdb，我们必须能够a）序列化imdb，b）传输和/或排队imdb，最后，c）将数据反序列化回完全运行的imdb以进行转换处理。例如，对h2执行此操作的最佳方法是使用sql脚本命令序列化数据，然后运行脚本反序列化数据。我想知道这种方法的性能特点。我不认为我们的平台对性能特别敏感，但我确实希望避免一种特别缓慢或架构上很尴尬的方法。
目标加载这个讨论集中在源端数据库处理上，因为我们经常在目标端生成xml（为此我们有成熟的子系统）。然而，有时我们也需要直接处理目标端的数据库。在这种情况下，我们必须能够根据转换后的数据直接插入/更新主流关系数据库。我正在考虑的方法再次使用imdb，但在目标端。转换后的数据使用与实际目标数据库相同的架构填充imdb。然后，这个目标imdb可以序列化并根据需要传输。最后，目标imdb的内容将用于插入/更新实际的目标数据库（当然，目标数据库可能有许多千兆字节的数据）。如果我可以对imdb使用一个简单的sql脚本语句来生成一个包含insert/update语句的脚本，然后就可以对目标数据库运行这个脚本，那将是非常了不起的（但我并不乐观）。我想不会那么容易。无论如何，这种目标装载的一般方法合理吗？
我对这篇文章的篇幅表示歉意，但对于我们的团队来说，这是一个非常重要的问题。非常感谢您的回复。

Answer 1

有点离题…需要记住的一点是，h2是非分布式数据库，因此充其量是一个相当原始的解决方案。从本质上说，这是一个非常适合单jvm的堆上数据库。有更好的方法，除非你在谈论绝对简单的用例（我不认为你是这样）。
例如，GridGain的内存数据库在内部使用H2进行SQL处理（具有所有优点），但也提供了SQL的完整发行版以及许多其他特性。还有其他分布在内存中的数据库，甚至一些复杂的数据网格，可以适合您的用例。
只有我的2美分。