NoSQL Benchmarks NoSQL use cases NoSQL Videos NoSQL Hybrid Solutions NoSQL Presentations Big Data Hadoop MapReduce Pig Hive Flume Oozie Sqoop HDFS ZooKeeper Cascading Cascalog BigTable Cassandra HBase Hypertable Couchbase CouchDB MongoDB OrientDB RavenDB Jackrabbit Terrastore Amazon DynamoDB Redis Riak Project Voldemort Tokyo Cabinet Kyoto Cabinet memcached Amazon SimpleDB Datomic MemcacheDB M/DB GT.M Amazon Dynamo Dynomite Mnesia Yahoo! PNUTS/Sherpa Neo4j InfoGrid Sones GraphDB InfiniteGraph AllegroGraph MarkLogic Clustrix CouchDB Case Studies MongoDB Case Studies NoSQL at Adobe NoSQL at Facebook NoSQL at Twitter



NoSQL vs SQL, Why Not Both?

Alaric Snell-Pym[1]:

But there’s no real reason why an SQL SELECT statement is difficult to implement in a replicated environment. After all, you can just run that SELECT on a nearby replica. It’s only INSERT/UPDATE/DELETE/CREATE/DROP that cause problems, because SQL comes with the expectation that those operations occur instantly upon a single global state.

Add to the list of problematics queries sub-SELECTs, JOINs and I’m not sure what remains can still be called SQL.

Also a replicated system is not necessarily equivalent to a sharded system where implementing even the simplest forms of SELECT becomes more difficult.

While from an adoption point of view (including developers’ familiarity with SQL, tooling support, existing expertise), supporting SQL makes a lot of sense, there are too many problems to be solved until it would get to a decent level. All these limitations would just be frustrating to everyone.

Sometimes it’s much better to start with a clean solution and determine over time if an integration/standard is emerging. Most practical and long lived standards out there are coming from real-live battle proven scenarios/experience.

  1. Alaric Snell-Pym: Chief Software Architect of GenieDB  ()

Original title and link: NoSQL vs SQL, Why Not Both? (NoSQL databases © myNoSQL)