4 ms·

HP still manufactures and maintains Tandem systems, under the HPE Integrity Nonstop brand [1]. Just like IBM Systems Magazine [2], there is a lot of proprietary

HP still manufactures and maintains Tandem systems, under the HPE Integrity Nonstop brand [1]. Just like IBM Systems Magazine [2], there is a lot of proprietary tech described that takes awhile to seep into Linux and the open source world. You can still read the Tandem documentation, so the ideas are still there to be picked up by anyone interested in re-implementing them on Linux. [1] https://www.hpe.com/us/en/servers/nonstop.html https://www.hpe.com/us/en/servers/nonstop.html [2] http://ibmsystemsmag.com/ http://ibmsystemsmag.com/

atombender 8y ago
Is there a technical writeup anywhere about the design and architecture of Tandem? One that has enough detail that a skilled database designer could understand it well enough to reimplement it?
- yourapostasy 8y ago
  Not in one place, and not sufficient to give anyone an implementation roadmap, but that is to be expected, as this is still a commercially-active architecture. They're not about to give away their architectural advantages that easily. But if you read between the lines, and are savvy enough to look up the background research papers, you'll pick up most of the technology. The devil as they say however, is in the engineering details, and that's where you'll run into a lot of special sauce. You'll want to look at their Transaction Monitoring Facility (TMF) in detail. They baked fault tolerance right into the bones of the architectural design, and TMF is an identifiable chunk of how that was done. You aren't going to be able to pull off the same kind of fault tolerance they're delivering at just the database level, too. Their thinking about fault tolerance goes way beyond, down into the hardware level though it stops short of the silicon.
- wmf 8y ago
  https://jimgray.azurewebsites.net/papers/TEs.pdf https://jimgray.azurewebsites.net/papers/TEs.pdf I don't have the background to fully understand this stuff, but it claims "The first distributed SQL -- it offers distributed data, distributed execution, and distributed transactions." while every single NoSQL/NewSQL article says things like "Legacy databases (typically the centralized RDBMS) solve this problem by being undistributed."
  - evanweaver 8y ago
    That claim is technically true. There's a lot of good stuff in here—partitioned locks, transaction recovery journals, a realistic expectation of WAN latency and reliability—but page 20 ("Local Autonomy") and page 37 ("NonStop Operation") give clues as to the differences from modern systems. Rather than build consensus-based high availability into the software, NonStop SQL relies on custom hardware and redundant networks that are designed to never fail. If they do fail, some portion of the data or some types of modifications become unavailable and the operator is expected to intervene and make choices about how to proceed. They give an example of being unable to run an ALTER TABLE statement because two datacenters that each own a shard of the table are disconnected—the statement can't be run at either datacenter during the partition. They give other examples where queries return partial results because a specific shard is down. This is potentially a correctness violation if it is not explicit, and it is definitely a loss of availability. Modern distributed systems are instead designed to maintain almost total levels of availability on constantly failing hardware, and heal themselves immediately and autonomously without losing correctness.

atombender 8y ago

Is there a technical writeup anywhere about the design and architecture of Tandem? One that has enough detail that a skilled database designer could understand it well enough to reimplement it?

yourapostasy 8y ago
Not in one place, and not sufficient to give anyone an implementation roadmap, but that is to be expected, as this is still a commercially-active architecture. They're not about to give away their architectural advantages that easily. But if you read between the lines, and are savvy enough to look up the background research papers, you'll pick up most of the technology. The devil as they say however, is in the engineering details, and that's where you'll run into a lot of special sauce. You'll want to look at their Transaction Monitoring Facility (TMF) in detail. They baked fault tolerance right into the bones of the architectural design, and TMF is an identifiable chunk of how that was done. You aren't going to be able to pull off the same kind of fault tolerance they're delivering at just the database level, too. Their thinking about fault tolerance goes way beyond, down into the hardware level though it stops short of the silicon.
wmf 8y ago
https://jimgray.azurewebsites.net/papers/TEs.pdf https://jimgray.azurewebsites.net/papers/TEs.pdf I don't have the background to fully understand this stuff, but it claims "The first distributed SQL -- it offers distributed data, distributed execution, and distributed transactions." while every single NoSQL/NewSQL article says things like "Legacy databases (typically the centralized RDBMS) solve this problem by being undistributed."
- evanweaver 8y ago
  That claim is technically true. There's a lot of good stuff in here—partitioned locks, transaction recovery journals, a realistic expectation of WAN latency and reliability—but page 20 ("Local Autonomy") and page 37 ("NonStop Operation") give clues as to the differences from modern systems. Rather than build consensus-based high availability into the software, NonStop SQL relies on custom hardware and redundant networks that are designed to never fail. If they do fail, some portion of the data or some types of modifications become unavailable and the operator is expected to intervene and make choices about how to proceed. They give an example of being unable to run an ALTER TABLE statement because two datacenters that each own a shard of the table are disconnected—the statement can't be run at either datacenter during the partition. They give other examples where queries return partial results because a specific shard is down. This is potentially a correctness violation if it is not explicit, and it is definitely a loss of availability. Modern distributed systems are instead designed to maintain almost total levels of availability on constantly failing hardware, and heal themselves immediately and autonomously without losing correctness.