Top Questions Asked About the NuoDB Distributed SQL Database Architecture
When people first hear about NuoDB, they immediately understand the benefits of our core features. Whether they’re attracted to scale-out performance, continuous availability, multi-tenancy, or something else entirely, they want to believe it can perform “as advertised.”
Not surprisingly, however, they are naturally skeptical, and as a solution architect, I’m often asked a number of detailed questions about how it all works. Most of those questions are thoroughly answered in our documentation or tech blog. Here, in one place, is an index of some of the most common questions we get asked, and the answers to some of the most useful information.
- So how does NuoDB work, exactly?
- How can a distributed database deliver speedy performance?
- How can you maintain consistency across updates to multiple nodes? (AKA What the heck is Multi-Version Concurrency Control?
- How do you control the visibility of a given transaction?
- To what degree can you control durability?
- So what happens when you have a conflict?
- What about Consistency, Availability and Partition Tolerance? What’s your view on the CAP Theorem
One of the other questions we get most often involve managing distributed updates. How can we actually support active-active updates to a distributed database, while claiming ACID compliance? Some of this has been answered in the links above, but beyond the “basics”, this question is further qualified by network problems that prevent transaction control messages from being exchanged (AKA network partitioning).Understanding how everything else works first is critical to understanding network partition management. The way we currently handle this is innovative and works well for many classes of applications. There’s always room for improvement, though, and we’re currently working toward a solution that will take this a step further by healing partitions after network failure.