BASE: All content tagged as BASE in NoSQL databases and polyglot persistence
Thursday, 2 May 2013
Banks and the Ethernal Consistency Example or What trumps consistency
Todd Hoff extracts and expands on some thoughts about BASE vs ACID from Eric Brewer’s NoSQL: Past, Present, Future published on InfoQ:
Consistency it turns out is not the Holy Grail. What trumps consistency is:
- Auditing
- Risk Management
- Availability
But the cornerstone of the availability vs consistency conversation is:
Availability correlates with revenue and consistency generally does not.
✚ Over time Michael Stonebraker has been the most prominent supporter of exactly the opposite argument.
✚ Remember Emin Gün Sirer’s The NoSQL Partition Tolerance Myth? He used the bank example too.
Original title and link: Banks and the Ethernal Consistency Example or What trumps consistency (©myNoSQL)
Wednesday, 2 March 2011
9 Things to Acknowledge about NoSQL Databases
Excellent list:
- Understand how ACID compares with BASE (Basically Available, Soft-state, Eventually Consistent)
- Understand persistence vs non-persistence, i.e., some NoSQL technologies are entirely in-memory data stores
- Recognize there are entirely different data models from traditional normalized tabular formats: Columnar (Cassandra) vs key/value (Memcached) vs document-oriented (CouchDB) vs graph oriented (Neo4j)
- Be ready to deal with no standard interface like JDBC/ODBC or standarized query language like SQL; every NoSQL tool has a different interface
- Architects: rewire your brain to the fact that web-scale/large-scale NoSQL systems are distributed across dozens to hundreds of servers and networks as opposed to a shared database system
- Get used to the possibly uncomfortable realization that you won’t know where data lives (most of the time)
- Get used to the fact that data may not always be consistent; ‘eventually consistent’ is one of the key elements of the BASE model
- Get used to the fact that data may not always be available
- Understand that some solutions are partition-tolerant and some are not
Print it out and distribute it among your colleagues.
Original title and link: 9 Things to Acknowledge about NoSQL Databases (NoSQL databases © myNoSQL)
via: http://www.evidentsoftware.com/nosql-basics-for-the-rdbms-savvy/
Thursday, 23 September 2010
On NoSQL Databases and ACID
Dan Weinreb:
The “NoSQL” systems are ACID, as long as you accept that a transaction can only perform one operation, in the sense that the only thing that gets in the way of being ACID is when there are network partitions and the system is called upon to perform operations while the partition is still there.
That’s why they are said to be ☞ BASE (basically available, soft state, eventually consistent)
Original title and link for this post: On NoSQL Databases and ACID (published on the NoSQL blog: myNoSQL)
via: http://danweinreb.org/blog/nosql-storage-systems-never-violate-acid-never-well-hardly-ever
Wednesday, 6 January 2010
Notes on Distributed Programming and CAP
Firstly, an interesting presentation by Paulo Gaspar (@paulogaspar7) on ☞ Distributed programming and data consistency
Key take-aways:
The network falacies:
- The network is reliable
- Latency is zero
- Bandwith is infinite
- The network is secure
- Topology doesn’t change
- There is one administrator
- Transport cost is zero
- The network is homogenous
-
CAP Trade-offs:
- CA without P: Databases providing distributed transactions can only do it while their network is up
- CP without A: While there is a partition, transactions to an ACID db may be blocked until the partition heals
- AP without C: Caching provides client-server partition resilience by replicating data, even if the partition prevents verifying if a replica is fresh
Another interesting post on this topic, is ☞ The CAP Theorem Distilled by Sid Anand (@r39132). Under the assumption that “any system needs to support ‘P’” (nb I am not sure why the article is limiting the analysis to this case only), the article compares ‘A’ vs ‘C’ in CAP:
If you choose ‘C’, your system might implement 2-phase commit (a.k.a 2PC) . […]
On the other hand, if you opt for an AP system, you are opening the door to potential data inconsistencies. […] AP systems can get quite complicated (relative to CP systems)
In two subsequent articles, Sid is explaining “eventual consistency” for ☞ non-techies and for ☞ techies . I liked the way Paulo visually represented inconsistency across time in his slides:
