HyperSQL (HSQLDB)：海量插入性能答案

【问题标题】：HyperSQL (HSQLDB): massive insert performanceHyperSQL (HSQLDB)：海量插入性能
【发布时间】：2012-04-24 07:24:57
【问题描述】：

我有一个应用程序，它必须将大约 1300 万行大约 10 个平均长度的字符串插入嵌入式 HSQLDB。我一直在调整一些东西（批量大小、单线程/多线程、缓存/非缓存表、MVCC 事务、log_size/无日志、定期调用checkpoint，...），在 16 上仍然需要 7 小时核心，12 GB 机器。

我之所以选择 HSQLDB，是因为我认为如果充分利用所有这些内核，我可能会获得显着的性能提升，但我开始怀疑我的决定。

谁能告诉我灵丹妙药？

【问题讨论】：

冒险猜测（不是 HSQLDB 专家）并说主要阻止程序在您的 IO（磁盘）上。
是的，我认为这是因为 CPU 百分比并没有完全超出上限。从多个线程进行批量插入有什么好处，还是在这种情况下我应该坚持使用单个线程？
可能不会，除非您可以实施基于 SSD 的解决方案。

标签： java performance hsqldb bulkinsert

【解决方案1】：

对于 CACHED 表，磁盘 IO 占用了大部分时间。不需要多个线程，因为您正在插入同一个表。显着提高性能的一件事是重用单个参数化 PreparedStatment，为每个行插入设置参数。

在您的机器上，您可以通过对内存映射 IO 使用较大的 NIO 限制来显着提高 IO。例如SET FILES NIO SIZE 8192。较大的尺寸需要 64 位 JVM 才能产生效果。

http://hsqldb.org/doc/2.0/guide/management-chapt.html

要在批量插入期间减少 IO，请使用SET FILES LOG FALSE，并且在插入结束之前不要执行检查点。细节在这里讨论：

http://hsqldb.org/doc/2.0/guide/deployment-chapt.html#dec_bulk_operations

更新：下面 1600 万行的插入测试产生了一个 1.9 GigaByte 的 .data 文件，在平均 2 核处理器和 7200 RPM 磁盘上只花费了几分钟。关键是 NIO 分配量大。

connection time -- 47
complete setup time -- 78 ms
insert time for 16384000 rows -- 384610 ms -- 42598 tps
shutdown time  -- 38109

【讨论】：

这是在什么操作系统上运行的？我发现大批量插入在 OS X 上相当快，在 Windows 上慢得令人沮丧（在各种硬件配置上）。在 2007 年中期的 Mac Mini 上使用库存的内置硬盘插入 108,000 行大约需要 1 分钟。在较新型号的非虚拟化 Windows 服务器上大约需要 15 分钟，而在旧的 2006 年非虚拟 Dell 750 Windows 服务器上需要更长的时间（大约 20 分钟后取消）。
没关系 - 问题原来与索引有关。当我添加索引时，问题就解决了。

【解决方案2】：

检查您的应用程序正在做什么。首先是查看 taskmanager（或特定于操作系统的可比对象）和 visualvm 中的资源利用率。

导致表现不佳的好候选人：

磁盘 IO
垃圾收集器

【讨论】：

【解决方案3】：

H2Database 可能会为您提供比 HSQLDB 稍好的性能（同时保持语法兼容性）。

在任何情况下，您都可能希望尝试使用更高的延迟来同步到磁盘以减少随机访问磁盘 I/O。（即SET WRITE_DELAY <num>）

希望您正在执行批量 INSERT 语句，而不是每行单个插入。如果没有，请尽可能这样做。

根据您的应用程序要求，使用键值对存储可能比使用 RDBMS 更好。（您是否经常需要插入 1.3*10^7 的条目？）

您的主要限制因素将是对磁盘的随机访问操作。我非常怀疑您所做的任何事情都会受 CPU 限制。（看看top，然后和iotop比较！）

【讨论】：

【解决方案4】：

有这么多记录，也许您可以考虑切换到 NoSQL 数据库。当然，这取决于您需要存储的数据的性质/格式。

【讨论】：