We looked at the basic differences between NoSQL and NewSQL in a recent post. Now let’s break the differences down specifically by looking at what developers really care about:
- Which problems can I solve with NoSQL?
- Equally important, where is NoSQL a bad fit?
- Where do different approaches – NoSQL and NewSQL – show their strengths?
Don’t get us wrong – NoSQL databases are great for lots of workloads and applications, but in four areas the weaknesses of NoSQL are pronounced.
This post will discuss those four areas, and identify use cases where NoSQL technology might not be the best choice.
NoSQL offerings began to attract attention when they were implemented to address the scalability requirements of web-native companies such as Google, Facebook and Twitter. These organizations were dealing with vast inflows of unstructured data from myriad sources: web searches, mobile devices, user status updates, streams of comments.
In these use cases, the most important consideration was scalability: the database had to scale out massively. The relational schema and challenge of scaling traditional SQL databases was seen as restrictive, and when cost was considered in either dollars or development effort of scaling legacy RDBMSs, using these systems was seen as prohibitive.
The key feature NoSQL systems brought to the development community was the ability to scale applications on inexpensive commodity hardware. If your use case requires horizontal scale-out for unlimited data feeds, NoSQL may be the right choice – unless you want to take action on the data in real-time.
While legacy relational database systems offer scaling options – at an often-significant cost – NewSQL systems were designed to address this same scalability challenge, all while maintaining the transactionality and SQL-standard interactivity of legacy RDBMSs.
One example is an in-memory, massively parallel, SQL relational database that scales out linearly on inexpensive commodity hardware. Like NoSQL solutions, NewSQL databases should be cloud-friendly and able to scale to meet the demands of web-scale applications. These systems should be designed for low latency high read/write performance, using a shared-nothing, cluster-native, cloud-friendly architecture. They need to provide high availability and fault tolderance, as well as geographic redundancy. Spoiler alert: VoltDB does all these things. With VoltDB, you can build transactional, database-oriented applications against data feeds that were previously limited to stream processing systems.
NoSQL systems are designed for availability, CAP-theorem style. Availability means the database is always responsive, even in the event of network partitions. NoSQL systems by design prioritize availability over strong consistency (i.e., always correct, exact answers). These systems will return an answer, even if the answer is not the most current at that given instance in time.
This design decision, made famous by Apache Cassandra, was based on the belief that it is less important to be immediately correct than it is to always return a response and/or accept new data.
For example, if your Twitter follower list is not displayed exactly correct at that moment, that is ok. It is better to display something that is not exactly correct but is the same for all clients rather than to display nothing at all. Eventually the answer will be correct for all clients.
For many applications, eventual consistency is acceptable. However, when you need to make immediate decisions, or transactions on exact answers, you will need a different solution.
Eventual consistency and thus NoSQL solutions are a poor fit for the following types of applications:
NewSQL systems favor consistency over availability. A NewSQL system will return the same exact answer to all clients – it won’t return different answers. This allows your applications to make decisions, for example on money, airplane seat assignments, inventory, etc., and to know there won’t be conflicts.
VoltDB, for example, is a strongly-consistent NewSQL database. If you have a use case that requires speed, scalability and always-correct, ACID-compliant transactions, VoltDB is pretty much the only game in town. No NoSQL offerings can make the same assertion.
Consistency (e.g., ACID-compliant transactions, correct answers)
NoSQL systems were architected for availability (see above). That choice meant they couldn’t deliver ACID-based, strong consistency. With CAP, three pillars are described – Consistency, Availability, and Partition tolerance. Brewer’s Theorem (aka the CAP theorem) states you can have two, but not all three of these properties.
Thus NoSQL systems are AP – they are Available, and Parition-tolerant. This makes NoSQL a poor choice for applications or use cases where strong consistency is required:
- Rights management, operations support (telco);
- Last dollar (adtech, gaming);
- SLA management, session management
- Trade verification, fraud detection, bid & offer management and
- Sensor management.
Here’s a more practical way to think about CAP: In the face of network partitions, you can’t always have both perfect consistency and 100% availability. Plan accordingly.
Strongly consistent systems such as VoltDB are CP. They choose Consistency (C) over Availability (A). They also provide Partition-tolerance (P).
Of all NewSQL solutions, VoltDB is the most robust and resilient in the face of many failure scenarios. We’ve been validated independently by Kyle Kingsbury’s Jepsen testing. We’ve seen customers with production clusters with uptime measured in years.
As you might expect from the above, VoltDB excels in applications or use cases where strong consistency is required:
- Rights management, operations support (telco)
- Last dollar (telco, adtech, gaming)
- SLA management, session management (telco)
- Trade verification, fraud detection, bid and offer management (financial exchanges), and
- Sensor management (IoT).
Fast Transactional Applications
Today, modern, request-response style applications happen at high volume. While NoSQL solutions often provide datastore speed, they cannot provide strongly consistent transactions at scale.
Applications requiring scalable transactions include:
- Allowing a mobile call to connect while verifying the user’s balance;
- Placing a trade at the best offer price;
- Presenting a mobile ad to potentially thousands of users without blowing through an advertiser’s ad budget;
- Managing tight SLAs for telco providers; or,
- Detecting a fraudulent card swipe before the transaction is approved.
NoSQL databases are generally not the right choice for these types of applications.
These events occur millions of times a day, even millions of times per hour (or even second) all over the world. Businesses in telco, financial services, online gaming, adtech and other industries need to be able to accommodate the varying volume and velocity of these events. They need a scalable, transactionally-consistent solution.
NewSQL Fast Transactions
ACID transactions are a requirement for request-response applications – and because NewSQL systems are relational ACID-based databases, they support ACID transactions. Coupling scalability, strong consistency and the ability to transact on data at scale, NewSQL systems provide the capabilities for modern applications.
Building Scalable Modern Applications with NewSQL
Both NoSQL and NewSQL technologies provide datastores on which highly scalable applications can be built. NoSQL datastores are a great choice for appliactions where availability – getting a response – is valued more highly than getting a consistent, correct response at all times. NewSQL systems provide applications with scalability as well, and also offer strong consistency and transactional interaction, favoring consistency over availability in failure scenarios.
While nearly all NoSQL solutions deliver scalability, VoltDB delivers on scalability and adds strongly consistent transactions; further, few can NoSQL solutions match VoltDB’s combination of blazing speed, transactional consistency and scalability.