You might want to read the following by Jay Kreps one of the authors of Kafka, Voldermort and Samza:
"SSDs and Distributed Data Systems"
>"On traditional hard drives the trade-off between in-place and log-structured storage is a bit of a wash. Write performance for log-structured storage is vastly better, but most applications have more reads than writes. Read performance may be better or worse depending on the details of the implementation (a traditional log-structured merge tree is definitely worse for reads since it does multiple seeks for each uncached read, but hashing variants or SSTables that use bloom filters to avoid unnecessary lookups need not be). However the move to SSDs completely changes this dynamic. Since SSDs have fast seek performance grouping data by key is much less important.
...
Here are the facts you need to know about SSDs:
They eliminate “seek time” and consequentially make random reads very, very fast"[1]
Source:
[1] http://blog.empathybox.com/post/24415262152/ssds-and-distrib...
Instead of downvoting maybe you could engage in a discussion?
> ... Since SSDs have fast seek performance grouping data...
Clearly, Jay is aware that there is no "seek time" in SSDs :)
Some of the principles remain the same across disk, SSD and RAM. Sequential access is usually faster than random ("seek") access.
Seek time from a storage point of view just means the lookup latency - the cost of jumping to a random source of data (an area on disk or in memory or in another datacenter). You could think of a hash table lookup as "seek time". It could be attributed to an L1/L2 cache reference, main memory reference, physical disk seek or network roundtrip etc.
Just because the concept of "seek time" originated with spinning rust does not mean it must remain there.
A seek is an agreed upon industry concept. A seek is composed of the following components[1]:
• start-up: the arm is accelerated, typically with constant torque (force) until it reaches half of the seek distance, or a fixed maximum velocity;
• coast: for a long seek, the arm will be allowed to coast across most of the distance at its maximum speed;
• slowdown: the arm is brought to rest, hopefully exactly on top of the desired track;
• settle: the disk controller uses servo positioning information to fine-tune the position of the head over the desired track on the selected surface.
Additionally a write seek takes slightly longer than a read seek on a rotating disk, this is because of settling described above. This has no corollary in SSDs.
Rotating disks also have something known as an Average latency which is calculated as the time it takes for the sector of the disk being accessed to rotate into position under a read/write head. The reason I bring this up is because seek and latency are two distinct measurements on mechanical disks and it is the latency measurement which could be applied to SSDs as it is a constant, it mechanical disk this would be gated on the rotational speed of the disk(RPMs)but this is a constant.
And the reason this all matters is that in order to calculate the average IOPS on a mechanical disk you use the following formula:
Divide 1 by the sum of the average latency in ms and the average seek time in ms (1 / (average latency in ms + average seek time in ms).
This formula is obviously meaningless in the context of SSDs.
And average seek time is also well understood to mean:
The average of all possible seek times which technically is the time to do all possible seeks divided by the number of all possible seeks, but in practice it is determined by statistical methods or simply approximated as the time of a seek over one-third of the number of tracks. This formula goes back to IBM and the Winchester drives I believe.
So no in SSDs there is no such thing as a seek. There is simply a latency and that latency is a constant.
SSDs don't have seek times at all as there is no actuator arm and read/write head to "seek" into place in order to read/write data.