Real-Time Computing: 4 Sources of Latency And How To Avoid Them

This post originally appeared on InfoWorld on November 1, 2017.

4 sources of latency and how to avoid them

Even Google and Amazon can’t process data instantly—here’s how to combat latency in your real-time application

 

Despite all the advances we’ve seen in data processing and database technology, there is no escaping data’s Public Enemy No. 1: latency, the time delay before a response is generated and returned. Even Gartner’s definition of a zero-latency enterprise acknowledges that latency can never actually be zero because computers need time to “think.”  

While you may never truly achieve zero latency, the goal is always to deliver information in the shortest amount of time possible, so ensuring predictable, low latency processing is key when building a real-time application. Often the hardest part, though, is identifying the sources of latency in your application and subsequently eliminating them. If you can’t remove them entirely, there are steps you can take to reduce or manage their consequences.  

Before, during, and after computing the response, there are number of areas that can add unwanted latency. Below are some common sources and tips for minimizing their impact.

Network I/O

Most applications use the network in some manner, whether between the client application and the server or between server-side processes and applications. The important thing to know here is that distance matters—the closer your client is to the server, the lower the network latency. For instance, round-trip latency between nodes within the same datacenter can cost 500 microseconds, while it can be an additional 50 milliseconds for nodes in California and New York.

What to do:

• Use faster networking, such as better network interface cards and drivers and 10GigE networking.
• Eliminate network hops. In clustered queuing and storage systems, data can be horizontally scaled across many host machines, which can help you avoid extra network round-trip connections.
• Keep client and server processes close together, ideally within the same datacenter and on the same physical network switch.
• If your application is running in the cloud, keep all processing in one availability zone.

Disk I/O

Many real-time applications are data intensive, requiring some sort of database to service the real-time request. Databases, even in-memory databases, make data durable by storing it to persistent storage, but for high-velocity real-time applications, making data durable can add significant unwanted latency, and disk I/O, like network I/O, is costly. Accessing memory can be upwards of 10,000x faster than a single disk seek.

What to do:

• Avoid writing to disk. Instead use write-through caches or in-memory databases or grids (modern in-memory data stores are optimized for low latency and high read/write performance).
• If you do need to write to disk, combine writes where possible, especially when using fsync. The goal is to optimize algorithms to minimize the impact of disk I/O. Consider asynchronous durability as a way to avoid stalling main line processing with blocking I/O.
• Use fast storage systems, such as SSDs or spinning disks with battery-backed caches.

The operating environment

The operating environment in which you run your real-time application—on shared hardware, in containers, in virtual machines, or in the cloud—can significantly impact latency.

What to do:

• Run your application on dedicated hardware so other applications can’t inadvertently consume system resources and impact your application’s performance.
• Be wary of virtualization—even on your own dedicated hardware, hypervisors impose a layer of code between your application and the operating system. When configured properly, performance degradation can be minimized, but your application is still running in a shared environment and may be impacted by other applications on the physical hardware.
• Understand the nuances of the programming language environment used by your application. Some languages, such as Java and Go, use automatic memory management and use periodic garbage collection to reclaim unused memory. The processing impact of garbage collection can be unpredictable and introduce unwanted latency at seemingly random times.

Your code

When it comes to coding, there are some common core functionalities that can pose barriers to speed.

What to do:

• Inefficient algorithms are the most obvious sources of latency in code. When possible, look for unnecessary loops or nested expensive operations in code—restructuring loops and caching expensive computation results usually help.
• Multi-threaded locks stall processing and thus introduce latency. Use design patterns that avoid locking, especially when writing server-side applications.
• Blocking operations cause long wait times, so use an asynchronous (non blocking) programming model to better utilize hardware resources, such as network and disk I/O.
• Unbounded queues may sound counter-intuitive, but these lead to unbounded hardware resource usage, which no computer has. Limiting the queue depths and providing back pressure typically lead to less wait time in your code resulting in more predictable latencies.

Combating the enemy

Building real-time applications requires that the application developer not only write efficient code, but to also understand the operating environment and hardware constraints of the systems on which your application will be deployed. Provisioning the fastest networking equipment and the fastest CPUs won’t singularly solve your real-time latency requirements.

Thoughtful application architecture, efficient software algorithms and optimal hardware operating environment are all key considerations for fighting latency.

 

This post originally appeared on InfoWorld on August 28, 2017. 

 Measuring real-time

I explore the different types of real-time applications and how real-time is measured based on the application need

The term “real-time” is thrown around a lot these days, but it’s a buzzword that is often surrounded by ambiguity. Every day, it seems a new product is announcing its real-time capability. But how is real-time measured? It certainly isn’t measured in days (or even hours)—so is it measured in:

• Nanoseconds?
• Microseconds?
• Milliseconds?
• Seconds?
• Minutes?
• All of the above?

Everyone, from developers to software corporate marketing departments to even consumers, seems to have a slightly different answer. So let’s explore the question “What does ‘real-time’ really mean?”

Let’s begin with the dictionary definition:

Real-time—“of or relating to applications in which the computer must respond as rapidly as required by the user or necessitated by the process being controlled.”

While this definition continues with the subjective theme, it does confirm that the correct answer to how to measure real-time is “All of the above.” The meaning of the term real-time varies based on application need—the amount of time a computer (the application) takes to respond and the acceptable latency is as fast as required by the problem domain.

Rather than look at applications and determine if they are real-time or not, let’s examine various time units and understand the types of real-time applications that require those response rates:

Nanoseconds: A nanosecond (ns) is one billionth of a second. Admiral Grace Hopper famously explained a nanosecond using an 11.8-inch wire, as that is the maximum distance electricity can travel in one nanosecond. This quick video of Hopper is worth watching if you haven’t yet seen it.

With this in mind, it is easy to see why nanoseconds are the unit used to measure the speed of hardware, such as the time it takes to access computer memory. Worrying about nanosecond latency is at the bleeding edge of real-time computing and is primarily driven by innovation with hardware and networking technology.

Microseconds: A microsecond (µs) is one millionth of a second. Real-time applications that worry about microsecond latency are high-frequency trading (HFT) applications. Financial trading firms spend large sums of money investing in the latest networking and computer hardware to eliminate microseconds of latency within their trading platforms. A trading decision has to be made in as few microseconds as possible in order to execute ahead of competition and thus maximize profit. 

Milliseconds: A millisecond (ms) is one one-thousandth of a second. To put this in context, the speed of a human eye blink is 100 to 400 milliseconds, or between a 10th and half of a second. Network performance is often measured in milliseconds. Real-time applications that worry about latency in milliseconds include telecom applications, digital ad networks, and self-driving cars. The decision on what optimal ad to display or whether there is enough balance to let a cellphone call proceed must be made on the order of 100 milliseconds.

Seconds: We’re starting slow down here. We’re still in the realm of real-time, but we are now venturing into near real-time. Sub-minute processing time is often more than good enough for applications that process log files, computing analytics on event streams, as well as alerting applications. These real-time applications drive actions and decisions that are made in human-reaction time rather than machine-time. Reducing the response time by one tenth of a second (100ms), which may be costly to implement, has no change in value for the application.

Minutes: Waiting minutes may seem like an eternity to a high-frequency trading application. However, consider package shipment and delivery alerts or ecommerce stock availability notifications. Those applications certainly feel real-time to me—the fact that I receive a “delivery notification” text message within 10 minutes of a delivery made to my home is very satisfying.

Finally, though I discounted it up front, let’s briefly consider hours and days. While this time range is generally not regarded as true real-time, if you’ve been getting finance or sales reports on a monthly, weekly, or daily basis, and now you can get up-to-date reports every hour, that may be as real-time as you need. The modernization of these applications is often termed as upgrading from “batch” to “real-time.”

The old proverb is correct: Time is money. Throughout history, the ability to make real-time decisions has meant the difference between life and death, between profit and loss. The value of time has never been higher and therefore speed has never been more critical to business applications of all kinds.

Luckily, we live in an age where fast computing is very affordable and making decisions in real-time is economically achievable for most applications. The first step is determining the appropriate definition of real-time that aligns with the needs of your business applications.

Top 5 Ways to Better Use Your Data

This post originally appeared on VoltDB.com in May, 2016. 

 Top 5 Ways to Better Use Your Data

Sir Francis Bacon is said to have coined the phrase “scientia potentia est”, translated as ‘knowledge is power’. Four hundred years later, we might rewrite the phrase as “data potentia est”.  Data is power - so how can you better use your organization’s data?  Here are five suggestions to help you drive value from your organization’s data - quickly.

1)    Know what you have.

First and foremost, inventory your data. 

There are two types of data to identify. First is historical data. Historical data is data you’ve accumulated over years of doing business. This could include databases, files, spreadsheets, presentations, transactions, logs, etc. The second type of data is the data that is being created “right now” - this is real-time data. Real-time data potentially has immediate value, and then ultimately turns into historical data.

Catalog and prioritize the data you have. Ideally, you will also want to identify the sources of data. Knowing how data is created allows you to capture it, store it, and eventually extract value from it, at the least cost to the organization, and with the best ROI.

The value of each type of data is different. Historical data allows you to analyze and mine past events. Real-time data gives you the opportunity to calculate analytics, possibly compare them to historical trends, and perform business actions in real-time, to capture additional and immediate value.

By way of example, consider a fraud prevention offering. Fraudulent transaction patterns are mined from historical data. These historical patterns are applied to real-time transactions to identify and reject suspected fraudulent transactions.

2)    Architect a data strategy that handles both Big and Fast data.

Creating a historical archive, perhaps a data lake via a Hadoop cluster, to store your data is only one step. Today enterprises create data at a tremendous - and growing - rate.  Processing and ingesting data in batch mode overnight is no longer acceptable. Real-time responsive enterprises need to process and react to data in seconds to minutes. Many organizations, including mobile operators, telecom providers, financial services organizations and advertising technology providers must respond in milliseconds.

3)    Choose the appropriate technologies.

There are a plethora of big data tools, and most are designed around best practices, optimized to extract value from both historical and real-time data.

Minimally you will need technologies for these areas:

Big Data: Typically, the main data management platform for big data is Hadoop or a data warehouse or perhaps a combination of the two to handle both structured and unstructured data. They act as the repository for all your data, often called the “data lake”. The data lake stores historical data to be analyzed and mined. 

Fast Data: Data is being created at a dizzying rate every day. Fast data is data that is being created now and is streaming into your company now.  It could be user clicks on your corporate web page or product downloads or any operational event occurring in your organization.  To deliver this fast data to the systems that can act on it, consider a message queueing systems such as Kafka.  To eliminate batch processing (slow data!) this message queue needs to deliver event data to an operational data stores capable of handling and processing messages at web-scale speed, thousands to tens of thousands to even millions of events per second.  The operational data store’s role is to ingest the data and process it in real-time.  Real-time processing can include computing real-time analytics, such as counts, aggregations and leaderboards, issuing real-time alerts, deduping, enriching and aggregating events, and making transactional decisions on an event-by-event basis. Both NewSQL and NoSQL operational stores can provide horsepower for handling real-time processing of event streams.  Modern operational data stores range from strongly-consistent SQL databases to eventually consistent key/value and document stores.  Consider numerous factors when choosing, including transactions as well as query interface, important for your data visualization tooling.

Data Visualization: Dashboards, charts, leaderboards, pivot tables, and visualizations all play a key role in understanding your data, both historical and real-time.

Historical visualization helps you explore, understand patterns, and create predictive analytics. Real-time visualizations help you understand the current state of your business, usually in the form of a real-time dashboard.

You will want to evaluate tools from vendors such as Tableau, Qlik and MicroStrategy for dashboarding and ad hoc visualizations -- user experience is a critical factor with this kind of software so having your users try it out is essential.

Data Science: A growing number of tools can help you extract information and insight from your data. Machine learning packages provide data classification, clustering, and regression analysis, and allow software to “learn” to identify and make predictions on data. Consider popular open source offerings such as Spark (MLlib) or R to get started.

4)    Build a Data Pipeline that delivers Data as a Service (DaaS) to internal customers.

Define an architecture that serves data to your internal customers. Capturing and analyzing the data is great, but it is only the first step. Data and insights must be readily available to consumers (people and applications) across your enterprise. Consumers of your data must be able to tap into both historical data from the data lake as well as real-time fast data, along with the insights derived from both together.

5)    Begin building applications to extract value from the data  -  then iterate.

Start small and add incrementally. Identify opportunities for small quick wins that will prove you can capture value from your data. Realize that data evolves and new patterns will emerge. Foster an environment of experimentation, innovation and continuous improvement and iterate on your data analysis.

Data is valuable. Batch processing is so 1990s. Now you’ve got five ideas for how to extract more value from your data. Start now and iterate. Think Big, of course, but also Think Fast.

Streaming Data: Billions and Billions (of transactions)

 This post originally appeared on VoltDB.com in October, 2016.

Billions and billions (of transactions)

Billions and billions^[1] of transactions are executed each and every day by production-deployed VoltDB applications.

A back-of-the-napkin calculation puts the number north of 50 billion a day. The number is likely much, much higher. These billions of transactions are executed across a variety of innovative applications, applications not practical, or sometimes even possible, to build a decade ago. Chances are that you have touched VoltDB – without knowing it – today!

• When you call someone on your cell, there’s a good chance a VoltDB application is approving the call.
• If you have played some of the top 10 mobile games within the past few years, a VoltDB application likely processed your in-game events.
• If you’ve run a road race recently, there’s a good chance a VoltDB application tracked your progress.
• If you live in the UK and turn on a light switch, you are interacting with VoltDB as your electrical smart grid uses VoltDB to authorize and process grid and meter events.
• If you play baccarat in a casino, there’s a good chance the bets placed and movement of chips on each gaming table is validated by VoltDB via in-chip RFID technology.
• If you bought something in China with your credit card, it is likely that your transaction was verified as valid or detected as fraudulent by a VoltDB application.

The VoltDB engineering team has been building the world’s fastest in-memory database for over eight years now. It’s been a fun as well as challenging journey and we’ve learned a lot in the process. Some of the more notable learnings have been:

Batch is so 2000s. Legacy applications are moving from batch processing of feeds to real-time processing. New applications are being built to ingest, transact, and compute analytics on data streaming from all types of sources, such as IoT sensors, mobile devices, logs, etc. The world is moving to real-time and turning to products like VoltDB, which has the capability to handle high throughput (thousands to millions of events per second).

SQL [still] rules the roost.  VoltDB was founded around the same time as the NoSQL movement. At the time, building a distributed SQL data store seemed contrarian, given the NoSQL hype. Fast forward a half-dozen years and we now see many of the more popular NoSQL products offering SQL or SQL-like interfaces. Even the Hadoop ecosystem has added SQL interfaces to the data lake. SQL is here to stay(and, in fact, never left).

VoltDB’s commitment to SQL remains strong. Over the past year we’ve added windowing analytic SQL, geospatial SQL support (points and polygons), continuous queries via real-time materialized views, the ability to join streams of data to compute real time analytics, and the ability to very quickly generate an approximate count of the number of distinct values. More advanced SQL capabilities are made available nearly every month.

Expect the unexpected, operationally. When you build a highly-available, clustered database that runs 24×7 at high throughput, on bare metal or in the cloud, all types of error scenarios that could happen, dohappen. Disks fail, networks break down, power goes out, mistakes are made, lightning strikes.

Building a production-ready operational database is tough work. The bar is set high and not negotiable. The following features are table stakes for current and next generation applications:

• High availability: Machines, containers and virtual machines can and do break, crash or die. Networks pause or partition. The database must handle these situations properly.
• Correctness: Accuracy matters. Every client should see a consistent view of the data.
• Predictable latency: Response time should be predictable, within 99.999% of the time.
• Durability: Never lose data even in the face of nodes crashing or networks partitioning.
• Performance: The database needs to scale with your application. Adding additional nodes should scale throughput smoothly and linearly.

To maintain these requirements across all scenarios, VoltDB Engineering constantly pounds on the database in our QA lab. We focus on randomizing errors of all types. The more we learn, the more we feel we need to test more. That’s one of the reasons we reached out to Kyle Kingsbury, (aka Aphyr), to independently apply his dastardly Jepsen test suite and methodology to VoltDB. As part of this effort, we found a few issues in the product before they caused issues in customer deployments. This effort remains one of the team’s proudest accomplishments of 2016.

But we know there’s always more work to do, and we’re committed to doing it.

Streaming analytics and operational data stores are merging into a new real-time platform

The architecture required for real-time processing of streaming data is evolving rapidly. When we started building VoltDB, a developer had to cobble together numerous pieces of technology, (e.g. ZooKeeper, Kafka, Storm, Cassandra), to process real-time streams of data.

VoltDB Founding Engineer John Hugg stated at a recent Facebook @Scale conference, “OLTP at scale looks a lot like a streaming application.”  Today we’re seeing the result of that evolution: a convergence of real-time ingestion, streaming analytics, and operational interaction into a single platform. While creating the next generation of database, the VoltDB engineering team has assembled the core components for building streaming fast data applications in VoltDB:

• Real-time ingestion with in-process, highly-available importers reading from Kafka, Kinesis and other streaming sources;
• Streaming analytics on live data via ad hoc SQL analytics as well as continuous queries; and
• A blazingly fast in-memory storage and ACID transaction execution engine capable of accessing hot and historical data to make per-event decisions millions of times per second.

The VoltDB engineering team is not done building (or learning)! Our mission is to make building highly-reliable, high throughput fast data applications not only possible, as it is today, but also extremely easy. So stay tuned. Over the coming months we’ll be delivering additional geo-distributed and high availability features, additional importers and exporters for building fast data pipeline applications, and improving our real-time analytical SQL capabilities.

^[1] With a hat tip to Johnny Carson and Carl Sagan

Simplifying the Lambda Architecture

 This post originally appeared on VoltDB.com in December, 2014. 

Evolving and Simplifying the Lambda Architecture

Introduction

The Lambda Architecture defines a robust framework for ingesting streams of Fast Data while providing efficient real-time and historical analytics. In Lambda, immutable data flows in one direction: into the system. The architecture’s main goal is to execute OLAP-type processing faster - in essence,  reduce columnar analytics from every couple of seconds to 100ms or so, without actually enabling interesting new applications like real time application of user segments/scoring. As Lambda was conceived, it wasn’t designed to transact and make per-event decisions on the Fast Data, nor to be responsive to the events coming in, as they arrive.

What is Lambda?

The Lambda Architecture is a new Big Data architecture designed to ingest, process and query both fresh and historical (batch) data in a single data architecture. In his book “Big Data - Principles and best practices of scalable realtime data systems”, Nathan Marz introduces the Lambda Architecture and states that:

“The Lambda Architecture.. provides a general purpose approach to implementing an arbitrary function on an arbitrary dataset and having the function return its results with low latency.”

Nathan further defines the system as having both a batch (historical) layer, as well as a speed layer:

“The Lambda Architecture solves the problem of computing arbitrary functions

on arbitrary data in realtime by decomposing the problem into three layers: the

batch layer, the serving layer, and the speed layer. “

The batch layer is usually a “data lake” system like Hadoop, though it could also be an OLAP data warehouse like Vertica or Netezza. This historical archive is used to hold all of the data ever collected. The batch layer supports batch query; batch processing is used to generate analytics, either predefined or ad hoc.

The speed layer is defined as a combination of queuing, streaming and operational data stores. In the Lambda Architecture, the speed layer is similar to the batch layer in that it computes similar analytics - except that it computes those analytics in real-time on only the most recent data. The analytics the batch layer calculates, for example, may be based on data one hour old. It is the speed layer’s responsibility to calculate real-time analytics based on fast moving data - data that is zero to one hour old.

As you can see, if you combine the analytics produced by the batch layer as well as the speed layer, you have a complete view of the analytics across all data, fresh and historical.  The third layer of Lambda, the serving layer, is responsible for serving up results, combined from both the speed and batch layer.

To summarize, Lambda defines a Big Data architecture that allows arbitrary queries and computations on both fast moving data as well as historical data.

“Typical” Lambda Applications

The Lambda Architecture is an emerging paradigm in Big Data computing. As such, new Lambda-based applications are emerging seemingly weekly. However, one of the more common use cases of Lambda-based applications is log ingestion and accompanying analytics. “Logs” in this context could be general log collection, website clickstream logging, VPN access logs, or the popular Twitter tweet stream collection.

Log messages often are created at a high velocity. They are immutable and usually are time-tagged or time ordered. This is the "fast data" that is captured and harvested - it is this data that is ingested by both Lambda’s speed layer and batch layer, usually in parallel, by way of message queues and streaming systems (like Kafka and Storm). The ingestion of each log message does not require a response to the entity that delivered the data - it is a one-way data pipeline.

A log message’s final resting place is the data lake, where batch metrics are [re]computed.   The fast layer computes similar results for the most recent "window", staying ahead of the Hadoop/batch layer. 

Analytics at the speed and batch layer can be predefined or ad hoc. Should new analytics be desired, Lambda suggests that you can re-run the entire data set, from the data lake or from the original log files, to recompute the new metrics. For example, analytics for website click logs could be counting page hits and page popularity. For tweet streams they could be computing trending topics.

VoltDB and the Lambda Architecture

VoltDB, a clustered, in-memory, relational database.  It supports fast ingest of data, real-time ad hoc analytics and rapid export of data to downstream systems like Hadoop and OLAP offerings.  It fits squarely and solidly into the Lambda Architecture’s speed layer. Like popular streaming systems, VoltDB is horizontally scalable, highly available, and fault tolerant — all while sustaining transactional ingestion speeds of hundreds of thousands to millions of events per second. In the standard Lambda Architecture, the inclusion of VoltDB greatly simplifies the speed layer by replacing both the streaming and the operational data store portions of the speed layer. 

In the outlined Lambda Architecture, a queuing system like Kafka would feed both VoltDB and Hadoop, or VoltDB directly, which would then in turn immediately export the event to the data lake.

Future-proofing Lambda

As defined today, the Lambda Architecture is very focused on fast data collection and read-only queries on both fast and historical data. In Lambda, data is immutable - it never changes. Data comes into the system in streams and metrics, both historical and real time, and is calculated and maintained. External systems make use of the Lambda-based environment to query the computed analytics. These analytics are then used to alert, should metric thresholds be crossed, or harvested, for example in the case of Twitter trending topics.

When considering improvements to the Lambda Architecture, what if you could react, per event, to the incoming data stream? In essence, you’d have the ability to act on the incoming feed, in addition to performing real-time analytics.

Here at VoltDB we have a lot of experience building streaming applications for Fast Data, another term for the Lambda-defined “speed layer”. Most of our customers are building Fast Data applications, providing us with unique insight into the Lambda speed layer.  These systems ingest events from log files, the Internet of Things (IoT), user clickstreams, online game play, and financial applications. While some of these applications passively ingest events and provide real-time analytics and alerting on the data streams (in typical Lambda style), many of these applications have begun interacting with the stream, adding per-event decisioning and transactions in addition to real-time analytics.

Additionally, another characteristic of these systems is that the speed layer analytics can differ from the batch layer analytics. Often the data lake is used to mine intelligence via exploratory queries.  This intelligence, when identified, is then fed to the speed layer as input to the per-event decisions. Scott Jarr describes this fully interactive Lambda-like application evolution here, http://voltdb.com/blog/youd-better-do-fast-data-right/ in his Fast Data blog.

In this diagram you can see the additions to the architecture:

1.     Data arrives at a high rate and is ingested.  It is immediately exported to the Batch Layer, the Data Lake.

2.     Historical intelligence can be mined from the Data Lake and the aggregate “intelligence” can be delivered to the Speed Layer for per-event real-time decisioning (for instance, to determine which ad to display for a segmented/categorized web browser/user).

3.     Fast Data is either passively ingested, or a response can be computed by the new decisioning layer, using both real-time data as well as historical “mined” intelligence.

For a working code example of the simplified speed layer, reference the

VoltDB “fast data” application posted here: http://voltdb.github.io/app-fastdata.

Conclusion

The Lambda Architecture is a powerful Big Data analytics framework that serves queries from both fast and historical data.  However, the architecture emerged from a need to execute OLAP-type processing faster, without considering a new class of applications that require per-event decisioning: applications like real time application of user segments/scoring, fraud detection, denial of service attacks, policy and billing, etc. In its current form, Lambda is limited: immutable data flows in one direction, into the system, for analytics harvesting.

Adding VoltDB, a linearly scalable in-memory relational database, into the Lambda Architecture greatly simplifies the speed layer by reducing the number of components needed.

Lambda’s shortcoming is the inability to build responsive, event-oriented applications.

In addition to simplifying the architecture, VoltDB provides future-proof functionality to Lambda, specifically, the ability to execute transactions and per-event decisions on Fast Data as it arrives. Rather than a one-way streaming system feeding events into the speed layer, adding an ingestion engine like VoltDB provides developers with the ability to place applications in front of the event stream to capture value the moment the event arrives, rather than capturing value at some point after the event arrived on an aggregate-basis.

VoltDB improves the Lambda architecture by: 

●      Reducing the number of moving pieces, the products and components, needed.  Specifically, major components of the speed layer can be replaced by a single component, VoltDB.   Further, VoltDB can be used as a data store for the serving layer.

●      Enables the ability for the application to make per-event decisioning and transactional behavior, without re-implementing the architecture once deployed.

●      Providing the traditional relational database interaction model, with ad hoc SQL capabilities, on Fast Data.  Applications can use standard SQL providing agility to their query needs without requiring complex programming logic.

●      Providing access to standard analytics tooling, such as Tableau, MicroStrategy, and Actuate BIRT, on top of Fast Data.