Comments on: The legit part of the NoSQL idea

By: Chris Bird’s blog is brilliant, and update-in-place is increasingly passe’ | DBMS2 -- DataBase Management System Services

Thu, 25 Feb 2010 05:46:03 +0000

[...] the NoSQL guys point out, some of today’s most demanding applications have extremely simple schemas. [...]

By: Interesting trends in database and analytic technology | DBMS2 -- DataBase Management System Services

Mon, 01 Feb 2010 18:01:48 +0000

[...] me Friday he knows of a bunch of others as well. And that’s all before we even get into the NoSQL kind of [...]

By: Ling Qian

Ling Qian — Wed, 06 Jan 2010 09:29:33 +0000

NoSQL stands for “Not Only SQL”. I think KV store is good at manage data that have only one key, which is very popular for the Internet. However to manage multiple keys together, or relations among the data, SQL is probably the choice.

To some extend, KV Store is good in some kind of OLTP applications (could be more popular?), while SQL stays the master of data warehouse.

By: M

Wed, 30 Dec 2009 04:06:21 +0000

As a casual observer, it seems to me that NoSQL systems are really targeting a very specific problem: low latency queries on massively parallel data sets. The overhead to support distributed joins is a deal killer as far as this goal, so to simplify, they just did a way with all joins, and with no joins there really isn’t a relational model, so why keep SQL around?

By: RC

RC — Thu, 17 Dec 2009 19:00:29 +0000

@Andy E

It is not that I disagree but what name do you have in mind?

By: Andy E

Andy E — Thu, 17 Dec 2009 18:18:17 +0000

Shouldn’t the NoSQL movement consider renaming itself? Among the traditional limitations they’re trying to overcome (performance, scalability, data model flexibility, etc.), it seems to me that data access language (SQL) is the least of the problems.

The name is catchy, but a name that positions against traditional DBMS (e.g., like what Mike Stonebraker calls the “One-Size-Fits-All” databases) would probably get broader support than just the KV vendors.

By: RC

RC — Mon, 14 Dec 2009 21:43:20 +0000

I’m not so sure about the no-schema thing when it comes to Cassandra. The manual explains that you need to think about what queries you want to support effectively ahead of time and model appropriately. You can’t add indexes later. You also need to restart the database when you want to add, remove or rename a column family.

It sounds like a quite rigid schema to me.

By: RC

RC — Mon, 14 Dec 2009 19:03:54 +0000

It is easier to parallelize declarative/set-based code than imperative/procedural code but it is certainly not impossible. However a function has to live up to certain constraints to be parallelizable. A reduce function for instance has to be idempotent. ( http://www.mongodb.org/display/DOCS/MapReduce )

By: Joe Harris

Joe Harris — Mon, 14 Dec 2009 13:50:25 +0000

@Unholyguy

“SQL is not that great a language for querying and managing data” Huh? What’s your definition of data?

SQL may be unsuitable for many things, but querying and managing data (even just semi-structured data) is not in that list. SQL offers inherent opportunities for parallelism that no other mainstream language comes close to.

I’m all in favour of “supporting a wide variety of procedural languages” but that’s just what they are: *procedural* (i.e. PHP, Perl, Python, Ruby, etc.) They do everything *row by agonising row* and can’t even fully utilise a multicore machine. Regardless of future development in their VMs the programming structures they use will constrain a large percentage of their workloads to a single thread.

Joe

By: Curt Monash

Curt Monash — Sun, 13 Dec 2009 08:20:21 +0000

Unholyguy,

I think that’s an excellent summary.

CAM