关于数据存储的前世今生的故事（上）

                                                                   故事  

                                                                        2020.6.2

   前言

 话说天下大势，分久必合，合久必分。 

   背景

      蔚蓝星球上有一个数据王国： 刚开始：单机数据库包打天下，满足一切需求，例如mysql、oracle 物欲横流，人心思变，数据量越来越大，于是：分库分表、多主多备等妥协方案应运而生。  

      类似：汉高祖刘邦 广封 刘姓诸侯王，已镇天下 但随着经济的发展，数据格式越来越复杂      

      结构化数据、非结构并存 大数据、实时分析等场景的需求，出现了redis、hbase、nosql、hdfs等新存储出现 。

     丫的 数据孤岛 这是唐朝末期藩镇割据啊。

      大一统的数据库王朝不能忍，但没辙，沟通还是要的，于是kafka等数据流中间件出现了

      于是百花齐放，各领风骚 于是留下大骂坑爹的我们

       这么多库：hdoop、habse、mysql、redis、es等，都要一一学习

      学习成本重啊

       不同的工具可能面对的是某些特定、甚至「狭窄」的场景，为了应对一个复杂的业务，大家必然就要多种技术方案组合来覆盖所有的应用场景

技术层面：存储引擎的划分

     哈希存储引擎：

      REDIS、memcache

     基于哈希表结构的键值存储系统，仅支持追加写操作，即所有的写操作只追加而不修改老的数据，同一个时刻，只有一个活跃的新文件。

     主要思想是：

    1.内存中采用基于哈希表的索引结构，即hash表存放的是数据在磁盘上的位置索引，磁盘上存放的是主键和value的实际内容。

     2.定期合并，定期将旧的数据或者删除操作进行合并，保留最新的数据。

     3.掉电恢复，在磁盘上保留一份索引记录，在定期合并的时候产生这份索引记录，当磁盘掉电的时候直接通过这个索引记录到内存中重建即可。

    存在的问题：索引的长度远小于数据的长度，这样内存存放的索引越多，磁盘存放的数据就越多。

 

B树存储引擎：

   mysql、oracle

   关系型数据库常用的存储引擎，通过B树的结构进行数据的持久化

   主要思想：

    1.利用B树的数据结构，非叶子节点都是索引，叶子节点存放的数据，

    2.根节点常驻内存，通过二分法去查找非叶子节点，没有命中去磁盘上取根节点，直到最后早点叶子节点的值，最后从磁盘中取出。

    3.添加缓冲区管理，替换策略，加快叶子节点的缓存。

LSM树存储引擎：HBASE

  主要思想：放弃部分读能力，换取写入的最大化能力

    1.对数据的修改增量保持在内存中，达到指定大小限制后批量写入到磁盘中

    2.读取数据时，需要合并磁盘的历史数据和内存中最近修改的数据

    3.增加的数据写到磁盘上时，按照新老写入不同的sst文件，并给这些问题设置不同的层次，层次代表了数据的新老，通过这样的层次完成数据的持久化。

 

共识：数据是架构的中心

我们其实做的一切工作，都是围绕着数据。数据的产生，数据的存储，数据的消费，数据的流动……只不过是根据不同的需求，变化数据的形态和服务方式。 程序 = 算法 + 数据结构 系统 = 业务逻辑 +数据

 

魔鬼隐藏在细节里：经济基础决定上层建筑

•      基础理论： 数据库 acid:Atomicity\Consistency\Isolation\Durability
•       例如：为了实现上述理念：
•        所做的工作：隔离级别、MVCC、表锁、行锁、事务 分布式：cap，黄金三角，此消彼长，不能同时完美。
•              分区容忍性
•                脑裂
•        极端的例子：建立在区块链基础上的比特币

区块链

•    非高可用
•    冗余
•         nysql 主从
•         引发一致性 单点写入
• 多点写入
•     比如2个 写写冲突的一致性问题
•            1、时间戳 2、最早写入的为准 投票

区块链就是高可用、分布式存储系统

•    高可用，
•      每个节点保存了全部数据
•          导致能存储的数据容量少，也就100多G
•           mysql 几百G很正常
• 多点写入协调一致性
•      写入速度非常慢 其他公司自研的 轻轻松松上10万
•       为嘛啊，因为上百万的节点的一致性，能不复杂吗

 

现实就是现实：

     于是社会惯例：默认会让在线业务与离线业务是分开的， 在线业务用 MySQL、MongoDB 等等，离线业务（或者分析系统）用 Hadoop 做数据分析，好像大家都是理所当然的认为：在线和离线就该这样，泾渭分明

 

于是开始反思、开始怀念大一统的数据库，于是：Real-Time HTAP  出现了。

 

TIDB

1.         共识算法（Consensus algorithm）和一致性（Consistency）算法
2.         写磁盘的 IO 开销 （WAL，持久化），多副本高可用和保证分布式事务必然会牺牲延迟
3.         衡量一个分布式系统更有意义的指标是吞吐，提高并发度，如果系统的吞吐能够随着集群机器数量线性提升，而且延迟是稳定的才有意义，而且这样才能有无限的提升空间

END

借鉴1：https://blog.csdn.net/u012414189/article/details/83962251    

借鉴2：https://pingcap.com/blog-cn/talk-about-the-future-of-databese-on-5th-anniversary-of-pingcap/