July/August 2019 issue of acmqueue The July/August 2019 issue of acmqueue is out now

Subscribers and ACM Professional members login here

File Systems and Storage

  Download PDF version of this article PDF

Error 526 Ray ID: 5276b7e5ae269a02 • 2019-10-18 01:25:26 UTC

Invalid SSL certificate








What happened?

The origin web server does not have a valid SSL certificate.

What can I do?

If you're a visitor of this website:

Please try again in a few minutes.

If you're the owner of this website:

The SSL certificate presented by the server did not pass validation. This could indicate an expired SSL certificate or a certificate that does not include the requested domain name. Please contact your hosting provider to ensure that an up-to-date and valid SSL certificate issued by a Certificate Authority is configured for this domain name on the origin server. Additional troubleshooting information here.


Originally published in Queue vol. 6, no. 3
see this item in the ACM Digital Library



Pat Helland - Mind Your State for Your State of Mind
The interactions between storage and applications can be complex and subtle.

Alex Petrov - Algorithms Behind Modern Storage Systems
Different uses for read-optimized B-trees and write-optimized LSM-trees

Mihir Nanavati, Malte Schwarzkopf, Jake Wires, Andrew Warfield - Non-volatile Storage
Implications of the Datacenter's Shifting Center

Thanumalayan Sankaranarayana Pillai, Vijay Chidambaram, Ramnatthan Alagappan, Samer Al-Kiswany, Andrea C. Arpaci-Dusseau, Remzi H. Arpaci-Dusseau - Crash Consistency
Rethinking the Fundamental Abstractions of the File System


(newest first)

Displaying 10 most recent comments. Read the full list here

jaogoy | Sat, 28 Jun 2014 07:47:55 UTC

In my opinion, BASE can not replace ACID, for there is no equality between a big transaction and a group of small transaction split from the big transaction in all situations. And the Consistency does not mean Correct, it just meas the consistency of data among many hosts. However, It's really a good idea to solve transaction problems in many situations.

Toma~ Slivnik | Mon, 22 Apr 2013 11:24:13 UTC

Are there are any hard guarantees as to when "eventually" is? If there are not, then "eventually" could occasionally mean so long it means an effectively permanent inconsistency, even if in most cases it means "soon". This is a problem especially for truly massive databases where the probability of "eventually" being a very very long time may be tiny, but because there are gazillions of transactions, actually occurs quite regularly. I have seen deployed systems with non-ACID backends where the back end storage would occasionally remain inconsistent apparently permanently and wonder whether that is due to the "eventual" consistency nature of the system or due to a bug in the system elsewhere.

I would be very interested in hearing about any applications (whether real-life or artificial) where ACID really does not matter. I am happy to believe there are some, but I have not seen any that have persuaded me. All the examples that have been offered to me to date I perceived as an attempt to offer a clearly inferior solution and try to argue it was just as good, adequate etc. where in fact it was not.

Financial systems (where it is essential to know account balances in real time) and databases recording threads of interactive instantaneous communication (where communications are generally instantaneous and in the correct order, but are occasionally either delayed or put out of order, can cause real misunderstandings and conflict) in my view are clear situations where a non-ACID back end will be obviously inferior to an ACID one and, where deployed, will result in a clearly inferior and frustrating service.

Are there any situations where it really does not make a difference?

Pankaj Kapoor | Sat, 15 Dec 2012 07:16:01 UTC

A very good article explaining a step by step approach above the advantages and pitfalls. Obviously the article is not aiming to say that you need to replace the SQL by NOSQL. It is totally application dependent. Some data which requires accuracy at the very moment will definitely go for SQL but for very large data NoSQl is a better choice where consistency if eventually obtained is acceptable.

Winston Pacheco Junior | Wed, 30 May 2012 17:36:49 UTC

I think a bank is a good example of BASE Systems (I think is the oldest application of this idea), I don't know how this work in your country but in Brazil all the Bank systems are BASE. There are ACID transactions, like your Balance (this is ACID, fully consistent), but the "account statement" (I don't know if this is the right term, I wanna say the list of transactions that change your balance like: Supermarket 100,00; Pub 50,00 and so on) are BASE you'll see this data updated only day+1. I don't see any problem in this approach and I think the insitutions has no problems too.

Juan Trejo | Mon, 19 Dec 2011 20:47:51 UTC

Think Facebook, Twitter, Amazon... they all use BASE approaches for persistence.

Karl Banke | Thu, 28 Apr 2011 15:06:18 UTC

A rather artifical example as far as I can see. For me, the problem with the argument is the existence of "queues" in each of the datastores that engage in cross system transactions. That soon results in a lot of plumbing code or a lot of infrastructure components, since you need (at least) one on every persistent store. In addition one would need some housekeeping on the transaction tracking tables as well, which will diminish performance on the databases.

Sukumar Iyer | Mon, 18 Apr 2011 05:35:12 UTC

BASE signals won't be good unless connections to file systems are pointed out.

Noman Khan | Sun, 25 Oct 2009 07:14:06 UTC

I second with Adam D., Marcel. Really a good article to think out of ACID think.

Adam D. | Tue, 08 Sep 2009 06:16:33 UTC

You totally missed the point, Marcel. Not everything should be solved by relational algebra. Take a look at Event Sourcing and Messaging in general. Want scientific? Take a look at Paxos. This is a great article that shows the concepts simply.

michael lazar | Tue, 07 Jul 2009 18:11:49 UTC

Having designed many distributed systems over the years, this article lays out some good ideas. Obviously, a bank account would not be a good fit for this sort of approach. However, there are many places where eventual consistency is more than sufficient. This depends on business issues not technical issues. Inventory systems, reservation systems, and others all work in most business cases (not all) when they promise eventual consistency versus strict consistency.

Displaying 10 most recent comments. Read the full list here
Leave this field empty

Post a Comment:

© 2019 ACM, Inc. All Rights Reserved.