Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The CAP theorem. The Bad, the Bad, & the Ugly

blog.dtornow.com

Post reply on HN
Print view View original

21–30 of 81 posts

Re: The CAP theorem. The Bad, the Bad, & the Ugly

#21

Post by valenterry »

djha-skin wrote: post #20
valenterry wrote: post #16

Earlier quoted context omitted.

They don't provide availability, because if they go down, they are down. For example, if there is a fire, the whole thing is gone. That's a choice you make.

Datacenter fires cause downtime no matter what consistency model you choose. Also, mainframes are pretty big, multi-processor machines. They have their problems, but having all those components give out all at once? I'm sure it happens, but I've never heard of it.

> Datacenter fires cause downtime no matter what consistency model you choose.

Why that? I can distribute my nodes over multiple datacenters. Netflix does that even with whole regions (to my knowledge) to avoid downtime when a region goes down.

Re: The CAP theorem. The Bad, the Bad, & the Ugly

#22

Post by largbae »

jameshart wrote: post #18
valenterry wrote: post #16

Earlier quoted context omitted.

They don't provide availability, because if they go down, they are down. For example, if there is a fire, the whole thing is gone. That's a choice you make.

Mainframes have a ton of internal redundancy that enables insanely high avaialability, absent destruction. All ‘availability’ rests on some assumed radius of safety. A nuclear blast in northern Virginia can take out all the availability zones for AWS US-East-1 - that doesn’t invalidate the availability claims of a system that is distributed across three AZs, it just puts an upper limit on it.

"All availability rests on some assumed radius of safety", thank you for that! If this is not a named law could you name it? I have needed this statement in the past but it never came together like that.

Re: The CAP theorem. The Bad, the Bad, & the Ugly

#23

Post by djha-skin »

valenterry wrote: post #21
djha-skin wrote: post #20

Earlier quoted context omitted.

Datacenter fires cause downtime no matter what consistency model you choose. Also, mainframes are pretty big, multi-processor machines. They have their problems, but having all those components give out all at once? I'm sure it happens, but I've never heard of it.

> Datacenter fires cause downtime no matter what consistency model you choose. Why that? I can distribute my nodes over multiple datacenters. Netflix does that even with whole regions (to my knowledge) to avoid downtime when a region goes down.

In theory yes, and certainly if we're talking about Cassandra. In practice, most people do not distribute over multiple data centers. Doing so is very difficult and costly.

Re: The CAP theorem. The Bad, the Bad, & the Ugly

#24

Post by valenterry »

jameshart wrote: post #18
valenterry wrote: post #16

Earlier quoted context omitted.

They don't provide availability, because if they go down, they are down. For example, if there is a fire, the whole thing is gone. That's a choice you make.

Mainframes have a ton of internal redundancy that enables insanely high avaialability, absent destruction. All ‘availability’ rests on some assumed radius of safety. A nuclear blast in northern Virginia can take out all the availability zones for AWS US-East-1 - that doesn’t invalidate the availability claims of a system that is distributed across three AZs, it just puts an upper limit on it.

Sure. But the thing is: is there literally not a single component in that mainframe that cannot cause a single point of failure to the whole system?

If so, I agree - in that case it would be similar to running two severs in the same AZ. Which provides a certain form of availability.

Otherwise I disagree, because as soon as you have a single point of failure, your system is limited by the availability of that specific part, whereas in a distributed system you can by design increase availability by adding more nodes, at least up to a certain point.

Think about it: I can run the two servers I mentioned about in the same AZ. But I can also move them to a separate AZ each. For a distributed system it doesn't matter conceptually. That doesn't mean that there is no impact on the availability or performance, it just means that I don't have to change the logic of my system.

For a mainframe however that's not true - and that is what makes the charm of it: because I don't have (and don't want) to care, which simplifies things a lot; at the expensive of (the option of) the availability of a distributed system.

Re: The CAP theorem. The Bad, the Bad, & the Ugly

#25

Post by valenterry »

djha-skin wrote: post #23
valenterry wrote: post #21

Earlier quoted context omitted.

> Datacenter fires cause downtime no matter what consistency model you choose. Why that? I can distribute my nodes over multiple datacenters. Netflix does that even with whole regions (to my knowledge) to avoid downtime when a region goes down.

In theory yes, and certainly if we're talking about Cassandra. In practice, most people do not distribute over multiple data centers. Doing so is very difficult and costly.

Haha, I've been there. Three companies I've been with have done that - and every time we had more downtime overall than had we just run a mirrored postgres.

But yeah, the theory is what I'm talking about. Not putting the theory into practice is a whole different matter. :-)

Re: The CAP theorem. The Bad, the Bad, & the Ugly

#26

Post by filleokus »

valenterry wrote: post #24
jameshart wrote: post #18

Earlier quoted context omitted.

Mainframes have a ton of internal redundancy that enables insanely high avaialability, absent destruction. All ‘availability’ rests on some assumed radius of safety. A nuclear blast in northern Virginia can take out all the availability zones for AWS US-East-1 - that doesn’t invalidate the availability claims of a system that is distributed across three AZs, it just puts an upper limit on it.

Sure. But the thing is: is there literally not a single component in that mainframe that cannot cause a single point of failure to the whole system? If so, I agree - in that case it would be similar to running two severs in the same AZ. Which provides a certain form of availability. Otherwise I disagree, because as soon as you have a single point of failure, your system is limited by the availability of that specific…

I've been "arguing" AGAINST mainframes on HN in the past, and after that I've seen many really cool presentations about them. One, quite commonly known, is that two separate mainframes can run completely in lock-step if they are less than ≈ 50 km / 30 mi apart. So if one explodes mid instruction it will still continue fine. As for a single system, I don't think there is any single point of failure, you can swap cpu's mid operation.

Re: The CAP theorem. The Bad, the Bad, & the Ugly

#27

Post by super_mario »

I view CAP theorem as statement about the universe we live in (information travels at speed of light, "instantaneous" is observer dependant etc), and not as a consequence of information theoretic definitions we chose to adopt (strength of consistency or availability). Yes, when stated simplistically (you have 3 properties C, A, P choose 2) can be extremely misleading, since you can't really choose P, you can only decide what to do in case of P. But like any mathematical theorem one has to understand the preconditions when the theorem applies, understand the various computing model assumptions etc. to actually use it.

Notwithstanding, I still find it very useful as a general guide when designing distributed systems.

Re: The CAP theorem. The Bad, the Bad, & the Ugly

#28

Post by [deleted] »

valenterry wrote: post #24
jameshart wrote: post #18

Earlier quoted context omitted.

Mainframes have a ton of internal redundancy that enables insanely high avaialability, absent destruction. All ‘availability’ rests on some assumed radius of safety. A nuclear blast in northern Virginia can take out all the availability zones for AWS US-East-1 - that doesn’t invalidate the availability claims of a system that is distributed across three AZs, it just puts an upper limit on it.

Sure. But the thing is: is there literally not a single component in that mainframe that cannot cause a single point of failure to the whole system? If so, I agree - in that case it would be similar to running two severs in the same AZ. Which provides a certain form of availability. Otherwise I disagree, because as soon as you have a single point of failure, your system is limited by the availability of that specific…

[deleted]

Re: The CAP theorem. The Bad, the Bad, & the Ugly

#29

Post by [deleted] »

valenterry wrote: post #16
jameshart wrote: post #7

The ‘network partitions are not optional’ interpretation of CAP is forgetting about the fact that non-distributed-systems are a thing . Sure, as soon as you decided to distribute your system across a network you opted into a world where partition can happen, and you will have to give up consistency or availability. Mainframes, though, provide consistency and availability by being unpartitionable except through use of…

They don't provide availability, because if they go down, they are down. For example, if there is a fire, the whole thing is gone. That's a choice you make.

[deleted]

Re: The CAP theorem. The Bad, the Bad, & the Ugly

#30

Post by [deleted] »

valenterry wrote: post #21
djha-skin wrote: post #20

Earlier quoted context omitted.

Datacenter fires cause downtime no matter what consistency model you choose. Also, mainframes are pretty big, multi-processor machines. They have their problems, but having all those components give out all at once? I'm sure it happens, but I've never heard of it.

> Datacenter fires cause downtime no matter what consistency model you choose. Why that? I can distribute my nodes over multiple datacenters. Netflix does that even with whole regions (to my knowledge) to avoid downtime when a region goes down.

[deleted]
Post reply on HN