共计 1031 个字符，预计需要花费 3 分钟才能阅读完成。
这篇文章主要讲解了“LSM 的存储以及定位”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着丸趣 TV 小编的思路慢慢深入，一起来研究和学习“LSM 的存储以及定位”吧！
LSM 的存储
主要思想是将直接修改树形结构，改为分几个层级来完成。当完成第一个层级时就反馈完成，其他交由后台来处理。
流程是先写入 memory table，之后 merge 到低级别的 sstable，最后 merge 到高级别的 sstable。
如下是 Hbase 的大体结构：
2. 定位
Trailer–这一段是定长的。保存了每一段的偏移量，读取一个 HFile 时，会首先 读取 Trailer，Trailer 保存了每个段的起始位置 (段的 Magic Number 用来做安全 check)，然后，DataBlock Index 会被读取到内存中，这样，当检索某个 key 时，不需要扫描整个 HFile，而只需从内存中找到 key 所在的 block，通过一次磁盘 io 将整个 block 读取到内存中，再找到需要的 key。DataBlock Index 采用 LRU 机制淘汰。
首先，能快速找到行所在的 region(分区)，假设表有 10 亿条记录，占空间 1TB, 分列成了 500 个 region, 1 个 region 占 2 个 G. 最多读取 2G 的记录，就能找到对应记录；
其次，是按列存储的，其实是列族，假设分为 3 个列族，每个列族就是 666M， 如果要查询的东西在其中 1 个列族上，1 个列族包含 1 个或者多个 HStoreFile，假设一个 HStoreFile 是 128M， 该列族包含 5 个 HStoreFile 在磁盘上. 剩下的在内存中。
再次，是排好序了的，你要的记录有可能在最前面，也有可能在最后面，假设在中间，我们只需遍历 2.5 个 HStoreFile 共 300M
最后，每个 HStoreFile(HFile 的封装)，是以键值对（key-value）方式存储，只要遍历一个个数据块中的 key 的位置，并判断符合条件可以了。 一般 key 是有限的长度，假设跟 value 是 1:19（忽略 HFile 上其它块），最终只需要 15M 就可获取的对应的记录，按照磁盘的访问 100M/S，只需 0.15 秒。 加上块缓存机制（LRU 原则），会取得更高的效率。
感谢各位的阅读，以上就是“LSM 的存储以及定位”的内容了，经过本文的学习后，相信大家对 LSM 的存储以及定位这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是丸趣 TV，丸趣 TV 小编将为大家推送更多相关知识点的文章，欢迎关注！
