8 Comments

Summary:

The audacity of a database startup: NewSQL vendor NuoDB dares to propose an update to E.F. Codd’s 12 rules of relational databases, the blueprint for SQL databases for decades.

Barry Morris

NewSQL database startup NuoDB likes to think big. This week as it makes its scalable database generally available, it is also pitching an update to database guru Edgar F. Codd’s 12 rules of relational databases for the age of cloud computing. It’s a move that is bound to raise eyebrows since Codd, an IBM computer scientist who defined the relational database model, is viewed as a god in that arena.

NuoDB CEO Barry Morris (pictured above) seems girded for blowback.”The rules from Codd are intended to be obvious. If [the new rules] were strange or oriented around a particular product, they’d be self-serving, but they’re not. We want to say: ‘let’s stop screwing around with incremental database improvements. If you were to design your own requirements for an ideal 21st century database, what would they be?’ This is what we came up with. What’s missing? We want the conversation.”

NuoDB co-founder and CTO Jim Starkey

NuoDB co-founder and CTO Jim Starkey

Cambridge, Mass.-based NuoDB  was founded by Jim Starkey, a database pioneer who piloted Digital Equipment Corp.’s RdB database (now part of Oracle) and Interbase (acquired by Borland) and is responsible for many object database innovations. He also founded Netrastructure which was acquired by MySQL, the popular open-source database, that is now also owned by Oracle (sorcl). He is now listed as founder and senior advisor to NuoDB. He also used to be CTO.

A cloud database management system, according to NuoDB, is a superset of the tried-and-true relational model. Below is a truncated version of  NuoDB’s 12 rules of Cloud Database Management System (CDMS). The unabbreviated list is here.

1. Elastic Scale-out for Extreme Performance
A CDMS must deliver capacity on demand by adding/deleting computational and storage resources in a running database.  It must be able to handle very high transaction volumes and petabytes of data as needed and scale back “gracefully” when those resources are no longer needed.
2. Single Logical Database
A CDMS must present its users the view of a single, logical, consistent and always available database, no matter how complicated the application.
3. Run Anywhere, Scale Anywhere
A CDMS must be able to run on any infrastructure from single machines to private clouds, public clouds and combinations of the above and must be able to run in a heterogeneous environments.
4. Nonstop Availability
A CDMS must be able to running continuously — for months or years — without failing or being made unavailable for maintenance.
5. Dynamic Multi-tenancy
A CDMS must be dynamically multi-tenant and be able to manage large numbers of databases on a finite set of resources, and to reassign resources to databases as needed.
6. Active/Active Geo-distribution
A CDMS must be able to run concurrently in multiple data centers to support geographically distributed workloads, always-on applications, and for disaster recovery.
7. Embrace Cloud
A CDMS must integrate and run in a cloud environment, and designed to support cloud-scale performance requirements while being resilient against the inherent concurrency and latency challenges.
8. Store Anywhere, Store Redundantly
A CDMS must be able to store the data locally, remotely, in a data center or on a public or private cloud and in whatever storage system is appropriate.
9. Workload Mix
A CDMS must be flexible in the kinds of workloads it supports, and to efficiently run different workloads concurrently.
10. Tunable Durability Guarantees
A CDMS must allow a user to define infrastructure reliability constraints that control the trade off between durability guarantees and database performance.
11. Developer Empowerment
A CDMS must support rapid application development and frictionless application evolution. It should be easy to use without need for time-consuming provisioning requirements.
12. Admin Empowerment
A CDMS should provide a single, secure point of administration for all its databases and resources. It should make it simple to automate logging, auditing, profiling, process management and resource allocation.

Matt Aslett, a research manager for The 451 Group who has spent a good deal of time mapping out the modern database scene, said NuoDB, which promises to bring the strengths of a relational SQL database to highly distributed webscale computing, competes most directly with offerings like GenieDB and in some cases VMware’s SQLFire.

He agreed that NuoDB is making an aggressive statement with its list of rules but that it does so from a credible place. “The NuoDB guys are the real deal. There will be an element of skepticism for any company that claims to do fully-distributed ACID SQL database, but if anyone has the expertise to do this, Jim Starkey is one of those people.”

ACID stands for  “Atomicity, Consistency, Isolation, Durability.” Relational databases must offer this capability — which ensures that transactions are performed reliably and accurately. That’s an obvious requirement for modern  e-commerce applications, where every transaction relies on the accuracy of the entire data set.

What will database gurus think of this new list? I’m not sure but would love for them to sound off in comments.

  1. Seems like a tall order, and I wonder whether it is a violation of natural laws to have a geographically distributed database that offers both high performance and also traditional SQL-style transaction integrity. Hats off if they can do this, but usually there is a tradeoff along one of these axes.

    Share
    1. You are correct that these are difficult problems to solve, but NuoDB has fundamentally solved them. What NuoDB has done is put in place a peer-to-peer, asynchronous, distributed architecture that addresses fundamental issues such as “how can you maintain ACID guarantees across a network of computers, data centers located in different geographies, etc.”

      Share
  2. This is the 21St century database

    Share
  3. Some questions to Nuo:
    How can you guarantee a globally consistent state of a distributed database using asynchronous messaging?
    How do you deal with transactional conflicts?

    You can not get high performance if you support ACID transactions in a distributed database system. The reason for many NoSQL databases to only support some relaxed consistency requirements, like eventual consistency, is to get a system which can scale horizontally without drawbacks on performance.

    To guarantee global consistency in a distributed database system you need to synchronize all parallel transactions, and the cost of synchronization becomes larger the further away from each other the different parallel transactions are executed. Consequently you get better overall transactional throughput by running all parallel transactions in RAM on the same computer, which is how transactions are managed in the Starcounter database.

    Share
  4. Tom Lovegrove Monday, January 21, 2013

    Forget the technology for a moment, if Greg Fegan is motivated to get back in the game, he can scale NuoDB in his sleep

    Share
  5. Jim Robertson Monday, January 21, 2013

    Tom, I’d have to agree Fegan is one of the best sales guys this industry has seen in 30 years- one tough mother

    Share
  6. Andy Rightshouse Monday, January 21, 2013

    Well we have taken the subject matter off product, but 3 times a charm, if I were selling databases and knew Fegan was competing with me, I’d find another profession. He can charm the skin off a snake.

    Share
  7. When NuoDB hired Fegan they told the market game on- this a ticket you cant buy

    Share

Comments have been disabled for this post