Partition tolerance in CAP means tolerance to a network partition. An example of a network partition is when two nodes can't talk to each other, but there are clients able to talk to either one or both of those nodes. If you've ever used IRC and experienced a netsplit, this is a great example of that.
A CA system guarantees strong consistency, at the cost of not being able to process requests unless all nodes are able to talk to each other. An AP system is able to function during the network split, while being able to provide various forms of eventual consistency.
There's several forms of eventual consistency. There's the "weak eventual consistency", where you may not be able to read your writes. In the context of Dynamo-based key/value stores this actually only occurs as a failure condition: when the first node in the preference list for a key isn't available.
Another form of eventual consistency is "read-your-writes" consistency, where by you use a quorum of R reads, W writes out of a total of N replicas and set R + W > N. In this case you're guaranteed to be able to read your writes even if multiple nodes in the preference list for a key fail (as long as you're able to meet a quorum).
You mean something like "store all keys with an even hash value on server X, and all keys with an odd hash value on server Y"? You can do this yourself in your application: Just hash the value and then send the request to the corresponding server.
How is that any different than how you would do it with MySQL? If both products have the same solution to the same problem (handle it in your application) then why aren't they on the same edge?
If you want to partition (shard) your data, then this will work roughly the same in MySQL and Redis. But this article is only about partition tolerance. Neither MySQL nor Redis are inherently distributed, so it's not possible to generally state that either is partition-tolerant or not. The article is misleading here. You could use a replication strategy that is partition-tolerant or you could use a strategy that's not partition-tolerant.
Comments
Can anyone explain to me how redis supports partitioning? I'm still learning but so far I haven't found any support for it.
Partition tolerance in CAP means tolerance to a network partition. An example of a network partition is when two nodes can't talk to each other, but there are clients able to talk to either one or both of those nodes. If you've ever used IRC and experienced a netsplit, this is a great example of that.
A CA system guarantees strong consistency, at the cost of not being able to process requests unless all nodes are able to talk to each other. An AP system is able to function during the network split, while being able to provide various forms of eventual consistency.
There's several forms of eventual consistency. There's the "weak eventual consistency", where you may not be able to read your writes. In the context of Dynamo-based key/value stores this actually only occurs as a failure condition: when the first node in the preference list for a key isn't available.
Another form of eventual consistency is "read-your-writes" consistency, where by you use a quorum of R reads, W writes out of a total of N replicas and set R + W > N. In this case you're guaranteed to be able to read your writes even if multiple nodes in the preference list for a key fail (as long as you're able to meet a quorum).
You mean something like "store all keys with an even hash value on server X, and all keys with an odd hash value on server Y"? You can do this yourself in your application: Just hash the value and then send the request to the corresponding server.
How is that any different than how you would do it with MySQL? If both products have the same solution to the same problem (handle it in your application) then why aren't they on the same edge?
Read the comment by "strlen". Partitioning and network partitions are two totally different things.
I did, but I still don't see how redis and MySQL differ in how they handle either type.
If you want to partition (shard) your data, then this will work roughly the same in MySQL and Redis. But this article is only about partition tolerance. Neither MySQL nor Redis are inherently distributed, so it's not possible to generally state that either is partition-tolerant or not. The article is misleading here. You could use a replication strategy that is partition-tolerant or you could use a strategy that's not partition-tolerant.
Thanks, that's what I thought. I was hoping I was wrong. :P