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: New "segmented" StorageFactory Development
Date Fri, 05 May 2006 22:27:56 GMT

Rodrigo Madera wrote:
> On 5/5/06, Mike Matrigali <mikem_app@sbcglobal.net> wrote:
>> Do you have any more details on your requirements, such as the following:
>> 1) do you need for a single table and/or index to be spread across
>>     multiple disk?
> It would be terrific and the absolute glory of the requirement,
> however, it depends.
> Is Derby based on a table/index-is-a-single-file architecture? If so,
> it's too much trouble to change this. Making the tables/indexes
> segmented would only be viable (in my opinion) if Derby already
> supports this.

Yes the current Derby model is that a table/index is a single file
architecture.  This is known by the code implmenting the StorageFactory.
Above that, for instance in the raw storage engine it just needs to
open the abstract Storage file and be able to read/write pages - it is
up to the StorageFactory to do the right mapping.  Of course in the
current implementation the mapping is very straight forward :-), ie.
1-1 mapping of the file.

> I vote to get the "divider" in place that routes the new tables/etc to
> the different directories, and only then, when it's mature, begin a
> table segmentation engine.

I think this is a good first choice.  Seems a natural 1st step.

... cut ...
> This is only my initial vision of the model, so please give your
> opinions here to make it better.

I continue to support the model where the storage engine provides the
tools, and the caller uses them to.  Along these lines I prefer the
implementation that finishes the work of the storage engine allowing
seg0, seg1, ... directories.  It is up to the execution engine to
decide at create table or create index time which of these to use.
There would probably be the need for some new catalog that allows for 
defining segments, naming them, ...

If you want to go that route, I would definitely be interested in fixing
the current code to use the existing segment interface properly.

On the other hand, implementing a separate StorageFactory may be easier
for you to implement as it is a very small module of code located in
one place.  And if you can get your hands on the in memory 
implmentation, it should show what kind of changes are necessary to 
provide alternate implementations.  You would have a plugable module
which would make it easy to compare/contrast performance.

Moving forward I believe doing the seg1 approach clears the way for
other work in the execution engine in the future, as described above.

> Thanks,
> Rodrigo Madera

View raw message