Toby DiPasquale on 7 Sep 2007 13:58:23 -0000

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PhillyOnRails] jruby + hadoop?

On Thu, Sep 06, 2007 at 09:56:29AM -0400, Cassius Rosenthal wrote:
> Toby DiPasquale wrote:
> >On Wed, Sep 05, 2007 at 08:10:36PM -0400, Cassius Rosenthal wrote:
> >  
> >>I'm not really sure what you mean by that last line. Every RDBMS that 
> >>I've ever worked with had string pattern matching of some sort.
> >>    
> >
> >Good point. Now describe how Google would be built using Oracle. Your only
> >constraint is that it work like it does today.
> >  
> I would start with this, and add more CPUs as needed:
> [oh, snap!]  (^_^)

Not to be a dick, but you'd only think of that until they told you the 
price. ;-) Plus, you'd find that your cap on CPUs is quite small. Veritas
Cluster can only get up to 32 nodes. (disclaimer: I worked at Symantec
before and after the Veritas acquisition)

> Of course I understand your Socratic suggestion -- Google *probably* has 
> better performance for that particular application (search engine) -- 
> But you are suggesting that RDBMSs are inappropriate for semi-structured 
> data.  I think that is a bit of a stretch, and I think that widespread 
> usage of MySQL (to pick one) attest to their usefulness for exactly that 
> purpose.

But they are not generally used for that purpose. Perhaps we should be
calling it "variably-structured data" to better intimate the issue. A
table of users and their information is well structured. Web pages and
emails are not as they vary quite a bit in their content and format. If
you tried to build a search engine on an RDBMS, you'd have a hell of a
time trying to get the schema right (without BLOBs) and you'd also find
yourself constantly going through painful schema upgrades. 

> My motivation here is professional courtesy: a little less than two 
> years ago, I was told by *someone* (^_^) at PhillyOnRails that 
> _continuations_ were the future of next-generation Rails apps.  Oh, the 
> time I've wasted . . .

Touche :)

Continuations can be helpful in inverting back the inversion of control of
a typical web app. See Seaside and DabbleDB for some examples of this.

If you can marshal your continuation into a cookie and offload that to the
browser, continuations can be a big win. However, if you cannot,
continuations might be a real nightmare in terms of scaling up your app.
Frankly, I'd love to see how big DabbleDB is and how they are handling
this issue.

Personally, I'm intrigued by Jetty 6's implementation of one-shot
continuations and I can definitely see myself using that to do some flashy
Comet thing in the future. That, or Erlang ;-)

Toby DiPasquale
To unsubscribe or change your settings, visit: