skip to Main Content

Operational Databases

Last Updated:
Analyst Coverage:

An operational database is designed to run the day-to-day operations or transactions of your business. It may also be called upon to support analytic processing either by providing real-time dashboards or supporting the ability to embed analytics into operational processes.

There are many ways to skin this particular cat. Historically, the most common type of database used to support operations were relational databases, but some companies still run their transaction processing on navigational databases. More recent introductions include NewSQL databases (which look relational but aren’t) and various types of NoSQL database including, but not limited to, both graph databases and SQL on Hadoop engines. Many of these are suitable for supporting hybrid operational and analytic processing.

A report on HTAP databases and technologies will be published here shortly.

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.

Solutions

  • Actian (logo)
  • AEROSPIKE logo
  • ArangoDB (logo)
  • COUCHBASE logo
  • CRATE.io logo
  • DataStax (logo)
  • ESGYN DB logo
  • GIGASPACES logo
  • GRIDGAIN logo
  • INTERSYSTEMS logo
  • LEANXCALE logo
  • MARIADB logo
  • MEM SQL logo
  • MONGO DB logo
  • Neo4j (logo)
  • NuoDB (logo)
  • Redis Labs (logo)
  • TigerGraph (logo)
  • VOLT DB logo
Cover for What's Hot in Data?

What’s Hot in Data

In this paper, we have identified the potential significance of a wide range of data-based technologies that impact on the move to a data-driven environment.
CRATE DB InBrief cover thumbnail

CrateDB

CrateDB is targeted specifically at IoT applications and ingesting and processing machine data, and it can be deployed both at the edge and more centrally.
MEMSQL InBrief cover thumbnail

MemSQL

MemSQL is a scale-out distributed, relational database, with a lock-free architecture that supports both row and column storage.
Cover for All about graphs: a primer

All about graphs: a primer

Over the last few years graph databases have been the fastest growing sector within the database market ...
NEO4J for HTAP InBrief cover thumbnail

Neo4j

Neo4j, is a labelled, property graph database with a native engine that is targeted at operational and hybrid operational/transactional and analytic use cases.
AEROSPIKE InBrief cover thumbnail

Aerospike

Aerospike is a distributed, massively parallel, NoSQL database with a three-tier architecture
ACTIAN X InBrief cover thumbnail

Actian X

Actian X is a hybrid database that combines what used to be known as Ingres and what was previously VectorWise.
00002480 - DATASTAX ENTERPRISE InBrief cover thumbnail

DataStax Enterprise

DataStax Enterprise is a distributed NoSQL database, using CQL, that is oriented towards (though not exclusive to) cloud and hybrid-cloud architectures.
Back To Top