db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: Reducing memory footprint of embedded Derby
Date Wed, 21 Jul 2010 20:56:53 GMT
David Van Couvering wrote:
> Thanks, Mike
> 
> I am doing some of that, and am looking into doing more of that. 
> 
> But it's more than possible that I'll have a lot of open, *active* 
> databases. 
> 
> We're talking a lot of data, potentially 10s of GB of BLOBs.  I was 
> concerned a single Derby DB would not be able to handle this well, so I 
> asplit this up into multiple databases.  This also gives me future 
> flexibility to spread the databases across different disks to avoid 
> contention. 
> 
> But if you think this can be managed fine in a single database, well, I 
> could be convinced to go that way... :)

While supported, Derby was not really designed with large number of
concurrent databases in mind.  All performance work has always 
concentrated on single database throughput.  All cache's are per 
database, all locking is per database, all background threads are per 
database.  If at all possible I would go with one database.

The multiple disk issue is definitely a problem with one database.  The 
hope was that OS tools could be used to present multiple disks as one 
disk to the derby database.  I believe the sun OS's have a really nice
implementation of this.

Also concurrency and multi-thread throughput may go faster in the 
multiple database configuration, if you find ways to get each database
it's own resources (again this is the multiple disk per database issue).

Mime
View raw message