The Sorted String Table (SSTable) is one of the most popular outputs for storing, processing, and exchanging datasets.
An SSTable
is a simple abstraction to efficiently store large numbers of key-value
pairs while optimizing for high throughput, sequential read/write
workloads.

Unfortunately, the SSTable name itself has
also been overloaded by the industry to refer to services that go well
beyond just the sorted table, which has only added unnecessary confusion
to what is a very simple and a useful data structure on its own. Let's
take a closer look under the hood of an SSTable and how LevelDB makes
use of it.

SSTable: Sorted String Table

SSTable本身是个简单而有用的数据结构, 而往往由于工业界对于它的overload, 导致大家的误解
它本身就像他的名字一样, 就是a set of sorted key-value pairs
如下图左, 当文件比较大的时候, 也可以建立key:offset的index, 用于快速分段定位, 但这个是可选的.

这个结构和普通的key-value pairs的区别, 可以support range query和random r/w

A "Sorted String Table" then is exactly what it sounds like, it is a file which contains a set of arbitrary, sorted key-value pairs inside.
Duplicate
keys are fine, there is no need for "padding" for keys or values, and
keys and values are arbitrary blobs. Read in the entire file
sequentially and you have a sorted index. Optionally, if the file is
very large, we can also prepend, or create a standalone key:offset index for fast access.

That's all an SSTable is: very simple, but also a very useful way to exchange large, sorted data segments.

SSTables and Log Structured Merge Trees

仅仅SSTable数据结构本身仍然无法support高效的range query和random r/w的场景
还需要一整套的机制来完成从memory sort, flush to disk, compaction以及快速读取……这样的一个完成的机制和架构称为,"The Log-Structured Merge-Tree" (LSM Tree)
名字很形象, 首先是基于log的, 不断产生SSTable结构的log文件, 并且是需要不断merge以提高效率的

下图很好的描绘了LSM Tree的结构和大部分操作