5 ms·

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.,

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 single monolithic Postgres server, and the majority of systems I've worked on connected to single monolithic datastores, so at the very least these systems exist. These aren't particularly interesting examples, but when talking theoretically like with the CAP theorem, you don't get to just ignore the rare or uninteresting cases. These seem like relatively common examples of choosing CA. Of course, when you try to shard such databases, you're going to run into serious problems. I guess the claim I can credit to the author is that CA really really really means no partition tolerance. Even one network partition puts you in CP or AP territory. But I don't think that means CA stores don't exist. It may be that I'm just not understanding things correctly, though; the CAP paper is definitely a challenging read for me.

mason55 11y ago
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.
- kerkeslager 11y ago
  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.
  - jasonwatkinspdx 11y ago
    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.
  - wmf 11y ago
    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).
    - sciurus 11y ago
      A "clustered CA" system that corrupts data sounds like a AP system.
      - wmf 11y ago
        During a partition an AP system just returns stale data but a CA system may completely crash or lose all data.
- tl 11y ago
  Even if your web app and database are on the same server, you may experience partitions between the client and server.
  - Xorlev 11y ago
    You can, but it's vastly less likely than networking partitions assuming your DB is operating as expected.
chillacy 11y ago
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).
- deleted 11y ago
  [deleted]
- statictype 11y ago
  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.
  - chillacy 11y ago
    At this point we're edging into a semantic argument, but I would consider client-server architecture to be a type of distributed system. For the record, wikipedia lists "Client server architecture" on their page of distributed systems too: https://en.wikipedia.org/wiki/Distributed_computing#Architectures https://en.wikipedia.org/wiki/Distributed_computing#Architec...
  - zzzcpan 11y ago
    > You get nothing. You don't get nothing, you get inconsistency that could require even human intervention to fix. For example, if client lost connection right before the database was able to respond that his commit was successful. Client then retries and you get a typical double billing problem. That's because monolithic database with a remote client is in fact a distributed system and strong consistency in a distributed system requires proper distributed algorithms and protocols, where clients are nodes too. You cannot guaranty consistency otherwise (to be precise, you will need clients to be able to wait indefinitely to guaranty strong total consistency, but if clients are used by humans they will not do that and the only consistency you can guaranty for a human is eventual consistency).
lostcolony 11y ago
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.
zzzcpan 11y ago
> The website I'm working on now has a single monolithic Postgres server, and the majority of systems I've worked on connected to single monolithic datastores, so at the very least these systems exist. These systems do not guaranty neither consistency, nor availability during network partitions.

mason55 11y ago

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.

kerkeslager 11y ago
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.
- jasonwatkinspdx 11y ago
  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.
- wmf 11y ago
  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).
  - sciurus 11y ago
    A "clustered CA" system that corrupts data sounds like a AP system.
    - wmf 11y ago
      During a partition an AP system just returns stale data but a CA system may completely crash or lose all data.
tl 11y ago
Even if your web app and database are on the same server, you may experience partitions between the client and server.
- Xorlev 11y ago
  You can, but it's vastly less likely than networking partitions assuming your DB is operating as expected.

chillacy 11y ago

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).

deleted 11y ago
[deleted]
statictype 11y ago
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.
- chillacy 11y ago
  At this point we're edging into a semantic argument, but I would consider client-server architecture to be a type of distributed system. For the record, wikipedia lists "Client server architecture" on their page of distributed systems too: https://en.wikipedia.org/wiki/Distributed_computing#Architectures https://en.wikipedia.org/wiki/Distributed_computing#Architec...
- zzzcpan 11y ago
  > You get nothing. You don't get nothing, you get inconsistency that could require even human intervention to fix. For example, if client lost connection right before the database was able to respond that his commit was successful. Client then retries and you get a typical double billing problem. That's because monolithic database with a remote client is in fact a distributed system and strong consistency in a distributed system requires proper distributed algorithms and protocols, where clients are nodes too. You cannot guaranty consistency otherwise (to be precise, you will need clients to be able to wait indefinitely to guaranty strong total consistency, but if clients are used by humans they will not do that and the only consistency you can guaranty for a human is eventual consistency).

lostcolony 11y ago

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.

zzzcpan 11y ago

> The website I'm working on now has a single monolithic Postgres server, and the majority of systems I've worked on connected to single monolithic datastores, so at the very least these systems exist. These systems do not guaranty neither consistency, nor availability during network partitions.