OK, thanks, very useful. David
On Wed, Jul 21, 2010 at 1:56 PM, Mike Matrigali <mikem_...@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
