When people learn about database transactions, they often learn that transactions are useful when you want to modify multiple values together and want all of the ACID guarantees.
Lets move from academic to practical and think about what happens when you process an event in a production app. The most common patten we see:
- Collect context about the event and needed information to drive an action.
- Make a decision.
- Record that decision in state,
- Respond to caller and simultaneously export to a “big data” system for analysis.
Number one is what we mean when we say real-time analytics inside transactions.
Consider Openet, who uses VoltDB transactions to decide if mobile calls should be authorized. The first thing Openet does is collect information. Some questions are simple, e.g., “Does the caller have prepaid balance?” Others are more sophisticated, like, “How many blacklisted numbers has this caller made calls to in 24 hours?”.
VoltDB aims to make this per-event analytics phase of a transaction dramatically more powerful than any competing solution.
It’s not enough to support the SQL and transactional semantics though; to make these kinds of per-event understanding useful, it has to be instant. That’s why VoltDB supports many features that make common analytical queries real-time analytics. Read about our materialized views, specialized indexes and more data structures for more about what we mean.
We’re not talking about running reporting queries on your OLTP database, we’re talking about powerful queries supporting decisions made up to millions of times per second. This is something nobody else can do inside a single, serializable transaction.
Collect recent history, consider materialized aggregations, lookup ranks, join a few tables; go crazy. We’ll give you the tools to execute repeatable analysis up to millions of times per second, with low long-tail latency.