Operational Databases

We regard operational processing as a superset of transaction processing. The principle difference from a database management perspective is with respect to the consistency of your processes. In our view – others may disagree – genuine transactions require immediate consistency while operations can leverage eventual consistency. This needs to be explained.

Apart from performance and other generalised considerations the major requirements for transaction processing – as opposed to operational processing – are so-called ACID properties and, typically, support for XA-compliant two-phase commit (where an XA compliant driver is a driver that can participate in an XA compliant transaction as defined by the X/Open specification). The former are properties that ensure that transactions are processed reliably, and the latter specifically supports atomicity (the A in ACID), ensuring that all transactions are either completed in full or rolled back.

However, consistency is a fraught issue when it comes to discussing distributed NewSQL and NoSQL databases, because of the CAP (consistency, availability and partition tolerance) theorem. While ACID provides guarantees about the processing of transactions within a database, the CAP theorem, also known as Brewer’s theorem, states that in a distributed data store you cannot guarantee all elements of CAP and, in particular, you can have availability guarantees or consistency guarantees but not both. Note that this isn’t an issue when the cluster is running normally.

One difficulty that arises is that the “C” for consistency in ACID is not the same as the “consistency” in the CAP theorem, which actually stands for “atomic consistency”. As the authors of the CAP theorem state: “discussing atomic consistency is somewhat different than talking about an ACID database, as database consistency refers to transactions, while atomic consistency refers only to a property of a single request/response operation sequence. And it has a different meaning than the Atomic in ACID, as it subsumes the database notions of both Atomic and Consistent.”

On top of this confusion of terms, there are multiple types of consistency (à la CAP) supported by different vendors. There is strong consistency, weak consistency, immediate consistency, eventual consistency, strong eventual consistency, causal consistency and a whole bunch of other consistency models. In addition, you will hear vendors referring to linearizability, which provides guarantees about single operations performed on single objects and is related to the CAP Theorem; and serializability, which refers to guarantees about transactions and is ACID related. There is also a concept known as strict serializability. Note that some vendors offer tuneable consistency, by which they mean that you can choose different consistency models depending on requirements, including having different models in place within the same cluster.

In this context, a useful resource is https://jepsen.io/analyses.

The short answer is everybody. Every organisation deals with at least some customers (or clients, patients and so on), partners, suppliers, staff, stock and so forth and operational databases are the bedrock upon which applications supporting these (often commercial) relationships are based.

In practice, the decision of which database to select will often be down to IT, if for no other reason than that it is the applications built on top of the database that the enterprise will interact with.

The most notable longer-term trend is towards the adoption of NoSQL and graph databases for particular use cases and, where, geographically distributed databases are required, also to NewSQL databases. This has been exacerbated by increased cloud and hybrid deployments. In the shorter term, there has been a significant uptick in interest in so-called HTAP (hybrid transactional and analytic processing) databases. These are not only provided by vendors of all the types of database already mentioned but also by providers of data grids.

Two further trends are towards the separation of storage and compute, allowing either to be scaled (preferably in an elastic manner) without reference to the other, and in the growth of multi-model databases – see NoSQL databases.

There are more than 350 databases on the market and the vast majority of these support operational processing if not transactional processing. A great many support both. In our view, this is too many, but which ones are set for a fall and which ones will live long and prosper is a question we can’t answer.