-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 23, 2005 3:16 AM Cc: [email protected] Subject: Re: Cloudscape Database Size limitation
The following message is a courtesy copy of an article that has been posted to comp.lang.java.databases as well. [EMAIL PROTECTED] writes: > Does anyone know cloudscape database size limitation? Any documentation > states the relation between cloudscape database size and performance? For Derby (open source Cloudscape) I don't think there is a limitation (other than those imposed by OS, jvm, available memory and disk). I have seen it run with 10 GB, and I believe IBM is planning on testing with up to 100 GB. To get performance with a large database you may need to adjust the pageCacheSize (the default is only 4MB). The tests I have seen indicate that Derby performs better (relative to other dbs) the larger the database is. (I have cc'ed my reply to the derby-user mailing list, where more derby experts are likely to see it. You can subscribe to and browse this (and other) mailinglist at http://db.apache.org/derby/ -- Dt ------------------------------- I'm a little skeptical whenever I see a question like this. There are always limits. And while you could get up to 100 GB, I wouldn't recommend it performance wise as Derby is currently written. I think the important point isn't to find a theoretical limit, but to choose the right database for the right job. 1 GB is a lot of data. Regardless of what database you are planning on running. (Putting blobs aside for now.) Derby still has some ugly warts. (Derby-47)as an example. It has some limitations on how it stores data that will cause issues when it starts to get large. Going over a certain point, you're going to want to choose a database that has a better storage method than using the file system. (And I had better clarify...) I'm talking about having the data stored in either raw or cooked chunks. Not As separate files within a directory. (More akin to Informix's Standard Engine.) The comment that Derby scales better to *other* databases, requires some parameters. I wouldn't try to benchmark Derby against Informix or DB2. Its more important in identifying the application requirements and then seeing what database is going to meet your needs. Note that there would have to be some changes to Derby if you were going to offer the concept of a tablespace/chunk and then raw/cooked chunk/partitions. But hey, what do I know? Its not like I haven't been playing with databases since the 1980s? (eeew! Now I know I'm getting old.) ;-) -G
