就目前掌握的一些数据库技术，包括elasticsearch， clinkhouse， Hbase。甚至包括具有非常高的吞吐量的消息中间件kafka。它门之所以有超高的性能。都和这些设计有一定关系。
LSM ——一种提供优越的吞吐量的设计理念写在前边：LSM设计，可以为我们提供极高的写入能力。
这个最认识这个设计的是在学习clinkhouse的时候，文档中有写为何clinkhouse能够提供极高的写入能力。后来再想一下es也是用的这种理念来维护数据。再到后来学习了海量数据的存储以后，知道其实hbase也是基于这种设计来组织数据的。下边是一篇日志结构合并树的介绍。
深入浅出分析LSM树（日志结构合并树） - 知乎
当然这种设计，我们必须接受的是近实时。因为这种设计，实际上要写入磁盘的数据，不会立刻进入到磁盘中。而是保留在内存中，然后到文件系统，最后才能到磁盘。另外这种设计，对数据的修改和删除是非常不友好的，需要我标记删除。而且还要在后台进行段合并，只有段合并的时候，之前被标记删除的数据，才能真的删除。
利用磁盘的顺序写fafka之所以在使用磁盘的情况下，也能有极高的吞吐量，就是因为它用到的是磁盘的随机写。Hbase也是利用廉价的磁盘来做数据存储的，它有着极高的写入能力，远高于mysql。并且在几十亿的数据量下，根据key检索一条数据仍然能在两秒以内。前者的写入能力也是因为用到了LSM设计来组织数据，并且用磁盘的顺序写。
··PS LSM 和磁盘顺序写，真的是好兄弟。他们在处理大量数据的时候，有着非常不错的能力。
FST有限状态集。是es（lucene）中用到的设计。我们可以使用这种理念，将数据进行重新组织，然后将它门放在我们的内存中。
Elasticsearch之数据压缩算法 - 简书
数据压缩关于数据压缩，不管是elasticsearch中还是在 clinkhouse，都有很多的被用到。在clinkhouse文章中特别提到，之所以能够有很大的吞吐量，在海量数据中进行检索，离不开压缩。在es的相关设计的讨论中，甚至有人提出对压缩的数据进行减速，要快于没有压缩的数据。虽然后来没有被证实，但是es也去压缩存储数据，它门的结论是，压缩数据，并不会降低性能，还能节省存储空间！
快照的设计理念快照最早的时候在redis中看到过。用来保证redis中基于内存的数据不丢失。
在elasticsearch中也有出现快照的概念。在系统设计中，我们为了保证数据不丢失（数据容灾），引入快照的概念，或许是一种不错的选择。
之前在看G1垃圾回收器的时候，也有看到过快照的影子。在进行第一次GCroot的根扫描以后，进行一次快照。
