db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: Blog response to Oracle white paper
Date Fri, 01 Dec 2006 00:35:21 GMT
Olav Sandstaa wrote:

> 
> Several places in the BDB paper the same conclusion is reached that
> the lower performance of Derby compared to BDB is "probably due to
> the overhead of SQL processing in Derby". The experiment that is most
> similar to the "get record based on key" as requested in [1] is shown
> in the figure named "Random read". In this figure it seems like BDB has 5X
> the performance of Derby (100.000 vs 20.000 records per second).

I actually think this is the 10x measurement that justifies the top-end 
of the claim of being 10x slower. Apart from not having the source I 
can't see any description of "random read" in the paper. So there's a 
graph that shows Derby being 10x slower with absolutely zero explanation 
for what was being measured.

I think it would be useful to setup a standard benchmark, based around 
these types of applications that could be implemented against 
BerkeleyDB, Hibernate, SQL, JDO, JPA etc. That is the benchmark would be 
defined in abstract terms, that would allow multiple implementations. 
Then at least we could all have some confidence over what was being 
measured.

I agree with you & Suresh, that 400% or 1000% seems too much for SQL 
processing, but without seeing if the applications are receiving 
identical functionality from the databases it hard to see what is going 
on. One possible difference is the byte[] array returned from the api. 
With JDBC the value returned is private to the application and thus the 
application can modify it without making a copy. Is the same true for 
BerkeleyDB, or does its api allow it to return a single value that the 
application needs to copy if it wants to modify?

Dan.



Mime
View raw message