db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Scott" <deni...@gmail.com>
Subject Re: multiple webapps many embedded vs single network
Date Mon, 30 Oct 2006 04:10:28 GMT
On 29/10/06, Michael Segel <msegel@segel.com> wrote:
> > -----Original Message-----
> > From: Jean T. Anderson [mailto:jta@bristowhill.com]
> > Sent: Sunday, October 29, 2006 1:32 PM
> > To: Derby Discussion
> > Subject: Re: multiple webapps many embedded vs single network
> >
> > Michael Segel wrote:
> > ...
> > > Derby wasn't designed to be a central database to multiple apps. So its
> > not
> > > efficient in that role. Note: This is in comparison to IDS, DB2, Oracle.
> > > Derby is not one of those. It lacks the features that they have to act
> > as a
> > > centralized DB, however it does have a much smaller footprint.
> >
> > I disagree with this statement, but perhaps I didn't read this thread
> > carefully and am missing some context.
> >
> [mjs]
> Knowing you, you haven't really thought about what I was saying.
> > Derby fully supports multi-user, multi-application concurrent access,
> > even in embedded mode. It complies with the ACID (Atomic, Consistent,
> > Isolation, Durable) properties expected of relational databases.
> >
> [mjs]
> And what does this have to do with performance?
> Now Jean you should know better. But I don't believe you're truly a heritage
> Informix person. ;-)
> I would suggest that talk to Mohan and ask him about items in DB2 and
> Informix that improve performance. Just how IDS stores data is way more
> advanced. Raw partitions/chucks, table spaces, table portioning, detatched
> indexes. It's the whole layout.
> > Olav Sandstaa's ApacheCon US 2005 performance presentation is here and
> > includes results for Derby in both embedded and client/server modes
> > (plus MySQL and PostgreSQL):
> > http://wiki.apache.org/apachecon-
> > data/attachments/Us2005OnlineSessionSlides/attachments/ApacheCon05usDerbyP
> > erformance.pdf
> >
> [mjs]
> Ooooh! MySQL, now that's a barn burner when it comes to looking for a
> centralized database?
> Hint: Compare MySQL to DB2, Oracle, Informix on performance issues.
> > I don't know of any similar results for comparing Derby performance to
> > IDS, DB2, and Oracle. If anyone knows of any such studies, please post a
> > pointer.
> >
> [mjs]
> You won't see it.
> Is there a Derby TPC-C benchmark?
> In case you've missed it, Derby was designed with a small footprint. Adding
> features that make databases perform well where there are multiple
> instances/databases per server, improved data storage techniques etc are
> missing from Derby.
> Is that a bad thing? No. Derby was designed for a specific niche and not a
> general purpose centralized database. You want those features, then you
> increase your footprint and you lose your ability to be embedded in a web
> page.
> We've covered this ground before.
> Does the community want a 100% Java, and a *free* database that could
> compete with Oracle, DB2 and Informix? Are there people in the community
> that are capable of designing and implementing this?
> And how do you still maintain the small foot print for those that want to
> imbed it?

Well, this seems like flamebait to me. The proof is in the Apache
Derby that exists right now: it has a small foot print, you can set it
up in Network Server mode, grant privileges to discrete users and
separate applications through the use of schemas. It seems to perform
quite well, although nobody to date has stepped up to fund an official
TPC-C or TPC-H benchmark (which shouldn't surprise anyone, as MySQL
and PostgreSQL haven't had official benchmarks set here either). But
the original poster's question was not about performance benchmarks or
competing with IDS, Oracle, or DB2; it was a simple question about
memory usage.

To answer the original poster's question, Network Server mode is
undoubtedly more memory efficient if you're using it as a central
database for more than a couple of applications. The reason the
threshold is a couple of applications is that the Derby database
itself runs in one JVM, while the Network Server runs in a separate
JVM. Thus, your memory break-even point is effectively two
applications hosted in a single Network Server mode Derby database.
After that, you're saving yourself one JVM per application (subject,
of course, to some increasing memory overhead due to the number of
concurrent connections your Network Server may have to handle).

In terms of separating your applications at a later date, I wouldn't
worry too much about that. Use schemas to separate your application
and you can pretty easily shift an application to point at another
database at any given time; just export the schema for the given
application, load it in the new database, and change your connection
string to hit the new database.


View raw message