Live data from Hacker News

You Can’t Sacrifice Partition Tolerance (2010)

codahale.com

11–20 of 24 posts

Re: You Can’t Sacrifice Partition Tolerance (2010)

#11
post #5

Earlier quoted context omitted.

You skipped the second part of that. Unless your web application is running on the database server then you are no longer running single node, your web app and db server can become partitioned.

Ah, okay, I didn't understand that next part correctly the first time. So that does account for why the author says such systems are rare. But that doesn't really help me understand why CA can't exist. There are still systems that simply don't have network partitions. SQLite on the same phone as the app using it? As I said, it doesn't seem like we ignore the rare or uninteresting cases.

The CAP theorem is fundamentally about distributed systems. The name is on the tin. It's not ignoring things, you're trying to pick an argument via examples outside the explicitly defined scope.

Re: You Can’t Sacrifice Partition Tolerance (2010)

#12
Liked everything up to this part;

"When it comes to designing or evaluating distributed systems, then, I think we should focus less on which two of the three Virtues we like most and more on what compromises a system makes as things go bad."

It seemed like the entire point was that really there are only 2 Virtues (Consistency, Availability) and given a partition you will chose one or the other. The only database that doesn't have network partitions also isn't distributed.

Re: You Can’t Sacrifice Partition Tolerance (2010)

#13
post #12

Liked everything up to this part; "When it comes to designing or evaluating distributed systems, then, I think we should focus less on which two of the three Virtues we like most and more on what compromises a system makes as things go bad." It seemed like the entire point was that really there are only 2 Virtues (Consistency, Availability) and given a partition you will chose one or the other. The only database that…

> and given a partition you will chose one or the other

There is no sacrificing consistency though. It's about whether you use CRDTs or something to keep the system working when network partition happens or you don't and let the system stop working.

Re: You Can’t Sacrifice Partition Tolerance (2010)

#14

Maybe I'm missing something, but it seems like this is basically just glossing over this part: > Some systems cannot be partitioned. Single-node systems (e.g., a monolithic Oracle server with no replication) are incapable of experiencing a network partition. But practically speaking these are rare; I'm not sure how the writer came to the conclusion that these systems are rare. The website I'm working on now has a sin…

Also, per the article, a single node system WITHOUT REPLICATION. That would hopefully be quite rare, as it means you have a single point of failure, with no automated recovery plan.

But as soon as you have replication...you have distribution, and what happens when a partition occurs, where the master can no longer talk to the replica(s)? That's where CAP applies; the system -will- make a decision about what to do, and in doing so will trade availability for consistency, or consistency for availability, for any given read/write scenario.

Re: You Can’t Sacrifice Partition Tolerance (2010)

#15
post #5

Earlier quoted context omitted.

You skipped the second part of that. Unless your web application is running on the database server then you are no longer running single node, your web app and db server can become partitioned.

Ah, okay, I didn't understand that next part correctly the first time. So that does account for why the author says such systems are rare. But that doesn't really help me understand why CA can't exist. There are still systems that simply don't have network partitions. SQLite on the same phone as the app using it? As I said, it doesn't seem like we ignore the rare or uninteresting cases.

Clustered CA systems can exist and they corrupt data (maybe silently) when a partition happens. In most discussions it is taken for granted that people don't tolerate data corruption.

Single-node "CA" systems are "available" under CAP's definition but not available under the common sense definition. A single hardware failure will take out the entire system (but in theory everything will be in perfect order after you restore from backups).

Re: You Can’t Sacrifice Partition Tolerance (2010)

#16
The original CAP paper was intended as a high-level discussion item for students. Brewer has since emphasized that it is more of an academic approach than applicable to real-world distributed databases.

Other computer scientists have either modified or narrowed it to be more useful.

So it's fun to read the original CAP paper, but it's less useful than you would expect. When somebody asks me about CP vs. CA, I realize they in fact don't anything at all about distributed databases.

Re: You Can’t Sacrifice Partition Tolerance (2010)

#17
post #15

Earlier quoted context omitted.

Ah, okay, I didn't understand that next part correctly the first time. So that does account for why the author says such systems are rare. But that doesn't really help me understand why CA can't exist. There are still systems that simply don't have network partitions. SQLite on the same phone as the app using it? As I said, it doesn't seem like we ignore the rare or uninteresting cases.

Clustered CA systems can exist and they corrupt data (maybe silently) when a partition happens. In most discussions it is taken for granted that people don't tolerate data corruption. Single-node "CA" systems are "available" under CAP's definition but not available under the common sense definition. A single hardware failure will take out the entire system (but in theory everything will be in perfect order after you…

A "clustered CA" system that corrupts data sounds like a AP system.

Re: You Can’t Sacrifice Partition Tolerance (2010)

#18
post #8
post #5

Earlier quoted context omitted.

You skipped the second part of that. Unless your web application is running on the database server then you are no longer running single node, your web app and db server can become partitioned.

Even if your web app and database are on the same server, you may experience partitions between the client and server.

You can, but it's vastly less likely than networking partitions assuming your DB is operating as expected.

Re: You Can’t Sacrifice Partition Tolerance (2010)

#19
post #17
post #15

Earlier quoted context omitted.

Clustered CA systems can exist and they corrupt data (maybe silently) when a partition happens. In most discussions it is taken for granted that people don't tolerate data corruption. Single-node "CA" systems are "available" under CAP's definition but not available under the common sense definition. A single hardware failure will take out the entire system (but in theory everything will be in perfect order after you…

A "clustered CA" system that corrupts data sounds like a AP system.

During a partition an AP system just returns stale data but a CA system may completely crash or lose all data.

Re: You Can’t Sacrifice Partition Tolerance (2010)

#20
post #6

Maybe I'm missing something, but it seems like this is basically just glossing over this part: > Some systems cannot be partitioned. Single-node systems (e.g., a monolithic Oracle server with no replication) are incapable of experiencing a network partition. But practically speaking these are rare; I'm not sure how the writer came to the conclusion that these systems are rare. The website I'm working on now has a sin…

If you read the next sentence he says > But practically speaking these are rare; add remote clients to the monolithic Oracle server and you get a distributed system which can experience a network partition (e.g., the Oracle server becomes unavailable).

The theory in question addresses distributed database systems. A remote client connected to a monolithic database is not a distributed database system. If there is a network partition between the client and the server then you don't get C or A. You get nothing.

The P refers to partitions between nodes of the database system. Not clients.

So that point in the article doesn't seem to make sense.

Post reply on HN