BT

FoundationDB NoSQL Database Supports ACID Transactions

by Srini Penchikala on Apr 29, 2013 |

FoundationDB database platform combines NoSQL scalability with ACID transactions across all data within the database. FoundationDB team announced last month the availability of its new NoSQL database platform.

NoSQL databases usually don't support ACID transactions across multiple data elements for scalability reasons but weak transaction guarantees can result in inconsistent data. Built on a distributed shared-nothing architecture, FoundationDB supports a diverse set of applications and data models using a concept called "layers" which map different data models to the ordered keys and values in the database. Applications built on these layers inherit the performance, data consistency and operational features of the core database.

InfoQ spoke with Dave Rosenthal and Nick Lavezzo from FoundationDB team about the new release, product features and how it compares with relational database models as well as with other NoSQL database technologies.

Nick talked about the current status of the database product. The new release is in Beta right now but it’s production ready. The product has been tested internally for the past few years, and it has been in alpha testing program for more than a year.

Responding to a question on how FoundationDB compares with relational databases (RDBMS) and with other NoSQL databases, Dave said FoundationDB combines the simple API and distributed design of NoSQL systems with the ACID transactions of RDBMSs.

InfoQ: Can you elaborate on how the database supports the CAP theorem and what it means for those three concerns: Consistency, Availability, and Partition-Tolerance?

Dave: The CAP theorem states that when a partition occurs in a distributed system you can choose either consistency or availability. As any transactional database must, FoundationDB chooses consistency. A system with both these capabilities is difficult to build, but not impossible.

InfoQ: What are the limitations or constraints of using FoundationDB database?

Dave: We carefully document both capabilities that FoundationDB is not designed to have, as well as known limitations in the current version of FoundationDB. We think it is very important to understand the limitations of any tool as important as a database.

InfoQ: What is the future of NoSQL databases in general and what do you see as the role of Relational databases in the overall data management landscape?

Dave: Of course, relational databases are not going anywhere soon, but other database technologies are narrowing the scope of problems for which RDBMSs are the best choice. The analytics market was the first place that traditional RDBMSs got displaced by the likes of Teradata, and now Hadoop is rapidly becoming the new standard for batch processing. NoSQL databases are now proving themselves as valid alternatives for scalable, operational systems.

FoundationDB will be available as both a free community edition and a licensed version with support and larger cluster capability. The community edition will include the full capabilities of FoundationDB and will allow production deployment. Developers can now sign up for the beta to evaluate FoundationDB and contribute layers via the Beta community site.

The website also includes several white-papers with information about the design and implementation of FoundationDB.

 

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

MarkLogic by Rob Rudin

MarkLogic is a database/search engine/application server that has been doing NoSQL/ACID for a decade. Granted, it costs money, but its feature set may justify the cost for you.

ACID - durability by Perara Taya

Documentation in FoundationDB for storage engine, state that "commits transactions to disk with the number of copies indicated by the redundancy mode before reporting them committed. This procedure guarantees the durability needed for full ACID compliance. At the point of the commit, FoundationDB *may have only logged* the transaction, deferring the work of updating the disk representation. This deferral has significant advantages for latency and burst performance. Due to this deferral, it is possible for disk space usage to continue increasing after the last commit.” What does this mean? does it mean that all replicas are written before returning from commit, but still haven't fsync() to disk/san, but operation is differed? if so how FoundationDB handles site/data center failures?

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

2 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT