As record-keeping first became computerized, the high price of compute, memory, and storage meant that it was too expensive to keep every event. To reduce costs, the database world endeavored to make it possible to only keep the current state, and thus gave birth to the “transaction”. Databases and applications that focused entirely on the current state proliferated and became what we know of today as On-Line Transaction Processing (OLTP). After a few decades of OLTP, methods to automate reporting and analysis of transactions were defined as On-Line Analytics Processing (OLAP). Now, after a few decades of exploration of both OLTP and OLAP, we are seeing a new split emerge, not on the basis of “transactional processing versus analytical processing” but on the basis of “Transactions versus Events”.
Early use of event processing, by Midjourney
This new split of transactions versus events is giving rise to a new set of infrastructure: HTAP as a one-stop shop for “Transactions” and “Event Stores” as a one-stop shop for Events. But, we are now jumping ahead of ourselves. Before we can reach that conclusion, we need to first go back and discuss the difference between events and transactions.
Events make Transactions, but Transactions do not make Events
We, as people, are all a product of our past experiences. We have seen different things, experienced different things and all of those serve as inputs into who we are as human beings. This very directly mimics the difference between Transactions and Events, all of our experiences as humans are Events that happened in our lives, but who we are right now, here, today, that is the Transactional representation of us. Even this description is probably too meta, so let’s actually boil this down to a real-world example: T-shirts!
First, we’ll explain Events by purchasing a t-shirt. When we make that purchase, we are essentially creating an “Event.” Events happen at a point in time, for a very specific amount of money, and these purchases never change: if you purchased something (such as a new shirt) yesterday, even if you return it today, it doesn’t change the fact that you purchased it yesterday. This specific notion of “never changing” is a central theme for Events, they are occurrences that will never change.
Purchasing a shirt in a store, with data, by midjourney
When we purchase that shirt, however, the inventory of shirts in the store changes. If there were 10 shirts, there are now 9, this is a Transaction. The inventory of shirts in the store is defined by its change and its most important property is that it is up-to-date. If the store manager is looking at the inventory and it is not up-to-date, there is a risk of purchasing too much stuff or running out of stock. Just as “never changing” is a central theme for Events, “changeable” is a central theme for a Transaction.
So, what is the relationship between your T-shirt purchases and the inventory management at the store?
Well, let’s start by discussing the world of that store manager who is managing their inventory. If they have a consistent view of how many of each shirt that they have, then it is relatively easy to decide if you have enough inventory right this moment. But, if all you know is your current inventory, you do not have enough information to decide how much inventory you will need in the future. Likely, you pick a level of inventory, say 10 of each shirt, and just try to keep that much in stock. But, do you tend to sell more Medium size shirts? Large shirts? XXXL shirts? Are there days of the week that you tend to sell more shirts and days when you sell less? These questions are hard to answer with only the current stock levels available: the best you can do is notice that you are running low on inventory and then stocking back up.
When you want to get a bit more intelligent about what the right level of inventory is and whether you need to be restocked by tomorrow or if it can wait til next week, you need more information. You might start keeping track of how much inventory you sold each day, and then you can go back and look at the history of days to get a better idea of how much and how quickly you need to restock. Even better than waiting for the end of the day to figure out how much inventory changed, you could also keep a record of each and every interaction, counting each sale as it happens. Whether you do this every evening or on each sale, you are recording Events: the fact that someone purchased that inventory never changes.
But, what about if we return that shirt? Doesn’t that reverse the purchase of the item? This is where the separation between a Transaction and an Event becomes even more important. When that T-shirt gets returned, the inventory increases again and it looks like nobody ever bought the shirt in the first place, so the “Transactional View” would end up having you believe that nobody purchased anything. However, that doesn’t change the fact that it actually was purchased, the Event view would actually register 2 separate Events: one for the purchase and one for the return.
In this way, as each new purchase or return occurs, a new Event happens. With each of these events, the inventory level increases or decreases: a Transaction change. Events and Transactions exist everywhere and follow this same relationship. The Transaction is a view of a specific state that sometimes changes when a new Event happens..
But, Don’t Databases already have Transactions?
A Transaction is a state that changes, but databases and especially OLTP databases have been defined by their support for “database transactions” for many decades. Truly, it’s right in the name: OLTP = On-Line Transaction Processing, but the section above doesn’t really sound like a “transaction” from a Databases 101 class, so, what gives?
These are very deeply related concepts and that’s why we are choosing to reuse the label “Transaction”, but there is a slight difference in nuance. Specifically, database transactions exist to ensure the correctness of changes applied to the Transaction. Going back to our purchasing example, let’s say that both I and a family member are shopping online. We both try to return the same item at the same time. The store should accept only one return and reject the other, but which one? The simplest answer to this is “the first one should be accepted and the latter one rejected.” But, if they truly happened at the exact same instant, how do we know which one is the first one and which one is the second? This is the problem that a database transaction solves: it gives us a way to ensure that one return is applied before the other, giving us the ability to accept one and reject the other.
Databases put great importance on making each database transaction ACID-compliant, guaranteeing Atomicity, Consistency, Isolation, and Durability. Without this, we couldn’t correctly apply the Events (our product returns) to the Transaction (the inventory level) in the database.
Even with database transactions ensuring that only one return gets processed, we still have a chance for a bad experience. If my return was the latter one and it got rejected, I will want to know why it was rejected. Specifically, I need to be able to see some record that the item I believe I’m returning was already processed and returned by my family member, so that I can double check with them that we both tried to do the same thing.
Taking this back to the generic “Transaction” versus “Event” terminology, a database transaction exists to enforce the orderly application of Event(s) to the state of a Transaction. It is a very necessary and powerful tool in the OLTP tool chest, but in an OLTP system, the database transaction fundamentally exists to allow us to minimize storage by applying Events to the Transaction and only store the most up-to-date, final state of the object.
At least, that was a fundamentally important element to dealing with data in the past. As technology has evolved, storage has become cheap while compute is ever-more accessible and usually available on demand. We’re evolved from a world where Events were too expensive to store to the modern world where the insights from Events are too valuable to lose.
What if we used Infrastructure designed to keep all of those Events?
All of this might sound like a new concept, like we are preaching some new doctrine, some new religion that was just discovered. But, in reality, we are not. Event-native infrastructure has been brewing for many years. Perhaps it started with streaming systems, where every message put into a Kafka topic is fundamentally equivalent to an Event. For analytics, data is commonly copied from OLTP systems to OLAP systems using an Extract-Load-Transform process. When this ELT process is completed, the resulting data is very commonly a ‘reverse conversion’ from a Transaction into Events (for example, the process might subtract today’s inventory from yesterday’s to figure out how many of each item was purchased).
Either way, the growth of the Internet has driven a fundamental shift in infrastructure, creating a need and development towards infrastructure that can deal with Events directly and natively. The first large-scale uses of event processing were driven by a very common use case: Web Analytics. Every interaction with a web site or a mobile app is an Event. Understanding the flow and how people go through logins, signups, and other activities is a collection of events, but not really a Transaction.
Events are streaming, by Midjourney
While events can be stored in databases designed for Transactions, the requirements to implement ACID-compliant database operations are usually at odds with the requirements to address the scale, performance, and concurrency needs of working with Events. Given that Events are forever constant, adding them to a database only requires an append and does not require changing any other state. This is a fundamental assumption that must be leveraged to truly scale out to the 10s, 100s, even 1000s of millions of Events per second that exist in our physical world. Infrastructure not built for this world often tries to overcome the cost of supporting ACID-compliant changes to state through adopting a microbatching strategy, converting a stream of Events to a series of database transactions.
Event databases house Events as the immutable pieces of treasure that they are. Event databases are built to store the Events and make them accessible so that it is always possible to understand the series of Events that caused something to happen. Since the Events are often arriving as a real-time stream, these databases are often called Real-Time Analytics Databases.
Diving deeper into our shopping example, we can take a case study from the realm of e-commerce. Amazon.com and other pioneers of e-commerce realized early in their journey that some functions, such as inventory tracking and financial settlement, need ACID-compliant transactions, but far more valuable information is in the flow of events. Understanding how each customer comes to the e-storefront, navigates through offerings, responds to recommendations, builds shopping carts (or, sometimes, abandons those carts), and changes patterns at different times of day, days of the week, and seasons of the year provides the knowledge to build lasting relationships. The events are transported as a data stream to an Event Store, where they can be evaluated and used to generate insights.
This need exists in all industries and beyond. Search engines use Events to validate the relevance of search results. Medical devices like a glucose meter can provide a stream of Events that can be leveraged to orchestrate an insulin pump to administer insulin while maintaining an auditable trail of the state of a patient and Event data to power predictive analytics and future research. Smart devices in a home provide streams of Events from their sensors which can be combined and aggregated to understand the overall efficiency of a building, or what time of day a household consumes their electricity.
Our Event-Driven Future
OLTP and OLAP are mature, and together they form the basis of transaction processing and analytics. Relational databases, non-relational databases, and analytics databases, are each designed to store, retrieve, and otherwise work with Transactions. We have found ways of scaling these databases, culminating in the advent and expansion of Hybrid Transactional/Analytic Processing (HTAP) databases which promise to remove the boundaries between OLAP and OLTP, for Transactions, still focusing on computing and analyzing a specific state at a specific point in time.
Future Data with Event Streams by midjourney
There is another world that is emerging from this that HTAP doesn’t address, it is the Event-focused world, where you want to understand the actions taken and provenance of a specific state more than just the current state. While, on the surface, it might seem like Transaction-oriented systems should be able to do what an Event-oriented system can do, this is the same argument that existed for many years that an OLTP system can do the same things that an OLAP system can do.
For low levels of scale, the sheer power of compute these days can overcome the inefficiencies of using a Transaction-oriented system to work with Events. But, there will always exist use cases and points of scale where an Event-oriented system will be required to provide the best experience at the best overall cost.
The fundamental assumptions of how you want to interact with Events versus Transactions are different. When you think about it, all actions taken by humans and machines are Events. So, the needs of Event-oriented infrastructure are not likely to disappear any time soon.
(If you’d like an easy way to try out an event database, get a free trial of Imply Polaris, the database-as-a-service built from Apache Druid.)
Other blogs you might find interesting
No records found...
Sep 27, 2023
Introducing incremental encoding for Apache Druid dictionary encoded columns
In this blog post we deep dive on a recent engineering effort: incremental encoding of STRING columns. In preliminary testing, it has shown to be quite promising at significantly reducing the size of segment...
Migrate Analytics Data from MongoDB to Apache Druid
This blog presents a concise guide on migrating data from MongoDB to Druid. It includes Python scripts to extract data from MongoDB, save it as CSV, and then ingest it into Druid. It also touches on maintaining...
How Druid Facilitates Real-Time Analytics for Mass Transit
Mass transit plays a key role in reimagining life in a warmer, more densely populated world. Learn how Apache Druid helps power data and analytics for mass transit.
Migrate Analytics Data from Snowflake to Apache Druid
This blog outlines the steps needed to migrate data from Snowflake to Apache Druid, a platform designed for high-performance analytical queries. The article covers the migration process, including Python scripts...
Apache Kafka, Flink, and Druid: Open Source Essentials for Real-Time Applications
Apache Kafka, Flink, and Druid, when used together, create a real-time data architecture that eliminates all these wait states. In this blog post, we’ll explore how the combination of these tools enables...
Visualizing Data in Apache Druid with the Plotly Python Library
In today's data-driven world, making sense of vast datasets can be a daunting task. Visualizing this data can transform complicated patterns into actionable insights. This blog delves into the utilization of...
Bringing Real-Time Data to Solar Power with Apache Druid
In a rapidly warming world, solar power is critical for decarbonization. Learn how Apache Druid empowers a solar equipment manufacturer to provide real-time data to users, from utility plant operators to homeowners
When to Build (Versus Buy) an Observability Application
Observability is the key to software reliability. Here’s how to decide whether to build or buy your own solution—and why Apache Druid is a popular database for real-time observability
How Innowatts Simplifies Utility Management with Apache Druid
Data is a key driver of progress and innovation in all aspects of our society and economy. By bringing digital data to physical hardware, the Internet of Things (IoT) bridges the gap between the online and...
Three Ways to Use Apache Druid for Machine Learning Workflows
An excellent addition to any machine learning environment, Apache Druid® can facilitate analytics, streamline monitoring, and add real-time data to operations and training
Apache Druid® is an open-source distributed database designed for real-time analytics at scale. Apache Druid 27.0 contains over 350 commits & 46 contributors. This release's focus is on stability and scaling...
Unleashing Real-Time Analytics in APJ: Introducing Imply Polaris on AWS AP-South-1
Imply, the company founded by the original creators of Apache Druid, has exciting news for developers in India seeking to build real-time analytics applications. Introducing Imply Polaris, a powerful database-as-a-Service...
In this guide, we will walk you through creating a very simple web app that shows a different embedded chart for each user selected from a drop-down. While this example is simple it highlights the possibilities...
Automate Streaming Data Ingestion with Kafka and Druid
In this blog post, we explore the integration of Kafka and Druid for data stream management and analysis, emphasizing automatic topic detection and ingestion. We delve into the creation of 'Ingestion Spec',...
This guide explores configuring Apache Druid to receive Kafka streaming messages. To demonstrate Druid's game-changing automatic schema discovery. Using a real-world scenario where data changes are handled...
Imply Polaris, our ever-evolving Database-as-a-Service, recently focused on global expansion, enhanced security, and improved data handling and visualization. This fully managed cloud service, based on Apache...
Introducing hands-on developer tutorials for Apache Druid
The objective of this blog is to introduce the new set of interactive tutorials focused on the Druid API fundamentals. These tutorials are available as Jupyter Notebooks and can be downloaded as a Docker container.
In this blog article I’ll unpack schema auto-discovery, a new feature now available in Druid 26.0, that enables Druid to automatically discover data fields and data types and update tables to match changing...
Druid now has a new function, Unnest. Unnest explodes an array into individual elements. This blog contains design methodology and examples for this new Unnest function both from native and SQL binding perspectives.
What’s new in Imply Polaris – Our Real-Time Analytics DBaaS
Every week we add new features and capabilities to Imply Polaris. This month, we’ve expanded security capabilities, added new query functionality, and made it easier to monitor your service with your preferred...
Apache Druid® 26.0, an open-source distributed database for real-time analytics, has seen significant improvements with 411 new commits, a 40% increase from version 25.0. The expanded contributor base of 60...
How to Build a Sentiment Analysis Application with ChatGPT and Druid
Leveraging ChatGPT for sentiment analysis, when combined with Apache Druid, offers results from large data volumes. This integration is easily achievable, revealing valuable insights and trends for businesses...
In this blog, we will compare Snowflake and Druid. It is important to note that reporting data warehouses and real-time analytics databases are different domains. Choosing the right tool for your specific requirements...
Learn how to achieve sub-second responses with Apache Druid
Learn how to achieve sub-second responses with Apache Druid. This article is an in-depth look at how Druid resolves queries and describes data modeling techniques that improve performance.
Apache Druid uses load rules to manage the ageing of segments from one historical tier to another and finally to purge old segments from the cluster. In this article, we’ll show what happens when you make...
Real-Time Analytics: Building Blocks and Architecture
This blog identifies the key technical considerations for real-time analytics. It answers what is the right data architecture and why. It spotlights the technologies used at Confluent, Reddit, Target and 1000s...
What’s new in Imply Polaris – Our Real-Time Analytics DBaaS
This blog explains some of the new features, functionality and connectivity added to Imply Polaris over the last two months. We've expanded ingestion capabilities, simplified operations and increased reliability...
Wow, that was easy – Up and running with Apache Druid
The objective of this blog is to provide a step-by-step guide on setting up Druid locally, including the use of SQL ingestion for importing data and executing analytical queries.
Tales at Scale Podcast Kicks off with the Apache Druid Origin Story
Tales at Scale cracks open the world of analytics projects and shares stories from developers and engineers who are building analytics applications or working within the real-time data space. One of the key...
Real-time Analytics Database uses partitioning and pruning to achieve its legendary performance
Apache Druid uses partitioning (splitting data) and pruning (selecting subset of data) to achieve its legendary performance. Learn how to use the CLUSTERED BY clause during ingestion for performance and high...
Easily embed analytics into your own apps with Imply’s DBaaS
This blog explains how developers can leverage Imply Polaris to embed robust visualization options directly into their own applications without them having to build a UI. This is super important because consuming...
Building an Event Analytics Pipeline with Confluent Cloud and Imply’s real time DBaaS, Polaris
Learn how to set up a pipeline that generates a simulated clickstream event stream and sends it to Confluent Cloud, processes the raw clickstream data using managed ksqlDB in Confluent Cloud, delivers the processed...
We are excited to announce the availability of Imply Polaris in Europe, specifically in AWS eu-central-1 region based in Frankfurt. Since its launch in March 2022, Imply Polaris, the fully managed Database-as-a-Service...
Should You Build or Buy Security Analytics for SecOps?
When should you build—or buy—a security analytics platform for your environment? Here are some common considerations—and how Apache Druid is the ideal foundation for any in-house security solution.
Combating financial fraud and money laundering at scale with Apache Druid
Learn how Apache Druid enables financial services firms and FinTech companies to get immediate insights from petabytes-plus data volumes for anti-fraud and anti-money laundering compliance.
This is a what's new to Imply in Dec 2022. We’ve added two new features to Imply Polaris to make it easier for your end users to take advantage of real-time insights.
Imply Pivot delivers the final mile for modern analytics applications
This blog is focused on how Imply Pivot delivers the final mile for building an anlaytics app. It showcases two customer examples - Twitch and ironsource.
For decades, analytics has been defined by the standard reporting and BI workflow, supported by the data warehouse. Now, 1000s of companies are realizing an expansion of analytics beyond reporting, which requires...
Apache Druid is at the heart of Imply. We’re an open source business, and that’s why we’re committed to making Druid the best open source database for modern analytics applications
When it comes to modern data analytics applications, speed is of the utmost importance. In this blog we discuss two approximation algorithms which can be used to greatly enhance speed with only a slight reduction...
The next chapter for Imply Polaris: celebrating 250+ accounts, continued innovation
Today we announced the next iteration of Imply Polaris, the fully managed Database-as-a-Service that helps you build modern analytics applications faster, cheaper, and with less effort. Since its launch in...
We obviously talk a lot about #ApacheDruid on here. But what are folks actually building with Druid? What is a modern analytics application, exactly? Let's find out
Elasticity is important, but beware the database that can only save you money when your application is not in use. The best solution will have excellent price-performance under all conditions.
Druid 0.23 – Features And Capabilities For Advanced Scenarios
Many of Druid’s improvements focus on building a solid foundation, including making the system more stable, easier to use, faster to scale, and better integrated with the rest of the data ecosystem. But for...
Apache Druid 0.23.0 contains over 450 updates, including new features, major performance enhancements, bug fixes, and major documentation improvements.
Imply Polaris is a fully managed database-as-a-service for building realtime analytics applications. John is the tech lead for the Polaris UI, known internally as the Unified App. It began with a profound question:...
There is a new category within data analytics emerging which is not centered in the world of reports and dashboards (the purview of data analysts and data scientists), but instead centered in the world of applications...
We are in the early stages of a stream revolution, as developers build modern transactional and analytic applications that use real-time data continuously delivered.
Developers and architects must look beyond query performance to understand the operational realities of growing and managing a high performance database and if it will consume their valuable time.
Building high performance logging analytics with Polaris and Logstash
When you think of querying with Apache Druid, you probably imagine queries over massive data sets that run in less than a second. This blog is about some of the things we did as a team to discover the user...
Horizontal scaling is the key to performance at scale, which is why every database claims this. You should investigate, though, to see how much effort it takes, especially compared to Apache Druid.
When you think of querying with Apache Druid, you probably imagine queries over massive data sets that run in less than a second. This blog is about some of the things we did as a team to discover the user...
Building Analytics for External Users is a Whole Different Animal
Analytics aren’t just for internal stakeholders anymore. If you’re building an analytics application for customers, then you’re probably wondering…what’s the right database backend?
After over 30 years of working with data analytics, we’ve been witness (and sometimes participant) to three major shifts in how we find insights from data - and now we’re looking at the fourth.
Every year industry pundits predict data and analytics becoming more valuable the following year. But this doesn’t take a crystal ball to predict. There’s instead something much more interesting happening...
Today, I'm prepared to share our progress on this effort and some of our plans for the future. But before diving further into that, let's take a closer look at how Druid's core query engine executes queries,...
Product Update: SSO, Cluster level authorization, OAuth 2.0 and more security features
When you think of querying with Apache Druid, you probably imagine queries over massive data sets that run in less than a second. This blog is about some of the things we did as a team to discover the user...
When you think of querying with Apache Druid, you probably imagine queries over massive data sets that run in less than a second. This blog is about some of the things we did as a team to discover the user...
Druid Nails Cost Efficiency Challenge Against ClickHouse & Rockset
To make a long story short, we were pleased to confirm that Druid is 2 times faster than ClickHouse and 8 times faster than Rockset with fewer hardware resources!.
Unveiling Project Shapeshift Nov. 9th at Druid Summit 2021
There is a new category within data analytics emerging which is not centered in the world of reports and dashboards (the purview of data analysts and data scientists), but instead centered in the world of applications...
How we made long-running queries work in Apache Druid
When you think of querying with Apache Druid, you probably imagine queries over massive data sets that run in less than a second. This blog is about some of the things we did as a team to discover the user...
Uneven traffic flow in streaming pipelines is a common problem. Providing the right level of resources to keep up with spikes in demand is a requirement in order to deliver timely analytics.
Community Discoveries: multi-value dimensions in Apache Druid
Hellmar Becker is an Imply solutions engineer based in Germany, where he has been delving into the nooks-and-crannies of multi-valued dimension support in Druid. In this interview, Hellmar explains why...
Community Spotlight: Apache Pulsar and Apache Druid get close…
The community team at Imply spoke with an Apache Pulsar community member, Giannis Polyzos, about how collaboration between open source communities generates great things, and more specifically, about how...
Meet the team: Abhishek Agarwal, engineering lead in India
Abhishek is Imply’s first engineer in India. We spoke to him about setting up our operations in Bangalore and asked what kind of local talent the company is looking for.