次の HSQLDB スキーマがあります。
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);
RUNSTATS テーブルはx.lobsファイルにあり、RUNSTATS__AVGLATENCYINDEX はx.dataにあります。
RunStats オブジェクトを挿入すると、それぞれが RUNSTATS テーブルに 1 行、RUNSTATS__AVGLATENCYINDEX に 100 行が生成されます。3 つのセッションを実行し、100、1000、および 10000 の RunStats オブジェクトを挿入します。
もう 1 つの非常に重要な詳細 - フィールドが VARCHAR(200) であるにもかかわらず、実際の FLOWID 値はすべて正確に 20 英字です。
x.dataファイル (RUNSTATS__AVGLATENCYINDEX テーブルを含む)のディスク使用量の概要を以下に示します。
- 10,000 行 = 2.0MB
- 100,000 行 = 16MB
- 1,000,000 行 = 128MB
生の計算: (sizeOf(ID) + sizeOf(FLOWID) + sizeOf(TIMESTAMP) + sizeOf(AVGLATENCY)) = 16 + 20 + 8 + 8 = 52
したがって、1,000,000 行には約 52 * 1,000,000 = ~50MB が必要です。
最適なサイズは、実際のサイズの 2 倍以上小さくなっています。
それは通常のデータベースのオーバーヘッドですか? スペースをより効率的に利用するように hsqldb エンジンに指示できますか?
もう少しコンテキスト:
- エンティティは追加されるだけです (決して削除されません)
- エンティティが定期的なペースで追加される明確に定義された期間があります。たとえば、3 日間 10 秒ごと。その後、エンティティは追加されません。
編集
ここで圧縮スクリプト ファイルを見つけてください - https://docs.google.com/file/d/0B2pbsdBJxJI3Z2dFTndMZnBMU2c/edit?usp=sharing