The Sorted String Table (<code>SSTable</code>) 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本身是个简单而有用的数据结构, 而往往由于工业界对于它的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 <code>key:offset</code> index for fast access.
That's all an SSTable is: very simple, but also a very useful way to exchange large, sorted data segments.
仅仅SSTable数据结构本身仍然无法support高效的range query和random r/w的场景
名字很形象, 首先是基于log的, 不断产生SSTable结构的log文件, 并且是需要不断merge以提高效率的
下图很好的描绘了LSM Tree的结构和大部分操作
本文转自张昺华-sky博客园博客，原文链接：http://www.cnblogs.com/bonelee/p/6408775.html，如需转载请自行联系原作者