db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rodrigo Madera" <rodrigo.mad...@gmail.com>
Subject Re: New "segmented" StorageFactory Development
Date Tue, 16 May 2006 18:54:24 GMT
To all of the members here, I want to wish you good luck and success
on the Derby project.

For external reasons, I will not participate in the Derby development process.

My ideas and those of others here should be implemented since I
believe it's a major win for the project itself, however I cannot
participate, even though it's what I really want.

Thanks to all and Good Luck!

Rodrigo Madera

On 5/5/06, Mike Matrigali <mikem_app@sbcglobal.net> wrote:
>
>
> 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
> >
> >
>
>

Mime
View raw message