Don’t Accept Data Loss When Upgrading to In-memory Database Performance

This article was originally written by Ryan Betts

Data loss is the enemy of businesses everywhere. Snapshots, replication, active-active architectures, even physical measures such as backup generators are used to ensure data is preserved as it enters and is used or warehoused by the enterprise. Most companies use a database to manage this data and extract intelligence from it; therefore, the database has an important role in preservation of data – durability in database-speak.

As data wends its way through ingestion, transactions and analysis, many databases rely on frequent writes to disk to ensure data is durable, even in the event of power failure. But writes take time, another enemy of business, especially in high-transaction speed industries like financial services, energy management, network monitoring and security, telco billing, gaming and retail.

Adapting to the needs of real-time business

Enterprise architects and application developers have adapted to the needs of real-time business by turning to database tweaks, streaming processing engines and caching to avoid the overhead of traditional relational databases used to analyze and sift through data. Choosing to optimize performance has led some to accept tradeoffs on data consistency and durability when selecting a database system. In-memory NewSQL databases such as VoltDB eliminate many of the downsides of traditional databases, but confusion about how ‘in-memory’ databases handle data to ensure it meets the ‘durability’ requirement of ACID compliance (Atomicity, Consistency, Isolation and Durability) abounds.

Ensuring in-memory is durable

VoltDB is an in-memory operational database architected to meet the performance needs of real-time businesses. By executing transactions in memory, VoltDB is free of much of the management overhead and I/O costs of traditional databases. We take the ‘D’ (durability) in ACID very seriously; it is important that the contents of the database be safeguarded against loss or corruption. Durability means that once an application receives a response from a transaction sent to the database, the database doesn’t forget the side effects of that transaction.

We are often asked how we make data durable in the event of power failures, since in VoltDB all data is resident in memory. VoltDB combines two techniques to make data durable. First, the database produces point-in-time snapshots of its in-memory state. Using standard copy-on-write semantics, the database efficiently serializes (writes down) its in-memory state to local disks. Second, to cover the gaps between snapshots, VoltDB produces a write-ahead log of incoming transactions. In VoltDB parlance, this log is called the “command log.” To recover from a power or cluster failure, the system first restores the most recent snapshot and then replays the command log to return the database to its durable state. No data is lost.

All on-disk artifacts, including snapshots and command logs, are written at all replicas. This means the database produces multiple copies of the durable record to disk. If one server fails and its hard drive is not accessible, other servers in the cluster will have up-to-date copies of that data.

VoltDB offers three durability levels to support the performance requirements of a variety of applications and businesses:

1. In-memory only – the snapshot and command log features can be disabled. This is appropriate for some “moving window” use cases that cache the last few minutes in memory, or for caching solutions in which another system is responsible for durability.

2. Asynchronous command logging. In this mode, the database returns results to clients before the command log is fsync’d. This means some data can be queued to be written to disk, but not yet fully persisted, when clients receive responses. This approach minimizes latency while providing good durability.

3. Synchronous command logging. In this mode, every replica affected by a transaction has fsync’d the command log to disk before the client receives a response. This mode provides perfect durability.

Choosing between modes 2 and 3 (a simple configuration switch) is an application-specific choice. Many applications prefer the slightly lower latency provided by choice 2 and can tolerate the loss of the last half-second of data in the case of a catastrophic cluster failure. Other applications that cannot tolerate data loss require a stricter level of durability.

These durability techniques are heavily optimized and very fast. Our recent YCSB benchmark results were all run in mode 2 – asynchronous command logging – and demonstrated a 12-node cluster running 725k TPS.

Pushing for performance

Applications requiring the fastest performance and lowest latency can tune VoltDB to meet those needs by choosing to disable command logging and snapshots, at the sacrifice of data durability (scenario 1 above). A more prudent path that balances application performance and data durability is asynchronous command logging (see #2 above). All organizations benefit from the tu nability of VoltDB – from pure in-memory to synchronous command logging (scenario 3), with its strong, replicated, on-disk guarantees.

Optimizing for durability

VoltDB is architected for data durability. Founder and database visionary Mike Stonebraker dismisses the usefulness of ARIES-style data logging as a solution to durability, noting in this webinar that its impact on performance can exceed 25 percent of a system’s overhead (locking and latching each consume another 25 percent in a traditional RDBMS and many NoSQL offerings). VoltDB is designed to avoid locking, latching and data logging to deliver in-memory speed and performance, high availability and ACID-compliant durability, requirements of today’s real-time businesses.