Hacker News Reader

Comment by dietrichepp | Hacker News Reader

That's an interesting question, but I expect many of the algorithms will stay the same. Think of a computer as having a multi-level cache: network -> disk -> ram -> L2 cache -> L1 cache -> register, each one smaller than the last. We're seeing a big change in disk latency, but that's only one part of the chain. For example, we're still going to be optimizing data structures to fit in L1 cache lines.

View on HN

Interestingly, that may be the new ordering if the disks are SSDs, but the typical seek latency on a spinning disk (~5 ms) is definitely higher than the latency to read data from another machine's memory across ethernet (a few hundred us), and even the bandwidths are comparable (~150 MB/s).

So, now it has jumped from (disk -> network -> memory -> ...) to (network -> disk -> memory -> ...), which is a big change.

> network -> disk -> ram -> L2 cache -> L1 cache -> register

It's more and more like network/disk -> L3 cache -> L2 cache. DRAM is pretty slow.

Because PCIe controller is anyways on the same chip as L3 cache, there's no reason to send the data on a long trip to DRAM and back. Until, of course, when the cache line gets evicted for reason or another.

Having said that, I do wonder to what degree various database engines are aware of the underlying disk platforms.

I've definitely noticed that when optimizing a query and deciding between a high number of seeks vs. a table scan, older versions of MSSQL will tend to be pessimistic of drive latencies and just go with the full scan (potentially incorrectly / prematurely). In an uncached scenario on an SSD, this is probably sub-optimal. My guess would be that instead of looking at actual seek latency, the optimizer was using reasonable guesses for spinning disks. I'm guessing newer versions are more SSD aware though.

Reply on news.ycombinator.com