Introduction to NuoDB
NuoDB has an interesting NewSQL story. NuoDB’s core design goals seem to be:
- SQL.
- Transactions.
- Very flexible topology, including:
- Local replicas.
- Remote replicas.
- Easy deployment and management.
Please don’t blame me for various annoying aspects of NuoDB’s marketing; they only became a client this month.
Key aspects of NuoDB’s architecture include:
- A modular approach, which seems to fall somewhere between true object-orientation and Spark RDDs.
- Much tiering.
- Very optimistic execution.
Less unusual technical highlights include:
- MVCC (Multi-Version Concurrency Control).
- B-trees.
- Some kind of tokenized compression (but data is decompressed for execution).
- Encryption across the network.
Online schema change is in the mix as well.
The heart of NuoDB’s design seems to be the optimistic execution. Highlights include:
- Any change to data is immediately propagated to all replicas, throughout the system, straight down to disk.
- Commit messages eventually say “Yeah, we’re good to go; commit that.”
- Conflicts are unwound via timestamps.
Consequences include:
- NuoDB doesn’t guarantee consistent state of the database; it merely guarantees database consistency in response to any kind of request. (This is akin to the philosophy behind RYW consistency.)
- The synchronous parts of network communications are very lightweight.
NuoDB’s consistency, by the way, is tunable. Commits can require:
- Acknowledgement by N different storage engine copies that persistence has happened (pretty much the traditional approach).
- Acknowledgement by K different transaction engine copies that the change is in RAM (what the cool kids are doing).
NuoDB’s modularity story starts:
- Everything — data, indexes, metadata, whatever — is chunked into “atoms” of 50Kb or so.
- There are common services to do things like replication of atoms.
- NuoDB speaks, inaccurately, as if the atoms actually carry their own logic; this seems to be the basis for various soaring metaphors about emergent flocks of birds.
Traditionally, DBMS have one tier. Exadata, MarkLogic, and InfiniDB — among others — have two to three each. NuoDB, however, effectively has four:
- A lightweight load balancer (just like any other peer-to-peer system), which travels with …
- … “transaction engines” that:
- Talk with clients.
- Parse and plan SQL.
- Manage distributed transactions.
- Cache data.
- Etc.
- “Storage managers” that manage persistence, with the help of …
- … “key-value stores”, a term NuoDB uses loosely but reasonably to encompass your choice of:
- A lightweight, proprietary NuoDB key-value store.
- Amazon S3.
- HDFS (Hadoop Distributed File System).
- Presumably more options later on.
The most counterintuitive part of this is probably that one instance of a storage manager can talk to a whole key-value cluster (e.g. one managed by HDFS); thus, this is not a classic shared-nothing nor sharded (transparently or otherwise) approach. Rather, each NuoDB storage manager sees the whole database.
Seeing only part of the database isn’t an option in NuoDB Version 1; hence, compliance-oriented geo-partitioning isn’t supported at this time.
Paradigmatically,
- NuoDB transaction engines and storage managers run on different machines.
- Each database has its own transaction engines and storage managers; transaction engines for different databases can run on the same machine.
- Replication factors can be different for different databases.
- Local replication gives high availability and elastic scale-out.
- Remote replication gives disaster recovery.
Wrinkles include:
- Transaction engines and storage managers have very similar code.
- You could run everything on one machine if you really insisted.
- Conversely, NuoDB fondly thinks that it makes sense to run transaction engines on the same machines as your application servers. (I’m more skeptical, since app servers and DBMS are both heavily consumptive of RAM.)
And finally, NuoDB company highlights include:
- 25 employees.
- Single-digit number of production customers.
- VCs who were previously CEOs of Relational Technology/Ingres (Gary Morgenthaler), Illustra (ditto), and Sybase (Mitchell Kertzman).
NuoDB took a “rolling thunder” approach to launch, so product news is already out, but some customer wins and internal benchmarks are being held back for a press event next week.
Bottom line: No new DBMS could possibly justify NuoDB’s hype. But NuoDB is an interesting new product for the cloud era.
Comments
5 Responses to “Introduction to NuoDB”
Leave a Reply
[…] NuoDB evidently subscribes to the marketing fallacy: […]
[…] who has NuoDB as a client, has been given a look under the hood, and has analyzed NuoDB's architecture and claims, concludes that "no new DBMS could possibly justify NuoDB's hype. But NuoDB is an […]
[…] NuoDB and GenieDB probably lean that way. (And SanDisk evidently shut down Schooner’s RDBMS while […]
[…] that I’ve addressed some new NewSQL entrants, namely NuoDB and GenieDB, it’s time to circle back to some more established ones. First up are my clients […]
[…] has brutally low “vision” rankings for NuoDB and Clustrix. I think scaling out SQL effectively is more impressive than that. Gartner also omits […]