[Pharo-project] [OT] NO-SLQ vs RDBMS Re: FluidDB API for Pharo

Germán Arduino garduino at gmail.com
Mon Oct 4 08:47:13 EDT 2010


I did some experiments with Cassandra (being that Thrift already
produce valid Smalltalk code) and my pov is
that nosql are born to solve the scalability problem in terms of
horizontal growing, sacrificing some time in consistency.

They are named "eventually" consistent, because the delays Randal
commented. To some sort of applications, as sort of Facebook or
Twitter, are a good option.

My 0,02.


2010/9/26 Randal L. Schwartz <merlyn at stonehenge.com>:
>>>>>> "Mariano" == Mariano Martinez Peck <marianopeck at gmail.com> writes:
>
> Mariano> Hi. Can someone with experience in "No-SQL" databases explain me the
> Mariano> differences/advantages over a RDBMS and doing something like:
>
> Mariano> create table database (key varchar() , value varchar() )
>
> I've given a talk a few times about "forget the ORM".  The slides are up
> on http://www.slideshare.net/RandalSchwartz/forget-the-orm
>
> The key thing that separates a lot of these newer databases is that you
> can't have all three of consistency, availability, and performance at
> once... you have to sacrifice something.  Traditional SQL databases
> favored consistency over everything, but who cares if your blog page
> says "read the 6 comments on this item" for a couple of seconds when
> there are really 7 because one just got added.
>
> The new databases give options for higher availability or performance at
> the cost of consistency.  Some, like Riak (interviewed at
> http://twit.tv/floss129), actually let you select on each request how
> consistent you want the results, thus controlling how fast you get the
> response.  Thus, for the front page of a blog, you can say "give me a
> result that any 1 of the 3 replicas has", but when you finally drill
> into the comments, you say "give me a result that all 3 replicas agree
> on".  Of course, these are all *eventually* consistent on the order of
> tens or hundreds of milliseconds, but by allowing "almost correct"
> results, things are a lot zippier.  (It also works that way on
> write... you can say "come back when any 1 replica says it has it" or
> "come back only when all 3 replicas confirm write".)
>
> So, it's not so much that you get schemaless key/value store (although
> that's a frequent feature)... it's that these aren't traditional
> databases in a lot of ways.
>
> --
> Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
> <merlyn at stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
> See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project at lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>




More information about the Pharo-dev mailing list