[BangPypers] NoSQL

[Santosh Rajan]

Here is something for the lighter side. A NoSQL CV. :-)
http://geekandpoke.typepad.com/geekandpoke/2011/01/nosql.html



On Sun, Feb 13, 2011 at 3:24 PM, Noufal Ibrahim <noufal at gmail.com> wrote:
> On Sun, Feb 13 2011, Anand Balachandran Pillai wrote:
>
>
> [...]
>
>> Hmmm, "better" in what sense ? By "better" if you mean the
>> programmer's or maintainer's work is reduced from designing schema,
>> writing SQL to store/retrieve data, basically all the RDBMS stuff vs
>> designing a rather flat key/value store using a Document store
>> (nosql), I am not convinced.
>
> Better meaning that it models the domain properly. I have documents that
> I want to store with versioning and couch (haven't used Mongo) does
> exactly that.
>
>> Does it really matter in a small-size wiki project whether you are
>> using SQLite to store your data, vs a mongodb that just runs on your
>> machine ?
>
> Perhaps not but you'd have to select one anyway.
>
>> I would rather go for the sqlite solution since,
>>
>> 1. It is the most simplistic RDBMs one can think of.
>> 2. You get the power of SQL, thereby chance of writing
>>  adhoc queries in the future.
>
> I'd consider using Couch simply because I don't have to write a *real*
> application. Just a few views to present the pages and that's it. I
> don't need to bother with a relational database, a schema, an ORM, a
> separate web application and what not. At the end of the day, a wiki is
> just a bunch of documents that are versioned. My example probably has
> flaws because I'm not that comfortable with document stores yet but I
> think the point I'm making is clear.
>
> As for point 2., Sounds like YAGNI to me.
>
> My point is that there's not need to "default" to RDBMS (except the fact
> that we're mostly "used to" relational databases rather than document
> stores).
>
>
>> I don't agree with it. One of the basic premises from where the nosql
>> platforms come is that they are trying to solve problems where your
>> data is distributed in a scale that traditional RDBMs would find it
>> difficult to address with sufficient performance. If I use the "CAP"
>> terminology, nosql is solving the problems of A and P on a large scale
>> while making no promises on the C side.
>
> Probably but that doesn't mean that scale is the only reason to move
> away from RDBMS.
>
> Once upon a time, I had binary file formats, then XML, then lightweight
> markups. In the future more of these might come. Just like that, I have
> a new way of storing data now.
>
>> Unless your wiki need to scale to at least 100K nodes or more, I don't
>> see a real technical reason to use document stores apart from
>> relieving you upfront of complex schema design and writing SQL
>> queries.  If you mean that is "better" for you, then we are talking of
>> different problems here. Mileages vary.
>
> I don't think the schema design for a wiki is "complex". I just don't
> see any reason to bother doing it at all. I also don't plan to scale to
> 100s of nodes. Maybe just run it as a personal wiki.
>
> I have a problem and a data store that models the domain almost
> exactly. Why do I have to restructure my data as "relations" and then
> write "queries" to get them? The only reason I can think of to do that
> is because I'm "used to" SQL.
>
> [...]
>
>> You might have got me wrong. My point was that there seems to be a
>> trend where programmers and designers choose to implicitly assume that
>> just because their data is expected to scale to gigabytes or terabytes
>> in the future, the right choice upfront is a Document store (I prefer to
>> use this term as against the confusing "nosql" one), which is not
>> the correct way to do this.
>
> Agreed.
>
>> I think any complex data storage problem will at the end consist of a
>> mix of Document stores and Relational stores. For example, in the link
>> I quoted the O.P seems to come from that kind of a thinking. Something
>> to do with all the current thinking in terms of "cloud" and "data out
>> there" and the fashion to think of SQL as "that old thing" and
>> Document store as "this flashy new thing".
>
> Agreed there too. Technical reasons and decisions are fine. It's the
> whole "SQL camp" vs. "noSQL camp" thing that's fruitless and I think
> Santosh's mail that started this thread with the "god help you",
> suggests that.
>
>> Looking at the hardware part of it, RDBMs have been severely limited
>> by current storage technology, i.e platter spinning disks, which is a
>> limiting factor when trying to optimize closer to the metal. SSDs
>> could solve a whole lot of the problems at that level, though now a
>> day's the trend is to blame the poor performance on the DB and think
>> of a document store which scales to millions of nodes, like Digg did
>> for example.
>
> Well, if you *already* have a relational setup, you can beef up the
> machine with SSDs and things to keep it going but if it doesn't work,
> you might have to consider scaling horizontally and then things change.
>
> [...]
>
>
> --
> _______________________________________________
> BangPypers mailing list
> BangPypers at python.org
> http://mail.python.org/mailman/listinfo/bangpypers
>



-- 
http://about.me/santosh.rajan