At FoundationDB, we believe passionately in the engineering benefits of transactions. We put together this video to provide a quick overview of these benefits and explain how transactions can help you build a solid, reliable application. Here are some of the things the video covers:
What’s a transaction?
A transaction is a set of database reads and writes with some crucial properties: reads are not affected by writes from other transactions (Isolation), writes all succeed or fail together (Atomicity), and writes are permanently stored (Durability). Each of these is one of the ACID guarantees.
Which applications need transactions?
Any application with multiple clients operating concurrently needs transactions. Transactions aren’t just for financial applications, like e-commerce or banking. They’re fundamentally an engineering tool for concurrency control, one that’s better for application-building than any of the alternatives.
How do transactions simplify concurrency?
Isolation makes concurrency easy for developers. Serializability, the strong form of Isolation supported by FoundationDB, lets you treat each transaction as if it were sequential, which greatly simplifies reasoning about interactions among them.
What’s the difference between local and global transactions?
Some NoSQL systems advertise support for ACID transactions, but there’s usually a catch. Often, they support transactions for a limited set of predefined operations restricted by data locality (e.g., a single document or local graph components). The real power of transactions comes when they’re global, meaning they can act on any set of data elements chosen by the developer.
How do transactions enable abstraction?
Global transactions let you build new functionality over your data and expose it through an API. A simple example is an index. At one level, an index is just another copy of your data with a new access path. What makes indexing hard is the need to keep the index synchronized with your data as clients perform concurrent updates. Transactions make this synchronization easy.
Aren’t transactions computationally expensive?
Contrary to what is often assumed, transactions don’t limit scalability or performance in distributed systems, and they don’t represent a fundamental tradeoff in the design space. However, what is true that transactions require a great deal of engineering effort to implement well in a distributed environment. FoundationDB has put in that effort. We’ve done extensive benchmarking and have found that our transactional processing accounts for less than 10% of total system CPU load. Guaranteeing durability does increase write latency, but durability is a key feature for fault tolerance and is usually worth the cost.
How will transactions impact the NoSQL movement?
Many applications employ concurrency with multiple clients. Without transactions, the burden of concurrency control falls on developers, and this burden becomes less manageable as applications scale out. As the NoSQL field matures and is deployed more widely, transactions will become a foundational element of distributed database design.
Interested in FoundationDB’s distributed ACID transactions?