Evan Weaver on 6 Sep 2007 20:14:59 -0000


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

Re: [PhillyOnRails] jruby + hadoop?

  • From: "Evan Weaver" <evan@cloudbur.st>
  • To: talk@phillyonrails.org
  • Subject: Re: [PhillyOnRails] jruby + hadoop?
  • Date: Thu, 6 Sep 2007 16:14:16 -0400
  • Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=XfuHlXUZltwQ2QcX/+fBI0jYXnS+AWw/7uAn5cn2fnM=; b=KSN0HCHarWwMxRb9uYVMrfmxCC0EbETcyFgIm2VruvDixpRI6QuvkUrjXyvg/119MYalrAOdicTSYQHcu9FmHOUDktD5+06SCwQ/WBF0dofUaENX+2xKfp5gHDmHue+EAgnRlMUTwsgbn65JeQHMN2D6JO4OnhtnKlX9NHoSYFU=
  • List-archive: <http://lists.phillyonrails.org/pipermail/talk>
  • Reply-to: talk@phillyonrails.org
  • Sender: talk-bounces@phillyonrails.org

BDB isn't SQL based; it's just a hash table.

For some people, continuations still are the future.

Evan

On 9/6/07, Cassius Rosenthal <cassius@xmodulation.com> wrote:
>
> >> That's not quite fair, Toby. I agree that Casey was wrong to suggest
> >> that RDBMs' text search hacks are adequate means to handle
> >> unstructured data, but I didn't care for your response. Casey raised a
> >> much larger issue that you did not address. I usually respect your
> >> opinion (if not your demeanor,) but I was disappointed to see you give
> >> in to resorting to straw-man argument instead of continuing (mostly)
> >> reasoned discussion.
> >>
> > You're right. I apologize.
> >
>
> For the record, I take more offense from Kenosha's suggestion that RDBMS
> text searches are "hacks" inadequate for handling semi-structured data.
> I have recently uncovered inside information from an anonymous source
> suggesting that more than 97% of Aaron's current projects use RDBMSs for
> semi-structured data, and I would challenge him to justify deploying
> 'inadequate hacks' in his client's projects.
>
> (^_^)
>
> Seriously -- no offense taken.
>
> > The trick to understanding the state here is that its everywhere in a
> > traditional RDBMS, not just in the data. The schema and the query both
> > have state. The schema cannot be changed without big pain (the bigger the
> > data and the more tables, the more pain). As a result, the SQL queries
> > themselves than also carry state that limit their parallelizability. Plus,
> > the very power of SQL limits it in other ways, too.
> >
>
> OK -- I can see that changing schema (or a view) in an RBDMS requires an
> explicit command, and does not in CouchDB. So an RDBMS would return an
> error whereas CouchDB would just return nothing for that part of the
> graph. But BerkeleyDB is SQL-based. So does BerkeleyDBHA not require an
> explicit command to change shema?
>
> I still think 'stateless' is the wrong word. Structured vs
> semi-structured seems a more reasonable distinction.
>
> > If you'd like a pretty good book on how SQL works under the hood and
> > the math behind it, check out The Art of SQL by Stephane Faroult.
> >
>
> Will do -- thanks for the suggestion.
>
> Thanks!
> -Casey
> _______________________________________________
> To unsubscribe or change your settings, visit:
> http://lists.phillyonrails.org/mailman/listinfo/talk
>


-- 
Evan Weaver
Cloudburst, LLC
_______________________________________________
To unsubscribe or change your settings, visit:
http://lists.phillyonrails.org/mailman/listinfo/talk