Re: [boost] [relational] Relational Model Library

From: Jose (jmalv04_at_[hidden])
Date: 2005-09-30 12:04:16

Hi Calum
I am very interested in using both your RML and persist library (especially
RML with persist) to avoid sql db altogether!

Some questions I have for persist:

- Your benchmark was for 0.9 release on 2.4 kernel. What happens on 0.95 and
2.6 kernel ?
- The 1 million row limitation looks awfully low to me. Is the code 64-bit
ready ? If not, do you have any plans for x86_64 ?
- This seems a core library that boost should have. Do you plan to submit it
?

Jose
On 9/29/05, Calum Grant <calum_at_[hidden]> wrote:
>
> > [mailto:boost-bounces_at_[hidden]] On Behalf Of Andreas Pokorny
> > On Wed, Sep 28, 2005 at 10:50:51PM +0100, Calum Grant
> > <calum_at_[hidden]> wrote:
> > > > [mailto:boost-bounces_at_[hidden]] On Behalf Of
> > Andreas Pokorny
> > > > On Tue, Sep 27, 2005 at 09:24:24PM +0100, Calum Grant
> > > > <calum_at_[hidden]> wrote:
> > > > > Is there any interest in providing relational
> > containers in Boost?
> > > > > Are there any features/improvements you can suggest for RML?
> > > >
> > > > You could compare the library with sqlite.
> > >
> > > Completely different. Most database engines are controlled
> > via text
> > > strings, and require parsing and data transformation. This
> > cuts all
> > > that out using C++ templates, and is therefore way faster. It's a
> > > container.
> >
> > Oh, sorry my request was not formulated clearly enough. I
> > wanted to see how rml performs compared to sqlite in a
> > benchmark. Sqlite is currently
> > a nice and fast solution if you do not need a remote
> > database. Rml could
> > be an even better solution, if you do not require a text sql
> > interface, provided that there are table types available in
> > rml, which work without
> > being fully loaded to memory.
> >
> >
> > > > Furthermore you could implement a table that can be stored in
> > > > a file, and used wihout reading all records into memory.
> > >
> > > I think the memory-mapped file route would be the most
> > profitable, it
> > > would probably already work.
> >
> > Interesting, could you give a short overview, how it could
> > already work.
>
> You could use an allocator with RML (or indeed any STL container) that
> stores the data in a memory-mapped file. This basically makes the data
> persistent.
>
> I actually had a project a while back that did such a thing, and got
> some good benchmarks comparing MySQL vs file-mapped containers:
> http://lightwave.visula.org/persist/bench.html
> and I'm sure boost::shmem::allocator is similar. Performance is very
> good. We could devise a benchmark and I'll implement in RML +
> Persist/Shmem, you implement in SQLlite and we'll see the difference.
>
> Calum
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>