ALL COVERED TOPICS

NoSQL Benchmarks NoSQL use cases NoSQL Videos NoSQL Hybrid Solutions NoSQL Presentations Big Data Hadoop MapReduce Pig Hive Flume Oozie Sqoop HDFS ZooKeeper Cascading Cascalog BigTable Cassandra HBase Hypertable Couchbase CouchDB MongoDB OrientDB RavenDB Jackrabbit Terrastore Amazon DynamoDB Redis Riak Project Voldemort Tokyo Cabinet Kyoto Cabinet memcached Amazon SimpleDB Datomic MemcacheDB M/DB GT.M Amazon Dynamo Dynomite Mnesia Yahoo! PNUTS/Sherpa Neo4j InfoGrid Sones GraphDB InfiniteGraph AllegroGraph MarkLogic Clustrix CouchDB Case Studies MongoDB Case Studies NoSQL at Adobe NoSQL at Facebook NoSQL at Twitter

NAVIGATE MAIN CATEGORIES

Close

distributedsystems: All content tagged as distributedsystems in NoSQL databases and polyglot persistence

Causality: A discussion of causality, vector clocks, version vectors, and CRDTs

If you have a quiet Sunday and want to listen to something extremely awesome, you should try this episode of ThinkDistributed podcast covering causality in distributed systems with guest hosts: Peter Bailis, Carlos Baquero, and Marek Zawirski.

The links in the show notes will fill your reading list for a good while.

Original title and link: Causality: A discussion of causality, vector clocks, version vectors, and CRDTs (NoSQL database©myNoSQL)


Scalable Atomic Visibility with RAMP Transactions

We’ve developed three new algorithms—called Read Atomic Multi-Partition (RAMP) Transactions—for ensuring atomic visibility in partitioned (sharded) databases: either all of a transaction’s updates are observed, or none are.

Still digesting Peter Bailis’s post and the accompanying Scalable Atomic Visibility with RAMP Transactions paper.

Original title and link: Scalable Atomic Visibility with RAMP Transactions (NoSQL database©myNoSQL)

via: http://www.bailis.org/blog/scalable-atomic-visibility-with-ramp-transactions/


Concurrent updates, distributed systems and clocks, vector clocks, last-write-win, and CRDT

Great post by John Daily from Basho about concurrent updates in the world of distributed systems and the implications of using clocks, vector clocks, last-write-wins, distributed data types (Commutative Replicated Data Type):

The problem is simple: there is no reliable definition of “last write”; because system clocks across multiple servers are going to drift.

Original title and link: Concurrent updates, distributed systems and clocks, vector clocks, last-write-win, and CRDT (NoSQL database©myNoSQL)

via: http://basho.com/clocks-are-bad-or-welcome-to-distributed-systems/


The "network partitions are rare" fallacy

Kelly Sommers:

Partitions in distributed systems is about availability not about network infrastructure. Many things can cause a node to be unavailable to a segment of other nodes.

Original title and link: The “network partitions are rare” fallacy (NoSQL database©myNoSQL)

via: http://kellabyte.com/2013/11/04/the-network-partitions-are-rare-fallacy/


The demise of eventual consistency?

A well written article by FoundationDB’s founder Dave Rosenthal about eventual consistency:

The concept of eventual consistency comes up frequently in the context of distributed databases. Leading NoSQL databases like Riak, Couchbase, and DynamoDB provide client applications with a guarantee of “eventual consistency”. Others, like MongoDB and Cassandra are eventually consistent in some configurations.

I could ignore some smart word choices and agree that dealing with eventual consistency is not a familiar area to many developers.

What I cannot agree with though, are weak statements like (what does unreliable writes mean?) :

Eventual consistency pushes the pain and confusion of inconsistent reads and unreliable writes onto software developers.

And definitely I cannot agree with unproved statements used solely to prove your point:

A system that keeps some, but not all, of its nodes able to read and write during a partition is not available in the CAP sense but is still available in the sense that clients can talk to the nodes that are still connected. In this way fault-tolerant databases with no single point of failure can be built without resorting to eventual consistency.

By changing the definitions, you are not proving a theorem is incorrect. Nor do you prove a different theorem.

Original title and link: The demise of eventual consistency? (NoSQL database©myNoSQL)

via: http://gigaom.com/2013/11/02/next-gen-nosql-the-demise-of-eventual-consistency/