Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Discussion" <derby-user@db.apache.org>
Received-SPF: pass (athena.apache.org: local policy)
From: dag.wanvik@oracle.com (Dag H. Wanvik)
To: "Derby Discussion" <derby-user@db.apache.org>
Subject: Re: Reducing disk footprint with compression (gzip?)
References: <20110414185810.80833aa0908s9msi@messagerie.si.c-s.fr>
Date: Sat, 16 Apr 2011 15:36:41 +0200
In-Reply-To: <20110414185810.80833aa0908s9msi@messagerie.si.c-s.fr>
	(BONNEFILLE Guilhem's message of "Thu, 14 Apr 2011 18:58:10 +0200")
Message-ID: <x67hau8gie.fsf@oracle.com>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (usg-unix-v)
MIME-Version: 1.0
Content-Type: text/plain

BONNEFILLE Guilhem <guilhem.bonnefille@c-s.fr> writes:

> An other solution is to compress (gzip) old part of history as we
> never need to update them.
>
> Is it possible to do this with Derby?

Derby doesn't have any built-in compression facilities. You say you
don't perform updates (or deletes), so presumingly there are no holes in
your database files, so running compression wouldn't help[1].

Some ideas: Could you compress the lob contents before you insert them
into the database and uncompress on retrieval? Could you store the lobs
as compressed files and just let the database reference them? Did you
consider a compressing file system?

Thanks,
Dag

[1]
http://db.apache.org/derby/docs/10.7/ref/rrefaltertablecompress.html
http://db.apache.org/derby/docs/10.7/ref/rrefproceduresinplacecompress.html


> Do you have any other tips when faced to this use case?
> Any other (embedded) database that best matches our needs?
>
> Thanks for your answer.
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.