HSQLDB SET FILES CACHE ROWS/SIZE 和 SET FILES WRITE DELAY 似乎没有按预期工作

Posted 2023-03-31

【中文标题】HSQLDB SET FILES CACHE ROWS/SIZE 和 SET FILES WRITE DELAY 似乎没有按预期工作

【英文标题】：HSQLDB SET FILES CACHE ROWS/SIZE and SET FILES WRITE DELAY do not seem to work as expected

【发布时间】：2013-04-06 11:31:17

【问题描述】：

我正在使用嵌入式 HSQLDB。 操作系统是 Windows 7。

下面是出现在脚本文件中的SET FILES 属性：

SET FILES WRITE DELAY 500 MILLIS
SET FILES BACKUP INCREMENT TRUE
SET FILES CACHE SIZE 10000
SET FILES CACHE ROWS 50000
SET FILES SCALE 32
SET FILES LOB SCALE 32
SET FILES DEFRAG 0
SET FILES NIO TRUE
SET FILES NIO SIZE 256
SET FILES LOG FALSE
SET FILES LOG SIZE 50

据我了解，数据应该每 500 毫秒写入一次磁盘。另一方面，它应该被缓存在内存中，直到 10MB 或 50,000 行在缓存中。

当我在大约一分钟和 6,000 条记录后查看数据库的目录时，我可以看到：

d:\tmp\test\hsqldb\Run_0>dir
 Le volume dans le lecteur D s’appelle DATA
 Le numéro de série du volume est 3C08-FEE7

 Répertoire de d:\tmp\test\hsqldb\Run_0

06/04/2013  07:10    <REP>          .
06/04/2013  07:10    <REP>          ..
06/04/2013  07:10                32 data.data
06/04/2013  07:10                 0 data.lck
06/04/2013  07:10                 0 data.lobs
06/04/2013  07:10                 0 data.log
06/04/2013  07:10                89 data.properties
06/04/2013  07:10             1,757 data.script
06/04/2013  07:10    <REP>          data.tmp
               6 fichier(s)            1,878 octets
               3 Rép(s)  73,975,611,392 octets libres

d:\tmp\test\hsqldb\Run_0>

请注意尺寸。

所以，我推断SET FILES WRITE DELAY 被SET FILES CACHE 属性覆盖。

我说的对吗？如果缓存在 500 毫秒结束之前溢出会发生什么？会被刷新还是会观察到 500ms 的延迟？

编辑

这很奇怪。我在 50 个不同的 HSQLDB 嵌入式数据库中分配数据（使用 50 个不同的数据源对象）。 每个 DB 有三个 CACHED 表：

CREATE TABLE RUNSTATS
(
   ID      BINARY(16)   NOT NULL,
   ENTITY  BLOB(128K)     NOT NULL
   ,CHECK (PUBLIC.RUNSTATS.ID IS NOT NULL)
   ,CHECK (PUBLIC.RUNSTATS.ENTITY IS NOT NULL)
);

ALTER TABLE RUNSTATS
   ADD CONSTRAINT pk_runstats
   PRIMARY KEY (ID);

CREATE TABLE RUNSTATS__AVGLATENCYINDEX
(
   ID          BINARY(16),
   TIMESTAMP   BIGINT,
   FLOWID      VARCHAR(200),
   AVGLATENCY  DOUBLE
);

ALTER TABLE RUNSTATS__AVGLATENCYINDEX
   ADD CONSTRAINT pk_runstats__avglatencyindex
   PRIMARY KEY (ID, FLOWID);

CREATE INDEX IDX_RUNSTATS__AVGLATENCYINDEX_FLOWID
   ON RUNSTATS__AVGLATENCYINDEX (FLOWID ASC);

CREATE TABLE RUNSTATS__CLIENTGWTOTALININDEX
(
   ID          BINARY(16),
   TIMESTAMP   BIGINT,
   FLOWID      VARCHAR(200),
   CLIENTGWTOTALIN  DOUBLE
);

ALTER TABLE RUNSTATS__CLIENTGWTOTALININDEX
   ADD CONSTRAINT pk_runstats__clientgwtotalinindex
   PRIMARY KEY (ID, FLOWID);

CREATE INDEX IDX_RUNSTATS__CLIENTGWTOTALININDEX_FLOWID
   ON RUNSTATS__CLIENTGWTOTALININDEX (FLOWID ASC);

到目前为止，每个数据库已收到 26,000 个 RUNSTATS 对象（每个大约 1K）、52,000 个 RUNSTATS_AVGLATENCYINDEX 和 52,000 个 RUNSTATS_CLIENTGWTOTALININDEX 对象。

这是 50 个数据库实例中任意一个的目录：

d:\tmp\test\hsqldb\Run_12>dir
 Le volume dans le lecteur D s’appelle DATA
 Le numéro de série du volume est 3C08-FEE7

 Répertoire de d:\tmp\test\hsqldb\Run_12

06/04/2013  07:10    <REP>          .
06/04/2013  07:10    <REP>          ..
06/04/2013  08:25         8,388,608 data.data
06/04/2013  07:10                 0 data.lck
06/04/2013  07:10                 0 data.lobs
06/04/2013  07:10                 0 data.log
06/04/2013  07:10                89 data.properties
06/04/2013  07:10             1,757 data.script
06/04/2013  07:10    <REP>          data.tmp
               6 fichier(s)        8,390,454 octets
               3 Rép(s)  33,617,223,680 octets libres

d:\tmp\test\hsqldb\Run_12>

java 进程的 RAM 已增长到超过 3GB。

RUNSTATS 对象应该转到 lobs 文件，不是吗？那么为什么这个文件被报告为空呢？如果一个 RUNSTATS 对象需要大约 1K，则在大约 10,000 个对象后达到 10,000K 的限制，但已经插入了超过 26,000 个！

请向我解释一下这种奇怪的行为。

【参考方案1】：

您在操作期间对目录的读取可能无法显示实际文件大小。这些尺寸在关机后会正确显示。

RUNSTATS blob 转到 lobs 文件。这些行在数据文件中。在 lobs 文件中，每个 blob 将占用 32K (SET LOB SCALE 32) 和 128K 之间的空间。

WRITE DELAY 设置仅与日志文件相关。它不适用于缓存和数据文件。

在 Windows 中，您可以使用资源管理器在右键单击文件后查看文件属性。这应该在操作期间显示当前文件大小。

【讨论】：

BLOB 粒度由LOB SCALE 属性决定？

插入 lobs 后不会。如果您的 lobs 平均为 32K 或更高，则 32 是可以的。