Re: Opportunity for a Radical Changes in Database Software

From: "J(dot) Andrew Rogers" <jrogers(at)neopolitan(dot)com>
To: Florian Weimer <fw(at)deneb(dot)enyo(dot)de>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Opportunity for a Radical Changes in Database Software
Date: 2007-10-28 04:38:11
Message-ID: 5C8EC50A-11B4-4EE3-A77C-701A1CF22D2C@neopolitan.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On Oct 27, 2007, at 2:20 PM, Florian Weimer wrote:
> * J. Andrew Rogers:
>
>> Everything you are looking for is here:
>>
>> http://web.mit.edu/dna/www/vldb07hstore.pdf
>>
>> It is the latest Stonebraker et al on massively distributed in-memory
>> OLTP architectures.
>
> "Ruby-on-Rails compiles into standard JDBC, but hides all the
> complexity
> of that interface. Hence, H-Store plans to move from C++ to
> Ruby-on-Rails as our stored procedure language." This reads a bit
> strange.

Yeah, that's a bit of a "WTF?". Okay, a giant "WTF?". I could see
using Ruby as a stored procedure language, but Ruby-on-Rails seems
like an exercise in buzzword compliance. And Ruby is just about the
slowest language in its class, which based on the rest of the paper
(serializing all transactions, doing all transactions strictly in-
memory) means that you would be bottlenecking your database node on
the procedural language rather than the usual I/O considerations.

Most of the architectural stuff made a considerable amount of sense,
though I had quibbles with bits of it (I think the long history of
the design makes some decisions look silly in a world that is now
multi-core by default). The Ruby-on-Rails part is obviously
fungible. Nonetheless, it is a good starting point for massively
distributed in-memory OLTP architectures and makes a good analysis of
many aspects of database design from that perspective, or at least I
have not really seen anything better. I prefer a slightly more
conservative approach that generalizes better in that space than what
is suggested personally.

Cheers,

J. Andrew Rogers

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Henry B. Hotz 2007-10-28 04:46:10 Re: 8.3 GSS Issues
Previous Message Alvaro Herrera 2007-10-28 01:13:19 Re: pgsql: Allow an autovacuum worker to be interrupted automatically when