3 ms·
> extremely fast IO. I wonder how big a competitive edge that will remain in an era where ordinary cloud VMs can do 10 GB/s to zone-redundant remote storage.
by jiggawatts 1y ago
> extremely fast IO.
I wonder how big a competitive edge that will remain in an era where ordinary cloud VMs can do 10 GB/s to zone-redundant remote storage.
- inkyoto 1y agoGuaranteed sustained write throughput is a distinguished feature of the mainframe storage. Whilst cloud platforms are the new mainframe (so to speak), and they have all made great strides in improving the SLA guarantees, storage is still accessed over the network (plus extra moving parts – coordination, consistency etc). They will get there, though.
- Cthulhu_ 1y agoGB/s is one metric, but IOPS and latency are others that I'm assuming are Very Important for the applications that mainframes are being used for today.
- imtringued 1y agoIOPS is the most meaningless metric there is. It's just a crappy way of saying bandwidth with an implied sector size. 99% of software developers do not use any form of async file IO and therefore couldn't care less. The async file IO support in postgres has been released a month ago. It's that niche of a thing that even extremely mature software that could heavily benefit from it hasn't bothered implementing it until last month.
- jiggawatts 1y agoMicrosoft SQL Server has been using async scatter/gather IO APIs for decades. Most database engines I've worked with do so. Postgres is weirdly popular despite being way, way behind on foundational technology adoption.
- rbanffy 1y ago> Microsoft SQL Server has been using async scatter/gather IO APIs for decades. Most database engines I've worked with do so. Windows NT has asynchronous IO since its VAX days ;-) > Postgres is weirdly popular despite being way, way behind on foundational technology adoption. It's good enough, free, and performs well.
- jiggawatts 1y agoI constantly hear about VACUUM problems and write amplification causing performance issues bad enough that huge users of it were forced to switch to MySQL instead.
- pgaddict 1y agoI've been involved in a couple of those cases, where a large company ran into an issue, and chose to solve it by migrating to something else. And while the issues certainly exist (and are being addressed), the technical reasons often turned out to be a rather tiny part of the story. And in the end it was really about internal politics and incentives. In several such cases, the company was repeatedly warned about how they implemented some functionalities, and that it will cause severe issues with bloat/vacuuming, etc. Along with suggestions how to modify the application to not hit those issues. Their 10x engineers chose to completely ignore that advice, because in their minds they constructed an "ideal database" and concluded that anything that behaves differently is "wrong" and it's not their application that should change. Add a dose of politics where a new CTO wants to rebuild everything from scratch, engineers with NIH syndrome, etc. It's about incentives - if you migrate to a new system, you can write flashy blog posts how the new system is great and saved everything. You can always argue the original system would be worse, because everyone saw it had issues - you just leave out the details about choosing not to address the issues. The engineering team is unlikely to argue against that, because that'd be against their interests too. I'm absolutely not claiming the problems do not exist. They certainly do. Nor am I claiming Postgres is the ideal database for every possible workload. It certainly is not. But the worst examples that I've seen were due to deliberate choices, driven by politics. But that's not described anywhere. In public everyone pretends it's just about the tech.
- deleted 1y ago[deleted]
- RetroTechie 1y agoOn-site. Speed is not the only reason why some org/business would have Big Iron in their closet.
- FuriouslyAdrift 1y agoLatency is much more important than thoughput...