Durable Distributed Cache
This video describes NuoDB’s underlying architecture, a memory-centric, peer-to-peer system that ensures ACID compliance, resiliency, and scale-out performance.
In this video, we’ll discuss how the NuoDB architecture drives its ability to support today’s modern, transactional applications. Users expect their applications to be available instantly, on demand, and with little to no latency, so you need a database that is built for the cloud.
NuoDB’s enabling architecture is called the “Durable Distributed Cache,” and it encapsulates the three key concepts that, when taken together, fuel its core capabilities.
So let’s take a look at each of those concepts and figure out how they work in practice.
Distributed: A Peer-to-Peer Database
At its core, NuoDB is a distributed database system made up of independent peers running on multiple hosts, potentially in different data centers.
Peers can be added and provisioned for a specific task - like orchestrating transactions or managing durability. This means that you can independently scale to address database performance requirements, ensure redundancy, or perform real-time analytics.
The NuoDB peer-to-peer architecture lets you deploy a single, logical database and insulate your applications against complexity and failure.
A network of equals
NuoDB database peers communicate using asynchronous messaging and only talk to other peers that are relevant to a given task assigned to them. [meh] This minimizes network traffic.
Designed for resilience
The peer-to-peer system also makes the database resilient. Since no single peer is wholly responsible for a given task or piece of data, any peer can fail or be purposely shut down without impacting service availability. NuoDB can also be configured to automatically bring new resources online when failures occur.
And with NuoDB’s ability to operate as a single database across data centers, peers can easily be added in new geographies based on changing usage patterns.
Cache: An In-Memory Database
Now let’s talk about another important concept - Caching.
NuoDB is based on a memory-centric architecture designed to optimize your database around memory rather than disk.
Every peer has an in-memory cache [in memory cache], and at any time data can be cached in one or more locations.
Typically, a cache [begin request - note: one of these peers should be noticeably further away from the other two] contains a working set of your data. If a peer needs data that’s not in its own cache, it requests it from the nearest peer who has it. This ability to populate data on demand means that NuoDB improves performance by naturally optimizing data locality based on usage patterns.
Ensuring Transactional Consistency
You may be wondering how the system ensures consistency when the data is cached in multiple locations.
Each peer knows the other locations of each data item stored in its own cache and can therefore drive coordination and cache consistency based on that knowledge.
NuoDB uses multi-version concurrency control, or MVCC, to coordinate read/write access to the system.
In-memory database, optimized
NuoDB’s memory-centric architecture means that the database is what’s in memory - not what’s on disk. That means that you can make optimizations to the system - for example around storage, redundancy, and replication - without having to worry about disk I/O.
With NuoDB, database performance, latency, and availability are easily managed by bringing peers online or taking them offline.
This is further optimized by dedicating peers to different tasks. Some peers are used exclusively for transaction processing, while others focus on the third key concept of the Durable Distributed Cache architecture: data durability.
Durable: A Safe, Redundant Database
There are two types of peers, transaction peers and durability peers. When new data gets written to the database, it goes into a transaction peer’s cache. Transaction peers collaborate with durability peers to support ACID semantics. Durability peers ensure that data assigned to them is written to disk and available to other peers on demand.
This is true for existing data as well as new data. For example, when a user changes a data value, the transaction and durability peers continue to coordinate and ensure that the change is replicated not just to the durability peers, where it gets written to disk, but also to other transaction peers that might have that particular data in cache.
Separating database services from data storage allows storage to flexibly balance safety, resource allocation, and cost.
NuoDB also gives you control over how you want to balance performance requirements versus data safety.
For instance, you can add more durability peers, control how many data copies are managed by those peers, and even determine how much of the data set each peer controls.
You can also control your “commit” level. For example, you can require a transaction to be considered committed when it’s written to disk by just one durability peer, or you can require that it not be considered committed until it’s written to disk by all relevant durability peers.
As you’ve seen in this video, NuoDB’s Durable Distributed Cache is a memory-centric, peer-to-peer system that enforces ACID compliance, enables resiliency, and delivers scale-out performance across multiple data centers.
For more information, visit www.nuodb.com.