03/30/20

Top 10 FAQs from KubeCon 2019 in San Diego

WHAT DOES NUODB DO?

TL;DR: NuoDB is a distributed SQL database

NuoDB is a SQL database, it is fully transactional, fully ACID, and fully consistent. This is a stark contrast to NoSQL solutions that have emerged in the last decade.

NuoDB is distributed, meaning that it is able to scale horizontally and automatically keeps multiple replicas in sync. Having multiple replicas of a database is a strict requirement for any service having 99.99% or better availability guarantees.

Continue reading
If you enjoyed this post, then make sure you subscribe to my Newsletter and/or Feed.

Facebooktwitterredditpinterestlinkedin
03/23/20

What Does Distributed SQL Really Mean?

The world is moving to the cloud and various post-monolithic SQL databases are emerging. The term “NewSQL” was coined by 451 Research analyst Matt Aslett in 2011, and in 2016 Aslett and Professor Andrew Pavlo of Carnegie Mellon University published a paper titled, “What’s Really New with NewSQL,” describing NewSQL as a new class of database management systems that “want to achieve the same scalability of NoSQL DBMSs from the 2000s, but still keep the relational model (with SQL) and transaction support of the legacy DBMSs from the 1970-80s.” NuoDB was founded in 2010 based on this idea, and has been an important player in the distributed relational database space since then. For a while, this concept was referred to as “scalable SQL,” and we’ve also seen reference to “elastic SQL.” More recently, we’ve seen a new term emerge: “distributed SQL.” 

Let me explain why all of these terms refer to essentially the same thing, although the ways that different databases achieve that scalability while maintaining consistency varies. As more and more companies started providing SaaS offerings that had no downtime, a pattern of pain points emerged:

  • A monolithic database cannot provide the resiliency and high availability guarantees required by modern always-up, always-available applications. 
  • Scaling up is no longer viable. Machines big enough to run these types of workloads become too expensive, too quickly.
  • NoSQL is not well suited for applications that require strong transactional and ACID guarantees.
  • Explicit sharding is too complex and diverts engineering resources from what matters most: the business.

We’ve seen technologies come and go, but the same four fundamental motivations that are aligned with the shift to the cloud remain unchanged. NuoDB has been here since the beginning, and we continue to help our customers alleviate these pains.

Continue reading
If you enjoyed this post, then make sure you subscribe to my Newsletter and/or Feed.

Facebooktwitterredditpinterestlinkedin
04/3/19

Distributed Transactional Locks

As I explained in a previous blog post, sometimes MVCC is not sufficient and an operation needs to block out all other concurrent modifications. NuoDB is able to lock three types of lockable resources: tables, schemas, and sequences. A resource can either be locked in SHARED mode (which still allows record modification, but no metadata modification) or EXCLUSIVE which prevents any concurrent modification.

EXCLUSIVE access is required for DDL that visits all records (various index operations for example) and distributed concurrent access is not possible. Exclusive access can also be used by operations that need to work around MVCC write skew anomalies.

SHARED locks need to be fast, consume as little memory as possible, involve no additional nodes in the cluster, and cause no additional messaging.

EXCLUSIVE locks, on the other hand, need to pay the cost.

MVCC uses row locks to serialise updates to a single record. Both transactional locks and row locks participate in the same deadlock detection process, but are otherwise independent. The following table explains the interaction between transactional locks and MVCC row locks. If you are interested in how row locks work, I recommend reading our MVCC blog series.

Row Locks (DML) / Transactional LocksSharedExclusive
selectNo ConflictNo Conflict
insert, update, delete, select for updateNo ConflictConflict
Continue reading
If you enjoyed this post, then make sure you subscribe to my Newsletter and/or Feed.

Facebooktwitterredditpinterestlinkedin
04/3/19

How Transaction Locks support Zero Overhead Distributed DML

Let us imagine a scenario that needs to prevent MVCC write skews…

One transaction increases the salary of everyone in a department by 10%; another transaction inserts a new employee with a salary X. Since the two transactions do not conflict, MVCC does not prevent either of them from committing. After both resolve, the overall salary in the department could be above the budget. To prevent a similar situation, the application developer might want to have exclusive access to the table.

NuoDB 3.2.2 exposes a new type of lock that guarantees exclusive access to a resource across the distributed cluster. We call them Transactional Locks and they are the underlying mechanism powering the new NuoDB LOCK statement.

Continue reading
If you enjoyed this post, then make sure you subscribe to my Newsletter and/or Feed.

Facebooktwitterredditpinterestlinkedin
08/2/18

Why A Chairman Ain’t the Master Replica

INTRO

As a distributed, ACID-compliant database, we get a lot of questions about how NuoDB works, and how it compares to more well-known architectures. In particular, people want to understand how NuoDB compares to a master / master architecture, and (related) how we handle lock management. This post will discuss both. We will also discuss when shared-nothing architecture is viable and when conflicting decisions need to coordinated.

In this blog post, we will discuss the concept of Chairmanship, NuoDB’s answer to distributed coordination. We will prove that Chairmanship is both consistent and resilient to failure. But before we go into the details, let us explore the basics of NuoDB architecture.

Continue reading
If you enjoyed this post, then make sure you subscribe to my Newsletter and/or Feed.

Facebooktwitterredditpinterestlinkedin

07/5/18

Quick dive into NuoDB Architecture

Introduction

Traditionally, relational databases were designed for scale-up architectures. Supporting more clients or higher throughput required an upgrade to a larger server. Until recently, this meant that implementing a read & write scale-out architecture either required a NoSQL database and abandoning traditional relational database benefits, or relying on sharding and explicit replication. There were no solutions that could scale-out and still provide complete ACID (Atomicity, Consistency, Isolation, and Durability) -compliant semantics. This tension is what inspired the NewSQL movement and ultimately led to today’s modern “elastic SQL” databases.

NuoDB is an elastic SQL database designed with distributed application deployment challenges in mind. It’s a full SQL solution that provides all the properties of ACID-compliant transactions and standard relational SQL language support. It’s also designed from the start as a distributed system that scales the way a cloud service has to scale, providing high availability and resiliency with no single points of failure. Different from traditional shared-disk or shared nothing architectures, NuoDB’s patented database presents a new kind of peer-to-peer, on-demand independence that yields high availability, low-latency, and a deployment model that is easy to manage.

This article highlights the key concepts and architectural differences that set NuoDB apart from traditional relational databases and even other elastic SQL databases.

Continue reading
If you enjoyed this post, then make sure you subscribe to my Newsletter and/or Feed.

Facebooktwitterredditpinterestlinkedin