ACID ... has nothing to do with "hardware"
Picky, picky. There is no hardware that can support ACID behaviour in these scenarios.
transaction rates and data volumes of Facebook, Twitter, Google
To the best of my knowledge, these applications are not "transaction" systems
You're right, and you're wrong. They relax ACID requirements slightly (so are not "transactional"), yet still produce the desired behaviour with the desired reliability. They preserve the vast majority (5 9's at least) of all transactions, otherwise folk would shriek about lost updates. However it's likely their businesses would not fail as a result of a failure rate even significantly higher than they actually have.
Even Walmart could afford to not get paid for 0.001% of its transactions, so yes, even Walmart could operate with the loss of ACID semantics. Their transaction volume is however many orders of magnitude lower than the online services, and are within the reach of ACID DBMSs. I wouldn't recommend NoSQL to Walmart anyhow, it takes a lot of expertise to get it right, whereas the ACID guarantees of traditional DBMS are much easier to use.
Ken Evans: Clifford Heath:
Read the article
I read the article - and all the comments.
Some of the contributors seem to be failing to differentiate between matters that are in the conceptual and theoretical domains and matters that are in the domain of physical implementation.
Yes, there's a good deal of ignorance and blurring of boundaries, including beliefs such as I described in my first post in this thread.
However, although Twitter, Facebook et al could theoretically implement greater reliability using an ACID-compliant DBMS running on some hypothetical computer that's orders of magnitude larger and faster than any available, that's a pointless thing to note. They have the problem they have, and they solve it the way they do. Because they're successful, others want to emulate them, so apply the same techniques inappropriately.
I might point out that for applications that contain terabytes of data, which need to be able to implement schema changes in seconds or minutes not hours or days, a departure from the relational model is often justified. Many non-1NF objects may be stored having different internal schema versions, and as long as the access code can read all live format versions, there's no need to rewrite all objects (and blow the time limit) when a new version is deployed. Such applications have needs which fall halfway between full relational/transaction support and a basic file system, and the NoSQL DBMS are suitable candidates. ACID semantics can still be implemented, but need help from the application code. It's a lot of work, yet a lot of modern web applications fall into this class, hence the enthusiasm for NoSQL. It's not necessarily evil, despite ignorant people doing it inappropriately.