Previously, I critiqued the Forrester Wave Translytical Data Platforms Q4 2017 report. At the end, I promised to provide a list of criteria to evaluate translytical databases. In order to create that list, we need to start with a solid definition of Translytics.
The Forrester Wave report defines Translytics as:
“A unified and integrated data platform that supports multi-workloads such as transactional, operational and analytical simultaneously in real-time, leveraging in-memory capabilities including support for SSD, Flash and DRAM and ensures full transactional integrity and data consistency.”
This is a good definition, but leaves a lot to be inferred by the reader. In my opinion, Translytics is not a “general purpose database” that does “good-enough” transactions with “good-enough” analytics. Relational DBMSs have been doing that for decades. So clearly there isn’t a need to coin a new term for that. To me, translytics is a purpose-built technology to do real-time operational analytics as transactions are happening. To boil it down to math equations, Translytics is not T+A (or A+T), but T’.
As an aside, you may get the impression that translytics necessarily means in-memory. This is not necessarily the case. You can have a translytical solution that is not in-memory (VoltDB is in-memory because we care about performance). Similarly, in-memory does not automatically imply Translytics. You can’t just slap an in-memory solution over your transactional system (such as TimesTen) or over your analytics platform (such as SAP HANA) and call that Translytics. Translytics means that the transaction and the analytics happen at the same time.
Choosing the Right Solution
With this in mind, there are five essential criteria to any translytics solution.
- Transactions: This may seem obvious, but you can’t have transactional analytics without transactions. Otherwise, you’re just doing analytics.
- Scalability: While not strictly a requirement, the problems that translytics solves don’t exist at low scale. The RDBMS solutions have solved the problem decades ago if it weren’t for large scale. But what workload doesn’t require large scale these days?
- High Performance: By high performance, I mean high throughput at predictable low latency. High throughput is essential when doing thousands (or millions) of transactions and analytics per second. Low latency is crucial for keeping applications reasonably fast. If you have all the time in the world, the problem essentially isn’t meaningful. Streaming systems have high throughput but fail to deliver low mean latency. Also, latency is a reason why you should co-locate application and the corresponding translytical databases on the same cloud.
- Real-Time Operational Analytics with Complex Decision Making: If you’re looking at translytics, you want high-quality, very accurate decisions in the moment. There are all kinds of analytics solutions/column stores that non-transactional Analytics. But when you need to do a hundred SQL queries to gain the understanding and context in the 1ms you have to authorize a credit card swipe or to connect a mobile call, you need real-time operational analytics.
- Enterprise Capabilities: These are capabilities that have become table stakes for any Enterprise software developed today. These include multi-site active/active/active replication, disaster recovery, etc. You’re (probably) not in the translytical database market just for the heck of it. Without these capabilities, you’re taking a gamble that nothing will ever go wrong, or that the solution to these problems will be developed in-house. Developers will need to have answer for these requirements before the Operations teams deploy the application in production.
There are a number of other features, such as data types, platforms, and so on, that can impact your decision. These can either be necessities or luxuries, depending on your use case. However, we believe that only the five listed criteria are essential to a translytical database. If you’re searching for a translytics solution and on a vendor call, and they don’t meet the above criteria, you might as well hang up the phone; they don’t have what you’re looking for.
John Ryan, Data Warehouse Solution Architect at UBS, has recently published an ebook, Comparing Database Solutions. Check it out for more on pros and cons of various database technologies.