The landscape for database management systems is changing more rapidly these days than it has since the earliest days of the relational DBMS. Not only do we have an onslaught of NoSQL database systems of various different forms (column, document, key/value, and graph databases), but we also see a burgeoning market for in-memory database management, where the DBMS relies on main memory instead of disk for data storage, management, and manipulation. But there is another “category” of DBMS evolving that is known as “NewSQL.”
The term NewSQL is confusing and not very well-defined. Basically, NewSQL DBMSs are typified by relational, SQL database systems with distributed, fault-tolerant architectures. In-memory capability is an additional feature typical of NewSQL offerings, as are clustered database services with the ability to be deployed in the cloud. NewSQL DBMS products may have fewer features and components, with a lighter-weight footprint, making them easier to support and learn than legacy relational offerings.
Of course, the features mentioned here are not exclusive to NewSQL database systems, nor are all of them required to be considered a NewSQL product. Many existing RDBMS products support many of these features.
Generally speaking, NewSQL database systems are designed to combat the onslaught of NoSQL using relational technology. The type of applications designed to benefit from a NewSQL DBMS will usually have a large number of short transactions that access a small amount of indexed data and execute repetitively. Clearly, that is a large subset of applications (but by no means all applications). The goal of NewSQL is to deliver high availability and performance to modern data without sacrificing the robust consistency requirements and transaction capabilities that NoSQL frequently skimps on.
In other words, NewSQL DBMSs deliver ACID transactions. ACID is an acronym for atomicity, consistency, isolation, and durability. Each of these four qualities is necessary for a transaction to be able to ensure the integrity of data:
- Atomicity means that a transaction must exhibit “all or nothing” behavior. Either all of the instructions within the transaction happen, or none of them happen. Atomicity preserves the “completeness” of the business process.
- Consistency refers to the state of the data both before and after the transaction is executed. A transaction maintains the consistency of the state of the data. In other words, after a transaction is run, all data in the database is “correct.”
- Isolation means that transactions can run at the same time. Any transactions running in parallel have the illusion that there is no concurrency. In other words, it appears that the system is running only a single transaction at a time. No other concurrent transaction has visibility to the uncommitted database modifications made by any other transactions. To achieve isolation, a locking mechanism is required.
- Durability refers to the impact of an outage or failure on a running transaction. A durable transaction will not impact the state of data if the transaction ends abnormally. The data will survive any failures.
So, a NewSQL DBMS is relational, delivers ACID, and offers modern capabilities and a modern architecture. And, of course, it uses SQL to access and modify data.
Although there is no rule book for what constitutes NewSQL, there are several different types of systems that utilize the moniker NewSQL. Most commonly, NewSQL refers to a completely new RDBMS product that operates in a distributed cluster of shared-
nothing nodes, with each node owning a subset of the data. By designing the NewSQL RDBMS from scratch, the code can be expressly written for a distributed architecture and avoid some of the overhead of the traditional RDBMS. Examples of NewSQL products include VoltDB, Clustrix, MemSQL, and Translattice.
The term NewSQL can also apply to SQL storage engines such as Infobright and transparent sharding systems such as ScaleBase.
The Bottom Line
NewSQL technology is one of several trends impacting the DBMS landscape circa 2015. As DBAs, we need to understand and embrace NewSQL to help our organizations and clients utilize the technology where and when it makes sense.
Be careful, though, of using the term “NewSQL” to differentiate or categorize database technology, because there are no hard-and-fast rules that dictate what NewSQL is, or should be.