db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: simpler api to the Derby store
Date Tue, 15 Jul 2008 18:16:52 GMT
Knut Anders Hatlen wrote:
> Mike Matrigali <mikem_app@sbcglobal.net> writes:
>> I do wonder if within this scope derby could do a better job of
>> addressing the application paradigm of only needing single keyed
>> access to a row of the form (short key, short data).  By being embedded
>> derby already presents a better solution for a java application than
>> a lot of databases.  So issues are:
>> 1) can we improve the jdbc implementation to make using it for a
>> compiled plan close to as efficient as a non standard, store specific
>> interface?
> Not an answer to your question, but I performed a small experiment to
> get a feel of how large the overhead imposed by the SQL and JDBC layers
> was for these simple queries. I used the single-record select test in
> org.apache.derbyTesting.perf.clients.Runner, which just performs primary
> key lookups and fetches about 100 bytes of data. When I accessed the
> same table and index directly through the store API (using same
> isolation level, holdability etc), I got about 15% more accesses per
> unit of time than when I accessed them through JDBC.
> The test was basically just a loop performing these operations:
>   * Traversing the B-tree (three hops, I think) with
>       TransactionController.openCompiledScan()
>       ScanController.fetchNext()
>   * One hop from the B-tree to the heap with
>       TransactionController.openCompiledConglomerate()
>       ConglomerateController.fetch()
>   * TransactionController.commit()
> I'm not sure how small an overhead in JDBC/SQL we can hope for, 15% is
> perhaps not too bad. If we implement some of the suggested improvements
> in the store without improving the top layers, the relative overhead of
> those layers will increase, though. In such a scenario, it may become
> more attractive to find a way to bypass those layers, unless we manage
> to reduce the extra cost.
Thanks for the experiment.  Those numbers seem really good to me.  To me
at least from the performance point of view it would not seem worth 
adding another interface.  I would not be surprised if there are things
that could be done to even do a little better on the 15% overhead that 
would then help both overall derby and the simple interface users 
applications.  And of course it means you are unlimited in the 
complexity of queries you may want to run, using a well known standard

This of course does not solve the code size issue if it is an issue for 
a particular device.

As to simplicity, it does seem like at the cost of a single extra method 
call you can turn jdbc into a set/get interface against a single keyed 
table if that is all you want.

View raw message