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