The Sushi Effect: Random vs. Sequential I/O

When you're in a sushi restaurant, do you wait til the food comes round at random on a conveyor belt? Or do you order it from the chef and receive your food sequentially? Welcome to the disk data diet.

Ever eaten at a sushi restaurant where the food travels round in dishes on a conveyor belt? As each dish travels around the loop you eye it up and (as long as you make your mind up in time) grab it. Miss the opportunity and you’ll have to wait for it to travel the whole belt before you get another chance. Accessing data on disk storage is a lot like this.

Let’s assume it takes a dish exactly four minutes to complete a whole lap of the conveyor belt. And for simplicity’s sake let’s also assume that no two dishes on the belt are identical. As a hungry diner you look at the menu and see a dish you want. It’s somewhere on the belt, so how long will it take to arrive?

Probability dictates that it could be anywhere on the belt. It could be passing by right now, requiring no wait time – or it could have just passed out of reach, requiring four minutes of wait time to go all the way round again.

This random method (choosing from the menu then waiting at the belt) results in the average wait time being halfway between the min and max times, i.e. two minutes. If you have eight dishes the odds say you’ll spend sixteen (eight x two) minutes waiting for your food. Welcome to the disk data diet.

An alternative option is to order eight dishes from the chef, who then places all of them sequentially (i.e. next to each other) somewhere on the belt. That location is random, so again you’ll wait anywhere between zero and four minutes (an average of two minutes) for the first dish to arrive, but the next seven will follow on with no further wait time. In this scenario, you only had to wait two minutes for all eight dishes – a much better scenario for the hungry diner.

Random vs. Sequential I/O

To translate the analogy, replace the conveyor belt with a hard disk and the sushi dishes with data blocks that are being requested by an application.

The inescapable mechanics of disk mean that every time a block on a disk drive is accessed, the disk actuator arm will move the head to the correct track (the “seek time”), then the disk platter must rotate to locate the correct sector (the “rotational latency”). This mechanical action takes time, just like the sushi travelling around the conveyor belt.

And as with the sushi, the wait time is variable. Get lucky and it could be zero, but even on the fastest 15k RPM disk a full revolution takes 4 milliseconds – a lifetime in the nanosecond world of CPUs.

What about the next block? If it’s somewhere else on disk, you’ll need to incur the same penalties of seek time and rotational latency. We call this type of operation a random I/O. But if the next block happened to be located directly after the previous one on the same track, the disk head would encounter it immediately afterwards, incurring no wait time (i.e. no latency). This is a sequential I/O.

Both random and sequential I/Os incur the penalty of mechanical latency – yet sequential I/Os return multiple blocks while random I/Os return just one. Put simply, on disk, random workloads pay a higher price.

The Flash Memory Effect

Flash memory systems store data on silicon and have no mechanical parts. Compared to disk this obviously brings performance benefits, as well as saving on power and cooling bills. But it also means there is no longer a concept of blocks being adjacent. Not only is the latency orders-of-magnitude lower, there is no penalty for choosing random over sequential: all blocks are equal on flash.

Back to the sushi analogy, there is no longer a conveyor belt – the chefs are standing right in front of you. Order a dish and it arrives immediately. Order in bulk and you might want to enlist the help of some friends to eat in parallel, because the food will come faster than you can consume it on your own. In the world of flash memory, hunger for data can be satisfied and appetites can be fulfilled. It’s time to break that disk diet.

All that sitting around waiting at the sushi conveyor belt takes too long. Sure, you can add more conveyor belts or arrange all of your dishes in a line, but the underlying problem remains; it’s mechanical. In the flash data center, disk storage – like last week’s sushi – is just a little bit too fishy.


Chris Buckel is Database Specialist at Violin Memory, and maintains a popular blog at