db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Van Couvering <da...@vancouvering.com>
Subject Re: Reducing memory footprint of embedded Derby
Date Wed, 21 Jul 2010 22:31:21 GMT
OK, thanks, very useful.

David

On Wed, Jul 21, 2010 at 1:56 PM, Mike Matrigali <mikem_app@sbcglobal.net>wrote:

> 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).
>



-- 
David W. Van Couvering

http://www.linkedin.com/in/davidvc
http://davidvancouvering.blogspot.com
http://twitter.com/dcouvering

Mime
View raw message