random and sequential IO are nothing but access pattern of the data which is also dependent on how the

application
wants the data access.

"Random" means you can get any part of the file in any order. So for example, you can read the middle part before
the start.
"Sequential" means you must first read the first part of the file, before reading second, then third etc.. figure below
explains .

Accessing/writing data sequentially is much faster than accessing/writing it randomly

because of the way in which the disk hardware works. The seek operation, which occurs
when the disk head positions itself at the right disk cylinder to access data requested, takes
more time than any other part of the I/O process. Because reading randomly involves a
higher number of seek operations than does sequential reading, random reads deliver a
lower rate of throughput. The same is true for random writing.

Analogy :
In older times, when playing a record, the needle/head follows one track around the surface of the disk. This is
sequential read. The difference between sequential read and random read is a random read is similar to if you pick up
the head and try to find the next track and let it play. Doing so causes music to stop playing while there is a "random"
seek.

Random versus Sequential I/O

I have another article planned for later in this series which describes the inescapable
mechanics of disk. For now though, I'll outline the basics: every time you need to
access a block on a disk drive, the disk actuator arm has to move the head to the
correct track (the seek time), then the disk platter has to rotate to locate the correct
sector (the rotational latency). This mechanical action takes time, just like the sushi
travelling around the conveyor belt.

Obviously the amount of time depends on

where the head was previously located and how fortunate you are with the location
of the sector on the platter: if its directly under the head you do not need to wait, but
if it just passed the head you have to wait for a complete revolution. Even on the
fastest 15k RPM disk that takes 4 milliseconds (15,000 rotations per minute = 250
rotations per second, which means one rotation is 1/250th of a second or 4ms).
Admittedly thats faster than the sushi in my earlier analogy, but the chances are you
will need to read or write a far larger number of blocks than I can eat sushi dishes
(and trust me, on a good day I can pack a fair few away).
What about the next block? Well, if that next block is somewhere else on the disk,
you will 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, of course, is
a sequential I/O.

Size Matters
In my last post I described the Fundamental Characteristics of Storage: Latency,
IOPS and Bandwidth (or Throughput). As a reminder, IOPS stands for I/Os Per
Second and indicates the number of distinct Input/Output operations (i.e. reads or
writes) that can take place within one second. You might use an IOPS figure to
describe the amount of I/O created by a database, or you might use it when defining

the maximum performance of a storage system. One is a real-world value and the
other a theoretical maximum, but they both use the term IOPS.

When describing volumes of data, things are slightly

different. Bandwidth is usually used to describe the maximum theoretical limit of data
transfer, while throughput is used to describe a real-world measurement. You might
say that the bandwidth is the maximum possible throughput. Bandwidth and
throughput figures are usually given in units of size over units of time, e.g. Mb/sec or
GB/sec. It pays to look carefully at whether the unit is using bits (b) or bytes (B),
otherwise you are likely to end up looking a bit silly (sadly, I speak from experience).
In the previous post we stated that IOPS and throughput were related by the
following relationship:
Throughput = IOPS x I/O size
Its time to start thinking about that I/O size now. If we read or write a
single random block in one second then the number of IOPS is 1 and the I/O size is
also 1 (Im using a unit of blocks to keep things simple). The Throughput can
therefore be calculated as (1 x 1) = 1 block / second.
Alternatively, if we wanted to read or write eight contiguous blocks from disk as
a sequential operation then this again would only result in the number of IOPS being
1, but this time the I/O size is 8. The throughput is therefore calculated as (1 x 8) = 8
blocks / second.
Hopefully you can see from this example the great benefit of sequential I/O on disk
systems: it allows increased throughput. Every time you increase the I/O size you
get a corresponding increase in throughput, while the IOPS figure remains resolutely
fixed. But what happens if you increase the number of IOPS?

Latency Kills Disk Performance

In the example above I described a single-threaded process reading or writing a
single random block on a disk. That I/O results in a certain amount of latency, as
described earlier on (the seek time and rotational latency). We know that the

average rotational latency of a 15k RPM disk is 4ms,

so lets add
another millisecond for the disk head seek time and call the average I/O latency
5ms. How many (single-threaded) random IOPS can we perform if each operation
incurs an average of 5ms wait? The answer is 1 second / 5 ms = 200 IOPS. Our
process is hitting a physical limit of 200 IOPS on this disk.
What do you do if you need more IOPS? With a disk system you only really have
one choice: add more disks. If each spindle can drive 200 IOPS and you require
80,000 IOPS then you need (80,000 / 200) = 400 spindles. Better clear some space
in that data centre, eh?
On the other hand, if you can perform the I/O sequentially you may be able to
reduce the IOPS requirement and increase the throughput, allowing the disk system
to deliver more data. I know of Oracle customers who spend large amounts of time
and resources carving up and re-ordering their data in order to allow queries to
perform sequential I/O. They figure that the penalty incurred from all of this
preparation is worth it in the long run, as subsequent queries perform better. Thats
no surprise when the alternative was to add an extra wing to the data centre to
house another bunch of disk arrays, plus more power and cooling to run them. This
sort of no pain, no gain mentality used to be commonplace because there really
weren't any other options. Until now.

Flash Offers Another Way

The idea of sequential I/O doesn't exist with flash memory, because there is no
physical concept of blocks being adjacent or contiguous. Logically, two blocks may
have consecutive block addresses, but this has no bearing on where the actual
information is electronically stored. You might therefore say that all flash I/O is
random, but in truth the principles of random I/O versus sequential I/O are disk
concepts so don't really apply. And since the latency of flash is sub-millisecond, it
should be possible to see that, even for a single-threaded process, a much larger
number of IOPS is possible. When we start considering concurrent operations things
get even more interesting but that topic is for another day.

Back to the sushi analogy, there is no longer a conveyor belt

the chefs are standing right in front of you. When you order a dish, it is placed in
front of you immediately. Order a number of dishes and you might want to enlist the
help of a few friends to eat in parallel, because the food will start arriving faster than
you can eat it on your own. This is the world of flash memory, where hunger for data
can be satisfied and appetites can be fulfilled. Time to break that disk diet, eh?
Looking back at the disk model, all that sitting around waiting for the sushi conveyor
belt just takes too long. Sure you can add more conveyor belts or try to get all of
your sushi dishes arranged in a line, but at the end of the day the underlying
problem remains: its disk. And now that theres an alternative, disk just seems a bit
too fishy to me
IOPS can be measured with applications, such as Iometer (originally developed by Intel), as well
as IOzone and FIO[3] and is primarily used with servers to find the best storage configuration.