4 ms·

Wouldn't SSDs - and even better system-bus-connected storage contraptions - also drive the use of different algorithms? I can see how merely cutting the disk la

by jakub_h 11y ago

Wouldn't SSDs - and even better system-bus-connected storage contraptions - also drive the use of different algorithms? I can see how merely cutting the disk latencies by two (or more) orders of magnitude leaves you starved for computational resources, but you don't have to do many things at that point. Data packing is different (could be even CPU matched now?), access patterns can be more random, etc.

dietrichepp 11y ago
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.
- njohnson41 11y ago
  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.
- danielbarla 11y ago
  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.
- vardump 11y ago
  > 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.

by jakub_h 11y ago

dietrichepp 11y ago

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.

njohnson41 11y ago
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.
danielbarla 11y ago
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.
vardump 11y ago
> 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.