Hi Mike,
Thanks for responding. Some comments inline...
Mike Matrigali wrote:
Bryan Pendleton wrote:
be useful for applications which just need to put and get data by
key value. These would be applications which don't need complex
queries or SQL.
Aren't there some pretty good packages for this already? E.g., BDB-JE,
JDBM, Perst, etc.?
Speaking totally personally, I'd sure like to see Derby focus on the
things that make it special:
- complete and correct JDBC implementation
- complete and correct SQL implementation
- low footprint, zero-admin reliable multi-user DBMS
thanks,
bryan
I agree with bryan, I would rather see the Derby project concentrate on
the stated goals of the project as Bryan enumerates.
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
I think that there are other usage patterns which are important to
people who use these btree stores. It's not just single row key/value
lookup although that's an important case. People also like to position
an iterator on a btree and then march forward (or backward), updating
and deleting as they go.
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? And if jdbc is too complicated, could something very simple
be provided on top of jdbc at the cost of an extra method call per
access?
I think these are useful itches to scratch. Just to repeat the benefits
of Derby Lite:
i) smaller
ii) faster
iii) easier
Streamlining the JDBC and SQL interpreter stacks would give us something
faster but not smaller or easier.
There are already plenty of ORM layers which you can bolt on top of
Derby in order to get something that is easier but bigger. I think that
the ORM layers can deliver something faster too but at the cost of
warming up a cache.
2) Can we provide a way such that only a single btree need be created,
rather than the current requirement of a heap and index. The current
model works well if one needs to create multiple indexes on the base
data, and if there is is no limit on the size of the un-indexed portion
of the data.
Other relational databases support this structure. If we were just
building this for Derby Lite, then some of the issues are called out at
http://wiki.apache.org/db-derby/DerbyLite#head-6d68dc7584419d1853f1f15d203513afa44be3a6
:
a) The current payload in the btree leaf page is a RowLocation and there
may be some other assumptions about this payload, for instance as you
note, its size.
b) Row-level locks are held on heap rows, not btree entries.
I could definitely see this improvement being built by the Derby Lite
enthusiasts. Then someone else could come in and add support for it in
the Derby SQL interpreter.
Thanks,
-Rick
3) anything else?
