[cm2187]

Stupid question. What are the use cases for such massively fast write speeds?

If you are storing data to disk at that speed, you fill even the biggest optane drives in a couple of minutes. So it would be an application where you need to overwrite a huge amount of data over and over again.

[stonewhite]

That also necessitates a matching network bandwidth as well.

It reminds me of the Bugatti Veyron situation, its tires lasting 15 minutes at top speed yet it runs out of fuel in 12.

[falcolas]

I'd rather run out of fuel and drift to a stop, instead of having a blowout and crash while driving at top speed. I'm not sure where the problem lies.

[ReactiveJelly]

It's not a problem with the car, it's an analogy that the fuel and the network are bottlenecks where normally the tires and storage might be.

[falcolas]

Still doesn’t make sense. The car is correctly configured (for safety purposes), and it would also make sense to be able to write to storage faster than your network speeds (no database writes exactly what it receives from the network, it adds metadata and structuring).

[dr_zoidberg]

Digital forensics is a situation where you need extreme IO but you aren't really writing all that much -- it's mostly searches over the forensic copy of computers you are analizing.

As for write speed, you don't really need it unless you're doing file/data recovery, but even then you can just make indexes to the disk image.

AFAIK, very few (if none) are using SCM in their forensic expert workstations, so I can't really tell if you'd saturate the storage capacity or the bandwidth. But in digital forensics, NVMe's have been a must for a while, so this would definitely help.

[yxhuvud]

You can for example flush a temporary db table to storage while doing computations if it ends up too big to fit in memory. Just because it is fast doesn't mean it need to be sustained throughput.

[lmilcin]

A lot of problems don't scale that easily. You may want to prolong the life of the solution by just giving it faster storage. Think in terms of giving faster storage for Oracle DB vs migrating your app to some better scaling nosql solution. SCM might seem expensive until you see the bill for the development costs.

Another use is to have local storage. You want most of the communication to be between your CPU and RAM/SCM and networking only to transmit results. In case of mongodb that would be something like very heavy aggregation that needs to look at a lot of data but transfers relatively small amount of results to the client (think counting number of objects meeting an arbitrary set of specifications). MongoDB actually requires storage for writing intermediate results of some types of operations so it is not purely about read speed.

[deepstack]

Timeseries db is one thing that comes to mind.