虽然分为上下篇介绍，但两篇文章的内容之间比较独立，完全可以单独阅读。 下篇链接如下： lsm派系(不仅lsm tree)存储模型概述(下篇)
WiscKey 的提出，主要是为了优化 LSM-Tree 的写放大问题。此前已经有不少论文讨论过这个问题，如 LSM-trie 和 PebblesDB，但是大部分优化方法都不是很彻底——简单说就是，优化效果太差，或者不够通用。WiscKey 提出的是一种比较通用、效果明显且简单易懂的方法。
最近遇到两个问题,wriedtiger引擎到底支持不支持LSM tree , 2 为什么percona的mongodb Dump 了ROCKSDB 的数据库引擎.
Hash Index 是一种相对简单的索引结构。几乎每一种程序设计语言都有提供内存数据结构 hash map/table 的标准库，比如 C++ 中的 std::unordered_map、Python 中的 dictionary、Golang 中的 map。
这部分内容主要回答我们在文章开头提到的第二个问题。第二个问题展开其实是一连串的问题。例如：lsm派系难道只有lsm tree这一类存储模型吗？如果答案是否定的，那么除了lsm tree存储模型外，还有哪些lsm 模型？这些模型之间又有哪些相同点和差异点？
这张经典图片来自 Flink PMC 的 Stefan Richter 在Flink Forward 2018演讲的PPT
随着云服务基础架构以及微服务技术的日益成熟，很多大型系统能够分解为根据应用 workload 需求的多个子系统，再通过网络交互组装在一起协同工作。 Nova-LSM，一个将基于LSM-Tree的分布式KV 存储系统分解为使用RDMA进行通信的组件的工作。这些组件将存储与处理分开，使处理组件能够共享存储带宽和空间。处理组件将文件块 (SSTable) 分散到任意数量的存储组件中，并通过一定机制平衡它们之间的负载，在运行时动态构建范围以并行化压缩并提高性能。Nova-LSM 具有很好的可伸缩性，在一些场景下性
LSM-tree 在 NoSQL 系统里非常常见，基本已经成为必选方案了。今天介绍一下 LSM-tree 的主要思想，再举一个 LevelDB 的例子。
随着使用数据库的深度和理解能力的提升，有一个问题硬件的提升,与数据量的变化是否对数据库底层的架构有冲击。 我们公认的BTREE B+TREE 是否还能面对现在的硬件的变化。
LSM-tree 是大数据时代一个经典的存储结构，是 Bigtable，Habse，LevelDB，RocksDB 等大数据存储的构建基础。LSM-tree 高效的设计建立在磁盘随机访问要比顺序访问慢两个数量级的基础上。但近年来 SSD 的大规模应用对此基础提出了挑战，而 WiscKey 正是基于 SSD 存储介质对 LSM-tree 的痛点：读写放大，进行了优化。
LSM树(Log-Structured-Merge-Tree)（日志结构合并树）是一种能够提升磁盘写入速度的数据结构，它通过将大量的磁盘随机写操作，转换为批量顺序写的方式来得到写入性能的提升。但是同时也牺牲了一部分的读性能
LotusDB 是一个基于 LSM Tree 进行设计，并结合 B+ 树优势的单机 KV 存储引擎，读写性能稳定、快速。
之前零零散散写过几篇和 LSM-Tree、LevelDB 有关的文章。之后也看了一些代码和论文，笔记也做了一些，但大都比较零乱、随意，没花功夫整理。
LSM Tree（Log-structured merge-tree）广泛应用在HBase，TiDB等诸多数据库和存储引擎上，我们先来看一下它的一些应用：
十多年前，谷歌发布了大名鼎鼎的"三驾马车"的论文，分别是GFS(2003年)，MapReduce（2004年），BigTable（2006年），为开源界在大数据领域带来了无数的灵感，其中在 “BigTable” 的论文中很多很酷的方面之一就是它所使用的文件组织方式，这个方法更一般的名字叫 Log Structured-Merge Tree。在面对亿级别之上的海量数据的存储和检索的场景下，我们选择的数据库通常都是各种强力的NoSQL，比如Hbase，Cassandra，Leveldb，RocksDB等等，这其中前两者是Apache下面的顶级开源项目数据库，后两者分别是Google和Facebook开源的数据库存储引擎。而这些强大的NoSQL数据库都有一个共性，就是其底层使用的数据结构，都是仿照“BigTable”中的文件组织方式来实现的，也就是我们今天要介绍的LSM-Tree。
笔者前段时间在学习数据结构时，恰好听说了 LSM Tree，于是试着通过 LSM Tree 的设计思想，自己实现一个简单的 KV 数据库。
以 Mysql、postgresql 为代表的传统 RDBMS 都是基于 b-tree 的 page-orented 存储引擎。现代计算机的最大处理瓶颈在磁盘的读写上，数据存储无法绕开磁盘的读写，纯内存型数据库除外，但由于内存存储的不稳定性，我们一般只将内存型的存储作为缓存系统。
LSM 树广泛用于数据存储，例如 RocksDB、Apache AsterixDB、Bigtable、HBase、LevelDB、Apache Accumulo、SQLite4、Tarantool、WiredTiger、Apache Cassandra、InfluxDB和ScyllaDB等。
作为目前数据库引擎的两种主要数据结构，LSM-tree和B+-tree在业界已经有非常广泛的研究。相比B+-tree，LSM-tree牺牲一定的读性能以换取更小的写放大以及更低的存储成本，但这必须建立在已有的HDD和SSD的基础上。 探索前沿研究，聚焦技术创新，本期DB·洞见由腾讯云数据库高级工程师王宏博进行分享，主要介绍一篇2022年FAST的论文，主题为“基于硬件透明压缩的B+树优化”。本次分享的论文针对可计算存储SSD（支持硬件透明压缩）提出了三种有趣的设计方法，从而极大地减少了B+-tree的写放大
对于目前大多数Druid 的使用场景来说，Druid 本质上是一个分布式的时序数据库，而对于一个数据库的性能来说，其数据的组织方式至关重要。为了更好地阐述Druid 的架构设计思想，我们得先从数据库的文件组织方式聊起。
LSM Tree（log-structured merge-tree）是一种文件组织结构的数据结构，目前在不少数据库中都有使用到，如SQLite、LevelDB、HBase在Mongodb中也有一个LSM引擎；
LSM tree (log-structured merge-tree) 是一种对频繁写操作非常友好的数据结构，同时兼顾了查询效率。LSM tree 是许多 key-value 型或日志型数据库所依赖的核心数据结构，例如 BigTable、HBase、Cassandra、LevelDB、SQLite、Scylla、RocksDB 等。
LSM树是HBase里使用的非常有创意的一种数据结构。在有代表性的关系型数据库如MySQL、SQL Server、Oracle中，数据存储与索引的基本结构就是我们耳熟能详的B树和B+树。而在一些主流的NoSQL数据库如HBase、Cassandra、LevelDB、RocksDB中，则是使用日志结构合并树（Log-structured Merge Tree，LSM Tree）来组织数据。
我们熟知常用数据库MySQL MongoDB HBase等底层存储都用了各种树结构，如B树LSM树，不过为什么要用这些结构呢？
Sorted Strings Table(SSTable)是HBase、 Cassandra等一些NoSQL数据库使用的一种持久文件格式，用于获取存储在memtables中的内存数据，对其进行排序以实现快速访问，并将其存储在磁盘上的一组持久的、有序的、不可变的文件中。不可变意味着sstable永远不会被修改。它们稍后被合并到新的sstable中，或者在数据更新时被删除。
很多的数据库现在都在使用LSM tree作为其核心结构，因为它可以提供非常高的写入吞吐量。一些分布式数据库比如Bigtable、HBase、LevelDB、SQLite4、Tarantool、RocksDB、WiredTiger（MongoDB新一代的引擎）、Apache Cassandra、InfluxDB、ScyllaDB、OceanBase，甚至一些MQ都在使用这个结构，比如pulsar。既然LSM tree这么厉害，我们就有必要深入学习一下。一个典型的基于LSM tree的系统应该包括如下组件。没错，通过本文你将了解到一个典型的LSM系统应该有的五脏六腑。
本文是左耳耗子推荐的Medium上的一篇关于MySQL的文章Some study on database storage internals，本人觉得文章十分好，就取得了作者的许可，自行进行了翻译，原文链接见文末。
在评估和选型数据库的时候，人们往往将重点放在数据建模的灵活性，一致性保证，线性可伸缩性，容错性，低延迟，高吞吐量和易于管理等方面。但怎么才能评判出这些指标呢？很多人往往会网上一通搜索和看官方文档，再加上自己的“经验”来得出这些指标。
LSM-Tree（Log Structured Merge Tree）是数据库领域内较高效的key-value存储结构，被广泛应用于工业界数据库系统，如经典的单机kv数据库LevelDB、RocksDB，以及被诸多分布式NewSQL作为底层存储引擎。 本期将由腾讯云数据库高级工程师韩硕来为大家分享基于LSM-Tree存储的数据库性能改进，重点介绍近年来学术界对LSM-Tree的性能改进工作，并探讨这些改进措施在工业界数据库产品中的应用情况以及落地的可能性。以下是分享实录： LSM-Tree基本结构 LS
在当今信息时代，数据的存储和管理变得越来越重要。无论是云存储、数据库还是分布式文件系统，都需要高效的数据存储和检索方法。其中，LSM树（Log-Structured Merge Tree）是一种高性能的数据结构，广泛应用于各种分布式存储系统和数据库引擎中。本文将介绍LSM树的原理，并探讨其在不同使用场景中的应用。
在有代表性的关系型数据库如MySQL、SQL Server、Oracle中，数据存储与索引的基本结构就是我们耳熟能详的B树和B+树。而在一些主流的NoSQL数据库如HBase、Cassandra、LevelDB、RocksDB中，则是使用日志结构合并树（Log-structured Merge Tree，LSM Tree）来组织数据。本文先由B+树来引出对LSM树的介绍，然后说明HBase中是如何运用LSM树的。
21 世纪的第二个 10 年，虎哥已经在存储引擎一线奋战近 10 年，由于强大的兴趣驱动，这么多年来几乎不放过 arXiv 上与存储相关的每一篇 paper。尤其是看到带有 draft 的 paper 时，有一种乞丐听到“叮当”响时的愉悦。看paper这玩意就像鉴宝，多数是“赝品”，需要你有“鉴真”的本领，否则今天是张三的算法超越xx，明儿又是王二的硬件提升了yy，让你永远跟不上节奏zz，湮灭在这些没有营养的技术垃圾中，浪费大好青春。
LSM-tree是由两个或两个以上存储数据的结构组成的。最简单的LSM-tree有两个部分，如下图所示。常驻内存部分，称为C_0树（或C_0），其可以设计为任何方便键值查找的数据结构，常驻硬盘部分，称为C_1树（或C_1）。C1进一步可延申为C_2，C_3等等。
TiDB 是一款分布式 HTAP 数据库，它目前有两种存储节点，分别是 TiKV 和 TiFlash。TiKV 采用了行式存储，更适合 TP 类型的业务；而 TiFlash 采用列式存储，擅长 AP 类型的业务。TiFlash 通过 raft 协议从 TiKV 节点实时同步数据，拥有毫秒级别的延迟，以及非常优秀的数据分析性能。它支持实时同步 TiKV 的数据更新，以及支持在线 DDL。我们把 TiFlash 作为 Raft Learner 融合进 TiDB 的 raft 体系，将两种节点整合在一个数据库集群中，上层统一通过 TiDB 节点查询，使得 TiDB 成为一款真正的 HTAP 数据库。
前言：最近在了解大数据实时分析技术druid,究其原理时发现用到了类LSM树思想以实现高效的数据插入，于是展开了对LSM的了解，了解之后感觉这东西虽然也并没有很特别，但在大数据、分布式架构中的应用还是非常有价值的，下面简单做下分享！
Github地址：https://github.com/xujiajun/nutsdb
第二章讲了上层抽象：数据模型和查询语言。本章下沉一些，聚焦数据库底层如何处理查询和存储。这其中，有个逻辑链条：
不同的数据库存储系统都会设计不同的索引结构来优化查询/写入效率， 在讨论这些结构之前， 我们先从头回顾一下计算机存储的一些设计
类型：技术专栏 作者介绍 张凯（Kyle Zhang），SmartX 联合创始人 & CTO。毕业于清华大学计算机系，研究方向为分布式系统和体系结构。2013 年与徐文豪、王弘毅联合创立 SmartX，主导自主研发了 SmartX 分布式文件系统 SmartX ZBS。SmartX 拥有国内最顶尖的分布式存储和超融合架构研发团队，是国内超融合领域的技术领导者。 本文转载自知乎专栏 @SmartX 技术博客，点击底部“阅读原文”进入博客浏览更多文章。 过去半年阅读了 30 多篇论文，坚持每 1~2 周写一篇
MySQL + HBase是我们日常应用中常用的两个数据库，分别解决应用的在线事务问题和大数据场景的海量存储问题。
Apache IoTDB（物联网数据库）是一体化收集、存储、管理与分析物联网时序数据的软件系统。Apache IoTDB 采用轻量式架构，具有高性能和丰富的功能，并与Apache Hadoop、Spark和Flink等进行了深度集成，可以满足工业物联网领域的海量数据存储、高速数据读取和复杂数据分析需求。
点击上方蓝字，发现更多精彩 导语 LSM作为一种重要的数据存储结构方式，被许多大型开源存储系统应用为底层引擎的存储结构。同时由于influxDB的不断改良，一种基于LSM的改良数据结构TSM也开始被熟知并广泛应用。本文将基于官方文档和相关论文分析该两种数据结构的组成原理和应用特点。 LSM（Log-Structured Merge Tree）日志结构合并树 ° 模型发展 由于b+树具有稳定查询效率、逻辑上有序的数据存储等特点，使得b+树成为了许多RDBMS的底层引擎的数据结构。不过，b+数的有序数据存储仅
本文为《数据密集型应用系统设计》的读书笔记第一部分第三章的笔记整理，也是个人认为的这本书第一部分最重要的内容。本文将会针对目前数据库系统两个主要阵营进行展开，分别是采用日志型存储结构高速读写的LSM-Tree和面向OLTP的事务数据库BTree两种数据结构对比。
过去十年，图计算无论在学术界还是工业界热度持续升高。相伴而来的是，全世界的数据正以几何级数形式增长。在这种情况下，对于数据的存储和查询的要求越来越高。因此，图数据库也在这个背景下引起了足够的重视。根据世界知名的数据库排名网站 DB-Engines.com 的统计，图数据库至 2013 年以来，一直是“增速最快”的数据库类别。虽然相比关系型数据库，图数据库的占比还是很小。但由于具有更加 graph native 的数据形式，以及针对性的关系查询优化，图数据库已经成为了关系型数据库无法替代的数据库类型。此外，随着数据量的持续爆炸性上涨，人们对于数据之间的关系也越来越重视。人们希望通过挖掘数据之间的关系，来获取商业上的成功，以及获得更多人类社会的知识。因此我们相信，天生为存储数据关系和数据挖掘而优化的图数据库会在数据库中持续保持高速增长。
基于 LSM-Tree 的存储系统越来越常见了，如 RocksDB、LevelDB。LSM-Tree 能将离散的随机写请求都转换成批量的顺序写请求（WAL + Compaction），以此提高写性能。但也带来了一些问题：
来源：blog.csdn.net/weixin_41605937/ article/details/110933984
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
即时通信 IM
