In this 6 minute recorded webinar, GenieDB chief architect Alaric Snell-Pym discusses NoSQL vs SQL
There are other frustrations with SQL, too; it can be limiting. SQL is a declarative, where one specifies what one wants, not how to get it. This is great for those architects and urban planners, but it means that the
SQL server has to formulate a ‘query plan’ from your query, deciding how it’s going to do it. Sometimes it fails to produce a good one, and performance is disappointing. So a skilled (expensive) breed of advanced database programmers come along, second-guess the query planner, and write contorted queries designed to trick the server into coming up with the query plan you actually wanted. It would be much easier if you could bypass it, and just tell it a query plan. And SQL is based on rigid schemas for tables, which can make it hard to upgrade a running system without downtime.

So NoSQL began to rise again; re-inventing the database for modern demands. There’s a lot of different ideas under the NoSQL banner; sometimes they have simpler data models than SQL, and sometimes more complex; but they are mainly more flexible data models, to ease those live upgrades. But most importantly, NoSQL applications usually make less assumptions about the behaviour of the database; so the database has more leeway to do things differently. “Eventual consistency” is an oft-heard term in the NoSQL world - as it makes replication easier, and makes it possible for the system to operate on a best-effort basis in the face of network partitions. Often, there are no transactions. Generally, though, the “ACID properties” that have underpinned database theory for decades are being reconsidered in the light of the cost of implementing them in a fault-tolerant distributed environment.

But it’s a trade-off. The new NoSQL engines are, by definition, new. They’re short on features. They’re not polished, and comfortable to use. They have new interfaces, and new models of working, that need learning.

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.

But it’s SELECT that’s the best thing about SQL!

NoSQL engines abandon SQL for the chance to have more flexible data models and softer semantics for update operations - but they also abandon it because it’s a lot of work to implement. And, creating a new database from scratch, they’re keen on solving the interesting hard problems (such as replicated data storage), rather than following the well-trodden path of writing SQL parsers and query planners, with a few decades of catching up with the competition ahead of them.

Sure, being able to run your own query plans is nice, because having to second-guess the SQL query planner to get decent performance sucks. But there’s no reason why SQL databases couldn’t expose lower-level interfaces, to let you do that alongside normal SQL queries. The rigid schemas of SQL are a little harder to change, but there’s ways (such as using views).

And the problem with INSERT/UPDATE/DLETE/CREATE/DROP isn’t with their syntax; just with the application expectation that they operate instantly and transactionally on a single global state.

There’s no reason why a scaleable flexible fault-tolerant replicated database can’t be used with SQL. Therefore, I predict that, as they mature, “NoSQL” engines will change - into “NearlySQL” engines.

About GenieDB

GenieDB offers a fully replicated distributed database that is both a MySQL storage engine and a high-speed key value data store. It provides SQL and NoSQL functionality with inter-table joins to help application developers use the database more effectively and efficiently. Our patent-pending replication technology provides instantaneous consistency across a cluster, increases read/write performance and supports almost linear scaling.

view the cloudbook profile for GenieDB >>

About Alaric Snell-Pym

Chief Software Architect at GenieDB

Alaric is the Chief Software Architect of GenieDB, a fully replicated distributed database that provides SQL and NoSQL functionality with inter-table joins to help developers use database more effectively and efficiently. He has designed distributed systems and worked on high-load and large-scale server clusters for over 15 years. His experience ranges from implementing low-level SQL optimization to developing peer-to-peer media distribution technologies. He is a freelance technical editor and author for QUE Books.

view the cloudbook profile for Alaric Snell-Pym >>

Cloudbook Journal
Vol 1 Issue 2, 2010

This article is featured in the
Vol 1 Issue 2, 2010 of the
Cloudbook Journal

Find more Stories from this Issue >>