SCALE 8x: Relational vs. non-relational

Posted Mar 4, 2010 17:30 UTC (Thu) by iabervon (subscriber, #722)
In reply to: SCALE 8x: Relational vs. non-relational by nye
Parent article: SCALE 8x: Relational vs. non-relational

There are plenty of revolutionary software changes. None of them work, and they won't work until a number of evolutionary changes make them viable. Static typing, automatic garbage collection, parameterized typing, and type inference were all revolutionary at different times, and were all unusable for generations before they had evolved to the point where people could use them, be able to do what they need to do, and get the benefits from the change.

When something claims to be revolutionary, the claim is generally really that its evolution has just made the revolutionary change available to people who want a system that works and don't want to redesign their application regularly to account for recent discoveries.

SCALE 8x: Relational vs. non-relational

Posted Mar 8, 2010 0:32 UTC (Mon) by dmag (guest, #17775) [Link] (2 responses)

I think the "revolutionary" isn't so much a label for the technology, but the fact that people are "bucking the trend" socially. The RDBMS has been the "gold standard" for the last 30 years. But the RDBMS market has basically stopped innovating. Trust me, I LOVE postgres, but it's lacking a lot of useful features. such as:

- Ability to just "add nodes" to help performance, without massive administration overhead. This is non-trivial: You need merkel trees, vector clocks, gossip protocols, etc. See Cassandra and Riak (and the Dynamo paper).

- Ability to answer queries quickly - The RDBMS has tons of overhead, such as query parsing, index selection, query optimization, etc. Some of the Key-Value stores can answer a query before an RDBMS is finished figuring out what the query is.

- Ability to forget about the database enforcing schema -- that's the application's domain. (In the old days, the database had to enforce constraints because it was the "integration point". Now every app has an API, so the database is only used by one app.)

- Ability to forget about writing to disk. Writing to disk means you have to run disk-based recovery (fsck, special recovery code, etc.) It's slow and especially useless in the cloud (on EC2, you can instantly loose your disk and you don't get it back). Instead, if you want HA, you should do replication with fail-over (in multiple data centers.)

- Ability to forget about consistency - It's *much* easier to achieve HA if you drop consistency. Consistency isn't always a business requirement. (See Amazon, see airline overbooking policies)

SCALE 8x: Relational vs. non-relational

Posted Mar 12, 2010 0:54 UTC (Fri) by robert_s (subscriber, #42402) [Link] (1 responses)

Seems to me like you want postgres to be able to just morph into any other type of database instantly at your whim, no matter how fundamentally different some of the ideas behind them are.

SCALE 8x: Relational vs. non-relational

Posted Mar 12, 2010 19:44 UTC (Fri) by dmag (guest, #17775) [Link]

> Seems to me like you want postgres to be able to just morph into any other type of database

No, I didn't mean that. I wouldn't want Postgres to add all of those features, because it would be lots of extra complexity to get some "simple" features.

I was pointing out some limitations of current systems (since most people are still in the denial stage, saying "what's wrong with the RDBMS?") The fundamental concept behind the NoSQL movement is "we need new tools in the toolbox", and there are a lot of "new tools" to explore.