也许是自己的认知在不断的提高，以前只会关注Oracle这样的Top5这样的数据库，造成了知识面狭窄，确切的说，我只是了解某个厂商的数据库管理系统，那并不一定通用，可能还比较专制。
针对今天的标题，从两方面来思考，第一点是数据库的存储引擎，第二点是存储介质SSD。
1. 数据库存储引擎
数据库的存储引擎有很多种，在DB ENGINES上有非常明确的分类，如关系型、文档型、键值型等等，无论是哪一种，最终的目的是要将数据存放到存储介质上，并且还会对数据进行频繁的增删改查的操作，我们通常称之为DML（Data Manipulation Language），在设计数据的存储机制上各数据库却各有不同，我在《GaussDB能否挑战Oracle在金融行业的霸权》一文中简单介绍了，但说的并不全面，下面再总结一次。
各存储引擎的存储机制概括起来有以下几种，以MVCC进行描述：
Tempspace Update，典型SQL Server的MVCC机制，把旧版本的数据写入专门的临时表空间，新数据写入日志，然后去更改数据
In-place Update，典型Oracle、MySQL的MVCC机制，把旧版本的数据写入到UNDO空间中，新数据写入到REDO日志，然后去更改数据
Append Only，典型PG的MVCC机制，新版数据和旧版数据都保留在表中，通过标记旧版数据不可见的方式，新数据写入到WAL日志，然后去更新数据。
LSM（log-structure storage），典型OceanBase的MVCC机制，新版数据和旧版数据保留在MEMTABLE，SSTABLE，通过标记旧版数据不可见的方式，新数据写入到WAL日志，然后去更新数据。这与Append Only很像，但又多了些合并的步骤。
如果按照阵营来区分的化，上面几种情况还能进一步归类为两种：原位复用和数据追加。
原位复用，顾名思义就是在进行修改数据时，会在源数据上直接变更，对于这种情况，会出现，如果所更新的数据比原数据小，可直接替换，并会留下少量空间不足以再插入一行，一定程度上会有少量空间浪费，如所更新的数据比原数据大，当所剩空间不够存放一行数据时，会引起行迁移的出现，这样会造成额外的IO。除了更新，插入也会利用所删除的记录空间，频繁的删除也会造成高水位问题。通常表是堆表形式，数据的插入也是随机写方式。
数据追加，新老数据都存放再一个表中，新数据的产生，旧数据的更新和删除，均采用追加的形式，新旧数据之间一般会通过链表形式进行关联，普遍这样的结构的数据库引擎中是不会有undo的，这样的结构的好处是数据插入快，按照现在底层存储介质的技术情况，LSM是会比Append only方式更快的，LSM数据写是基于日志的顺序写，而Append only则仍然是存在随机写的过程。这样在解决数据插入问题以后，带来的另一个好处就是MVCC的实现也简单了，只在一个表中实现了多版本。而负面作用是带来了空间膨胀，读放大以及写放大，这在我们传统机械盘上是一项突破，因为随机写和顺序写差了几个数量级，而空间问题及放大问题也才几倍或者几十倍，代价是更小的。
2. SSD给数据库存储引擎带来的好处
固态硬盘的到来，弥补了传统机械硬盘的IO问题，我们以前在计算一块机械硬盘的在数据库中的物理读和逻辑读时，要考虑机械硬盘的转数、机械臂的活动情况，因这些都会带来一定的数据读写延迟，当数据量小时，几个或者几十毫秒的延迟是不足挂齿的，然而实际的生产环境会遇到几万甚至几千万的数据块的读写，累计起来的I/O放大效果是惊人的。固态硬盘不存在转数、机械臂等问题，因此我们可以看到其IOPS值是机械硬盘的几十倍甚至上百倍，同时也让我们看到了其随机写和顺序写也是比传统机械盘高了不知多少倍。
之所以数据库存储引擎的存储机制会出现原位复用和数据追加，主要是历史原因，原位复用的出现是存储介质使用代价高昂，因此在设计时要充分考虑空间利用，因早期数据量小，在IO上并未出现瓶颈，随着时代发展，互联网大爆炸，海量数据喷发式增长，且机械硬盘在随机写方面差强人意，这也就造就数据追加的兴起，典型的就是LSM的诞生，在一定程度上弥补了随机写的不足，当然这是要牺牲大量空间来保障的。
那么如今，SSD存储已经普及，很多企业也都在使用。SSD底层是NAND Flash，理论来说NAND Flash的随机写和顺序写不会相差太多，而当今SSD基本上仍然是顺序写要远高于随机写，这更多的是技术上仍有很大的空间去提升，并无限去接近底层NAND Flash能力。
按照SSD这样的发展趋势，LSM这种数据的存储方式的顺序写的优势会越来越不明显，反而突出的是因其顺序写所带来的负面问题，我们知道机械硬盘也好，SSD硬盘也罢，都有使用寿命，SSD是以可擦写的总容量作为使用寿命的衡量，而LSM的写放大，会加速其衰老，无形中反而会让成本增加。
总结：
技术的发展并不是凭空想象，而是要依赖当时社会的情况，同样，我们的数据库技术要与时俱进，不能片面的去宣传一种技术有多厉害，而不考虑现在的场景。就像最近两天，TIDB将innodb的研发大佬给引入了，这也让我想到了，TIDB底层的存储引擎是基于rocksdb，rocksdb是LSM典型代表。
关系型数据库的数据类型多种多样，而LSM的存储引擎大多是key-value构造，value又是string格式，这种转换上的消耗又会增加了多少成本！
