使用JPA/Toplink批量插入

Question

我有一个通过 HTTP 接口接收消息的 Web 应用程序，例如：

http://server/application?source=123&destination=234&text=hello

此请求包含发送者的 ID、接收者的 ID 和消息的文本。

该消息的处理方式应如下所示：

• 从数据库中查找源和目标的匹配 User 对象，
• 创建对象树：一个包含消息文本字段的 Message 以及两个用于源和目标的 User 对象，
• 以保存该 消息树到数据库。

该树将由我无法触及的其他应用程序加载。

我使用 Oracle 作为后备数据库，并使用 JPA 和 Toplink 来执行数据库处理任务。 如果可能的话，我会留下这些。

无需太多优化，我就可以在我的环境中实现约 30 个请求/秒的吞吐量。 这并不多，我需要每秒约 300 个请求。 因此，我测量了性能瓶颈所在，发现对 em.persist() 的调用占用了大部分时间。 如果我简单地注释掉该行，吞吐量将远远超过 1000 个请求/秒。

我尝试编写一个小型测试应用程序，它使用简单的 JDBC 调用将 100 万条消息保存到同一数据库。 我使用了批处理，这意味着我执行了 100 次插入，然后提交，然后重复执行，直到所有记录都在数据库中。 在这种情况下，我测量了约 500 个请求/秒的吞吐量，这可以满足我的需求。

很明显，我需要在这里优化插入性能。 然而，正如我之前提到的，我想继续使用 JPA 和 Toplink，而不是纯粹的 JDBC。

您知道如何使用 JPA 和 Toplink 创建批量插入吗？ 您能推荐任何其他技术来提高 JPA 持久性能吗？

附加信息：

“请求数/秒”在此表示：请求总数/从测试开始到最后一条记录写入数据库的总时间。

我尝试通过在 servlet 内容和持久器之间创建一个内存队列来异步调用 em.persist()。 对表演有很大帮助。 然而，队列确实增长得非常快，并且应用程序将连续接收约 200 个请求/秒，这对我来说不是一个可接受的解决方案。

在这种解耦方法中，我收集了 100 毫秒的请求，并在提交事务之前对所有收集的项目调用 em.persist()。 EntityManagerFactory 在每个事务之间进行缓存。

Answer 1

您对“请求/秒”的衡量标准是多少？ 换句话说，第 31 个请求会发生什么？ 什么资源被阻止？ 如果是前端/servlet/web部分，可以在另一个线程中运行em.persist()并立即返回吗？

另外，您每次都创建交易吗？ 您是否为每个请求创建 EntityManagerFactory 对象？

Answer 2

您应该与 JPA 接口解耦并使用裸露的 TopLink API。 您可以将要保留的对象放入工作单元中，并按您的计划提交工作单元（同步或异步）。 请注意，em.persist() 的成本之一是整个对象图发生的隐式克隆。 如果您自己 uow.registerObject() 您的两个用户对象，TopLink 将工作得更好，从而节省了它必须执行的身份测试。 所以你最终会得到：

uow=sess.acquireUnitOfWork();
for (job in batch) {
 thingyCl=uow.registerObject(new Thingy());
 user1Cl=uow.registerObject(user1);
 user2Cl=uow.registerObject(user2);
 thingyCl.setUsers(user1Cl,user2Cl);
}
uow.commit();

这是非常老派的 TopLink 顺便说一句；）

请注意，批处理将有很大帮助，因为批处理写入，尤其是带有参数绑定的批处理写入将会启动，对于这个简单的示例来说，可能会有一个非常好的结果。对你的表现影响很大。

其他需要注意的事项：您的测序大小。 在 TopLink 中编写对象所花费的大量时间实际上是从数据库中读取排序信息，尤其是默认值较小的情况（我的序列大小可能有数百甚至更多）。