←back to thread

SSDs have become fast, except in the cloud

(databasearchitects.blogspot.com)
589 points greghn | 2 comments | | HN request time: 0s | source
Show context
pclmulqdq ◴[] No.39443994[source]
This was a huge technical problem I worked on at Google, and is sort of fundamental to a cloud. I believe this is actually a big deal that drives peoples' technology directions.

SSDs in the cloud are attached over a network, and fundamentally have to be. The problem is that this network is so large and slow that it can't give you anywhere near the performance of a local SSD. This wasn't a problem for hard drives, which was the backing technology when a lot of these network attached storage systems were invented, because they are fundamentally slow compared to networks, but it is a problem for SSD.

replies(30): >>39444009 #>>39444024 #>>39444028 #>>39444046 #>>39444062 #>>39444085 #>>39444096 #>>39444099 #>>39444120 #>>39444138 #>>39444328 #>>39444374 #>>39444396 #>>39444429 #>>39444655 #>>39444952 #>>39445035 #>>39445917 #>>39446161 #>>39446248 #>>39447169 #>>39447467 #>>39449080 #>>39449287 #>>39449377 #>>39449994 #>>39450169 #>>39450172 #>>39451330 #>>39466088 #
ejb999 ◴[] No.39444046[source]
How much faster would the network need to get, in order to meet (or at least approach) the speed of a local SSD? are we talking about needing to 2x or 3x the speed, or by factors of hundreds or thousands?
replies(5): >>39444115 #>>39444119 #>>39444137 #>>39444150 #>>39444218 #
Nextgrid ◴[] No.39444218[source]
The problem isn't necessarily speed, it's random access latency. What makes SSDs fast and "magical" is their low random-access latency compared to a spinning disk. The sequential-access read speed is merely a bonus.

Networked storage negates that significantly, absolutely killing performance for certain applications. You could have a 100Gbps network and it still won't match a direct-attached SSD in terms of latency (it can only match it in terms of sequential access throughput).

For many applications such as databases, random access is crucial, thus why nowadays' mid-range consumer hardware often outperforms hosted databases such as RDS unless they're so overprovisioned on RAM that the dataset is effectively always in there.

replies(2): >>39444606 #>>39447996 #
Ericson2314 ◴[] No.39447996[source]
Um... why the hell does the network care whether I am doing random or sequential access? Your left that part out of your argument.
replies(1): >>39448284 #
Nextgrid ◴[] No.39448284[source]
Ah sorry, my bad. You are correct that you can fire off many random access operations in parallel and get good throughput that way.

The problem is that this is not possible when the next IO request depends on the result of a previous one, like in a database where you must first read the index to know the location of the row data itself.

replies(1): >>39448578 #
1. Ericson2314 ◴[] No.39448578[source]
OK thanks yes that makes sense. Pipelining problems are real.
replies(1): >>39459410 #
2. Ericson2314 ◴[] No.39459410[source]
(The network indeed doesn't care, but bandwidth of dependent rather than independent accesses depends on latency)