Couchbase Advances Case for Becoming Your System of Record
By making its database look and behave more like a traditional relational database with today’s launch of Couchbase Server 7.0, Couchbase is giving companies a reason to leave their Oracle systems and power their most important transactions with its NoSQL database.
While there are over 30 new features in Couchbase Server 7.0, there are really two that stand out: support for multi-document SQL transactions, and the addition of scopes and collections in the schema-less JSON document store.
Couchbase CTO Ravi Mayuram gave Datanami the low-down on what the updates mean for customers. Let’s start with support for multi-document SQL transactions.
Multi-Document SQL Transactions
Since Couchbase is a document-oriented database, the data ultimately is stored in a series of JSON documents. That is not changing with this release, although the way that companies can ultimately manipulate that JSON data–through SQL–is changing.
From the very beginning, the Couchbase database has supported single-document ACID transactions. This provided developers the capability to retrieve data using PUTS and GETS through the standard API. They could also use Couchbase’s N1QL query language, which exposes a SQL syntax to the outside but connects directly to the document store on the inside, to fetch data from the JSON documents.
With the launch of Couchbase Server 6.5 in early 2020, the company (which went public last week) added support for multi-document ACID database transactions. This provided customers with the confidence to push more of the complexity inherent with serving transactions onto the database itself, instead of requiring the developers to account for it in the application. Again, this primarily impacted API access to the database.
Now with 7.0, Couchbase has added multi-document SQL transactions to N1QL while adhering to the ACID precepts of atomicity, consistency, isolation, and durability that has been the standard for transaction-oriented databases for decades. This is a significant change because it allows customers to take the SQL statements they have already developed for a variety of existing applications, and run them straight against the Couchbase database, Mayuram says.
“Earlier, you could get to the JSON documents using the API–GET, SET, UPDATE, that kind of stuff,” he says. “Now [you can do] the data manipulation part using SQL transactional semantics.”
The update is important, Mayuram says, because it allows Couchbase Server to handle the complexity inherent with active transactional systems in the same manner that customer have grown accustomed to with Oracle, SQL Server, and Db2 databases, but without giving up the flexibility that’s inherent with a distributed, schema-less database.
The hard part for Couchbase developers was to expose the transactional semantics and maintain those ACID guarantees while the database underneath is being constantly hammered by API requests, N1QL queries, and now SQL statements.
“Your schema is changing, new tables are being created, some tables are being updated, something is being deleted, we’re adding more capacity, and the data is actually being moved– yet the transactional guarantee is maintained for you,” he says. “The system could be in tumult underneath, yet we manage it for you.”
Couchbase offers a more in-depth description of SQL transactions in its blog.
Scopes and Collections
The second major new feature–the addition of scopes and collections–is important for a similar reason.
In a relational database, the ontology of the data structure, from general to specific, goes as follows; database to schema to table to row to column. This is how database administrators and developers are accustomed to thinking about their data.
In Couchbase, the ontology has been much simpler. According to Mayuram, there was the database, a bucket, and a document. “And we are schema-less, so it did not have to be anything more complicated than that,” he said.
Things are getting a little more nuanced in Couchbase Server 7.0 with scopes and collections, which directly correspond with schemas and tables.
“In the Couchbase ontology now, you have bucket, then you have scope, then you collections, then you have documents, and inside the documents, you have keys,” Mayuram says. “So there is one-to-one mapping…so people don’t have to think too much to figure out, how do I map this?”
Bringing It Together
Ultimately, support for multi-document SQL transactions and scope and collections are important because they lower the amount of development work required to move from a relational database to the document database, while simultaneously increasing the familiarity that developers feel towards the NoSQL database, Mayuram says.
“If you know how to drive a car, you can give them a Tesla [and they can drive it],” he says. “It’s just when you open the hood, you see all the differences. There is no internal combustion engine, none of that stuff. That’s what we want to achieve, because underneath the covers, it’s a totally different system. A document-based system is very different from a relational, tuple-based system. But we have put the rigor behind it in terms of using the right computer science theory, with the generalized relational algebra and the distributed transaction work we had to do to get that right.”
In the past, Couchbase spoke of being the database for the systems of engagement, those new Web and mobile applications that power all the user interactions that occur before the user is read to hit the “buy” button and complete a transaction, for example. The ratio of these interactions to a traditional transaction was 1,000 to 1, the company said.
Since traditional databases were ill-equipped to handle that volume, they adopted NoSQL systems like Couchbase to handle them. Yet the stakes were much higher with that credit card transaction, and so customers kept the traditional relational databases, which offered the ACID guarantees that they (and their banks) needed.
Now that Couchbase can offer those guarantees–it has also adopted the Raft consensus algorithm to keep data in synch as it moves between geographically distributed nodes–the company is targeting the more valuable transactions. It expects the volume of migrations off Oracle to its NoSQL database to accelerate because of it.
“This gives you the transactional guarantees to become the system of record for enterprise-grade applications with the least amount of effort, or without requiring you to reprogram the application,” Muyuram says. “We give you those familiar guarantees, and the necessary guarantees to say your data is going to sit in the disk, no matter what happens around that. That’s the guarantee you actually need for you to become a system of record.”