NoSQL Databases Should Support Transactions: 10 Reasons Why

By Chris Preimesberger  |  Posted 2013-10-07 Email Print this article Print

As the volume, variety and velocity of data streams continue to spiral up—not to mention the number of people and devices—more pressure is building on the Web and mobile apps that serve those users. These factors, combined with the shift toward cloud computing, mean traditional relational database management systems (RDBMSes) may not be the right fit anymore for the emerging generation of interactive applications. The NoSQL database, a growing group of database experts contend, offers the flexibility, scalability and performance that present-day Web and mobile app developers demand. Transactions of all types are a major part of all this usage. The "ACID" properties of transactions (atomicity, consistency, isolation and durability) are the fundamental guarantees. A common misconception is that transactions are useful only for e-commerce or banking applications, which process financial transactions. However, the power of transactions comes from their engineering impact on application development, not from the details of any particular app. Transactions are critical for building robust systems in an efficient, simple way. Here, eWEEK and Dave Rosenthal, co-founder of FoundationDB, offer 10 reasons your NoSQL database should support transactions.

  • NoSQL Databases Should Support Transactions: 10 Reasons Why

    by Chris Preimesberger
    1 - NoSQL Databases Should Support Transactions: 10 Reasons Why
  • Concurrency Control

    Concurrency arises whenever multiple clients, users, or parts of an application read and write the same data at the same time. Transactions make managing concurrency simple for developers. The main property of transactions that achieves this simplicity is isolation, or the "I" in ACID. When a system guarantees that transactions are fully isolated, developers can treat each transaction as if it were executed sequentially, even though it may actually be executed concurrently. The burden of reasoning about potential interactions between operations from separate transactions goes away.
    2 - Concurrency Control
  • Powerful Abstractions

    Transactions allow developers to build abstractions simply and efficiently, providing a highly extensible capability to support multiple data models. Data models optimized for graphs, hierarchical documents, column-oriented data or relational data can all be implemented in layers. A common abstraction is to maintain an index along with the primary data to enable quickly finding data items matching some constraint. With transactions, an indexing layer can update both the data and the index in a single transaction, guaranteeing their consistency and allowing for a strong abstraction.
    3 - Powerful Abstractions
  • Efficient Data Representations

    Transactions enable a more efficient data representation within a given model. Data elements can be modeled to optimize access efficiency, using multiple documents when appropriate, and still be updated in a single transaction to guarantee consistency. Moreover, the data can be shared by multiple clients and concurrently updated. Again, transactions provide the concurrency control needed to safely manage a shared state.
    4 - Efficient Data Representations
  • Flexibility

    When applications evolve, having the flexibility to modify the data model and the power of global transactions can make the difference between an easy change and re-architecting. This sort of evolution is a natural and frequently occurring pattern. Transactions make the difference between being able to easily add these features and throwing out large parts of your code and starting over.
    5 - Flexibility
  • Cost

    It may seem that the design tradeoffs for your system compel you to give up the advantages of transactions to gain speed, scalability and fault tolerance. Systems built this way are usually fragile, difficult to manage and often nearly impossible to adapt to changing business needs. The costs of forgoing transactions are rarely worth the benefits, especially if an alternative can provide transactional integrity at scale.
    6 - Cost
  • Performance and Scalability

    When the NoSQL movement began, features familiar from relational databases had been aggressively shed and were deemed unnecessary or even harmful for scalability and performance goals. However, it is becoming clear that supporting transactions is a matter of engineering effort, not a fundamental tradeoff in the design space. Algorithms for maintaining transactional integrity can be distributed and scaled out like many other problems.
    7 - Performance and Scalability
  • Write Latency

    Transactions guarantee the durability of writes (the "D" in ACID). This guarantee comes with some increase in write latency. Durability means that committed writes stay committed, even in the face of subsequent hardware failures. As such, durability is an important component of fault tolerance. NoSQL systems that don't support durability are necessarily weaker in regard to fault tolerance.
    8 - Write Latency
  • Modern Systems Depend On Them

    For several decades, nearly all software systems that need to store data have been built on top of relational (mostly SQL) databases, and rely on the strong consistency guarantees and concurrency controls provided by ACID transactions. Any projects to transition existing systems to modern distributed databases will be exceptionally complicated, if not impossible, if the new database does not provide ACID transactions.
    9 - Modern Systems Depend On Them
  • Google Needs Them

    Google can in large part be credited with the creation of the NoSQL movement; its "Big Table" white paper served as the basis for many first-generation NoSQL databases. It introduced the concept of "eventual consistency" as a sacrifice that could be made for scalability. Google has recently released a paper on Spanner, the company's new distributed database system, which instead of eventual consistency provides ACID transactions. If Google's engineers need transactions, chances are good that you do, too.
    10 - Google Needs Them
  • Next-Gen NoSQL Standard

    ACID transactions simplify concurrency for developers by providing "serializable" operations that can be composed to properly engineer application software. The choice to use transactions is ultimately not a matter of fundamental tradeoffs but of sound engineering. As the technology matures, transactions will form a foundational capability for future NoSQL databases. If you're building an application that needs to be scalable and you don't have transactions, you will eventually be burned.
    11 - Next-Gen NoSQL Standard

Submit a Comment

Loading Comments...

Manage your Newsletters: Login   Register My Newsletters

Rocket Fuel