Hacker News Reader

Comment by metildaa | Hacker News Reader

Optane will be squandered by limited CPU support and slim software support :c

Optane is a neat idea, but the severe change in software architecture combined with only select CPUs even supporting it will limit uptake outside FAANGs or organizations with really specialized needs.

View on HN

Databases will love Optane. There have been companies showing how much they are willing to spend on database hardware and software for ages. I'm not sure that will change any time soon.

Yep, exactly what I was getting at. If you have a giant database and a big budget, Optane is great. It could be really useful for smaller users too, but its unlikely to become widely popular as the average developer won't have it available in their laptop or desktop.

Not so sure about this. World is increasingly moving to distributed scale out databases. Once you go that way consensus algorithms and rpc costs dwarf disk io speed.

Not everyone is building apps which need to be "web scale". Optane has the potential to significantly raise the performance ceiling of a single-master database. I bet there are a lot of companies who will happily drop six figures on Optane systems if it saves them the complexity of managing a distributed database.

The niche where your present requirements are big enough to benefit from Optane and your future requirements are small enough to not need to go distributed is pretty narrow.

Finance, healthcare, and enterprise systems.

I'm not sure it's really a niche.

I've worked for a company that was willing to spend that kind of money on monolithic database servers. They were a top-100 website though, and this was the best part of a decade ago (and thus e.g. in the pre-SSD era).

They were also scrambling to move all their services away from use of that database in favour of a horizontally scaled system that could grow further.

The query rate that can be handled by a single conventional server are pretty monstrous these days. You'd have to be simultaneously a) maybe top-50 website level load (I'm well aware that there's a lot more than websites out there, but at the same time there really aren't that many organizations working at that scale, much as there are many that think they are) and b) confident that you weren't going to grow much.

The real world is much bigger than websites/apps.

It is, and I acknowledged that. But it gives a sense of the scale involved. Just as there are very few websites/apps that need to handle, what, 2000 requests/second (and simultaneously don't intend growing by more than a factor of two or so), systems that need that kind of performance in any other field are similarly rare.

Not really, it’s also not necessarily not needing to grow but not everything can scale in the same manner as Netflix or Facebook.

Financial systems especially trading platforms need to ensure market fairness they also need to have at the end a single database as you can’t have any conflicts in your orders and the orders need to be executed in the order they came in across the entire system not just a single instance.

This means that even when they do end up with some micro-service-esque architecture for the front end it still talks to a single monolithic database cluster in the end which is used to record and orchestrate everything.

That is indeed one case where a large single-node database makes a certain amount of sense (though it's not the only solution; you need a globally consistent answer for which orders match with which, but that doesn't have to mean a single database node. Looking at the transaction numbers I'd assume that e.g. the busiest books on NYSE must be multi-node systems just because of the transaction rates). But fundamentally there are what, 11 equity exchanges in the US total (and less than half of those are high-volume). And the market fairness requirements are very specific to one particular kind of finance; they're not something that would be needed in healthcare, general enterprise, or most financial applications. Like I said, niche.

That really depends on the workload.

You are correct.

Optane will be seen as a really big main memory by the OS and that's it. So, I don't get why there will be severe changes in software..

Optane is not durable enough to survive as main memory, hence use cases using it as primarily read memory to avoid wearing out the cells with writes.

Take a look at how cagey Intel is acting about Optane: https://www.semiaccurate.com/2018/05/31/intel-dodges-every-q...

This is the same behaviour as with Intel's LTE chips, where promised features keep slipping (much to Apple's dismay).

SemiAccurate's singing a different tune this year, now that Intel has stated that the Optane DC Persistent Memory modules are warrantied for 5 years regardless of workload. Intel's gotten write endurance up to sufficient levels for use as main memory, though if you use those DIMMs as memory rather than storage, then your DRAM will be used as a cache.

The new DIMMs Intel is putting out have a RAM cache in front of the optane memory that will absorb all the churn plus a wear leveling algorithm on the writeback side. It has big enough capacitors to put all its data away in the event of power loss.

https://www.storagereview.com/intel_optane_dc_persistent_mem...

All of which looks to solve the wear problem even if it means higher price and latency.

Reply on news.ycombinator.com