现代软件的发展历史，核心主体是互联网的发展，互联网的发展历史是 数据库的发展历史，数据库是伴随着互联网的发展逐渐成长建立起来的技术基础组件。数据库、中间件、前端软件构成软件行为 发展的三大马车，当用户从前端软件向服务器提交应用请求时，逻辑负责将这些请求分类为应用请求转向给中间件进行业务处理，中间件最后向数据库发出数据交换申请。随着数据激增，技术架构主流一直在变化，前端基础软件从apache发展到nginx，服务器能够智能效率支持更大的并发连接，而中间件代表tomcat、jetty除了版本迭代，技术概念一直鲜有推陈出新，在产品层次上没有有太大突破。在一个业务系统中，数据库强弱决定整个系统性能处理能力瓶颈。数据库的特征是数据处理能力，如何快速存储数据，存储后的数据如何快速访问 ？随着业用应务的需求，解决系统之间的安全、事务的性能、传输的可靠性、语义的解析、数据和应用的整合这些问题，新时代的数据库面临融合这些特性并形成拥有独立特性的产品。
从几个角度去理解，数据库历史的发展可以概括为数据模型的发展、数据智能解析的发展、数据处理能力的发展，在发展的过程，为了性能和功能，必须剔除数据库本身应该具备的特性，有些还是大幅度的剔除，数据库一词已经不满足它的称呼 ，更合适的词语是数据产品。
数据模型的发展分为以下阶段：第一代层次型数据库、第二代网状型数据库、第三代关系型数据库、第四代NOSQL数据库、第五代NEWSQL。数据模型的发展的背后意味人体工程思维习惯和软件工程技术的进步，第一代层次数据库代表是1969年IBM研制的层次型数据库管理系统。 层次型类似一个金字塔组织，同层次间的数据访问没有问题，不同层次的数据必须要通过高层次打通访问，最坏的情况要通过最高层回溯，技术上叫做根型指针回溯，产生业务太多不必要的访问。第二代网状型克服了层次型数据库的困难问题，它实现了实体数据到实体数据的直接映射，比起层次型更能够更为直接地描述现实业务世界。但是它也有缺点，就是结构比较复杂，而且应用环境越大，数据库的结构就变得越复杂，不利于最终用户使用。
第三代关系型数据库代表oracle、mysql等以关系代数做理论基础，以范式作为数据库设计准则，保障数据库的数据最大程度不冗余、不重复。在数据存储结构算法上，大多偏向硬盘结构的B+树算法，因为会节省内存。oracle与mysql 都是以SQL解析处理引擎为支撑，但是后面产品发展方向定位不同。oracle是一个多进程重量级的商业软件，在市场根植运营多年，它对sql有自己的领悟，不受ansi sql行业标准约束，创造出自己的oracle sql，此外在技术体系结构存储引擎一直严格遵守ACID特性。而mysql观察到并非所有的业务需求都需要用上ACID，mysql的技术架构分为两块， 一块是SQL解析器，一块是存储引擎，mysql在架构上属 于插件式管理，方便融合各种存储引擎。除了具备事务的innodb存储引擎，还包括myisam引擎、memory引擎、archive引擎、rocket引擎等等。
ACID是什么？数据库的本质无非是提供管理的方式解决数据读写的问题，ACID提供数据库对事务进行正确读写的能力 。一个事务包含多个读写操作，假设一下，成千上万的用户同一时间内访问同一行数据，所有的用户行为对同一行数据发起的操作可以归类为先读后读、先读后写、先写后写 、先写后读 ，而且可能网络超时或者服务器宕掉，带来的挑战是脏读、不可重复读、幻读，脏写、丢失更新等风险。一个脏读例子，A先把数据从旧值5写成新值10，B在T1时刻读取了10，但是T1时刻A回滚， B读取的一个不存在现实空间的数据，在支付、转帐等银行业务场景，数据读写的准确性非常重要，否则会导致严重的灾难，在非金融领域在库存、购买、交易等领域也需要ACID，否则会发生商品超额购买，下单无法交易的状况。
ACID是关系型数据库的亮点技术，并非所有的业务场景都需要ACID，例如CMS或者微博之类，该系统的特色是每时每刻都需要插入大量的数据，系统处理能力和响应速度十分重要，比安全还重要。关系型数据库的劣势表现出来 ，在数据量不断增大后，B+树在插入数据时的数据页会在大量分裂，其次单机硬件性能也不方便扩展，于是分布式技术革命涌起。oracle与mysql最早的分布式技术是oracle rac和mysql ndb cluster，但是这两种架构技术共同点每一个主机都是数据库实例，通过数据库实例横向扩展数据库的处理性能。即使这样，大规模数据读入写出，数据库仍然有很大的压力，还需要更深度的调优。
后面便是大名鼎鼎的nosql运动，nosql的全称是not only sql， nosql 运动主要成就剔掉了引以为傲的SQL处理引擎，改用自己独特的dsl处理机制，并且实现了关系型诟病的单点问题。 传统sql处理在数据访问路径有非常大的消耗，一个简单的查询语句，要经过SQL解析、检查权限、逻辑计划、SQL优化，物理计划等阶段。mysql实现nosql，就是饶过SQL处理引擎，通过一个handlesocket后台进程插件直接访问innodb存储引擎，数据处理能力比起以前有强大提升。 nosql旗下产品按门分类有键值数据库(memcache、redis)、列式数据库(hbase、cassandra)、文档型数据库(mongodb、couchDB)、图数据库(neo4j)等产品。其中键值数据库不能作为一个数据库独立使用，它的主要作用把热数据加载在内存中作为缓存，为数据库减轻访问压力。而hbase 与cassandra虽然称为列式数据库，其实不是列式，真正的列式数据紧密排集，并且经过高度压缩。而hbase与cassandra默认是无压缩的，因为他们就是为OLTP服务的，压缩对插入和修改的性能不好。键值模型和文档模型区别于传统的关系模型，开发者需要适应新的数据库设计方式，针对业务建模建表，必须尽可能把所有的业务关联数据都建在一个表。键值模型和文档模型不支持表关联，在NOSQL思想，表关联是关系模型的延伸，为了提高计算性能，NOSQL提倡宽表的理念，通过冗余数据去规范式提升数据库处理性能。关联表查询技术本质上属于关系代数的二元运算，二元运算需要把两个逻辑数据空间整合，运算、各种校验处理，计算机技术要强大的计算。nosql还有一个技术新特性是数据复制及一致性，这也是CAP的核心重点，它将会影响是CP或AP。
CAP是NOSQL包括分布式系统的理论基石，特别是具有数据分片和数据副本的分布式系统设计准则。过去是单点单兵作战，现在是一个集群一个团队在作战。前面往集群里面发一个写请求，后面往集群里面发一个读请求。如果读请求马上能读到最新的信息，那么是强一致性，如果读请求现在读的是滞后的信息，过一段时间才能读到最新信息这是弱一致性。数据复制及一致性就是团队内部如何协调写请求的事， 假如集群有3个数据副本，我们可以选择3个副本全部同步完成然后响应外界读请求，或者2个副本大多同步完成响应外界读请求，甚至1个副本或异步的方式响应用，目前只有kafka擅长支持异步，因为kafka的写速度非常快。是CP还是AP？关键是你选择数据副本复制的方式。hbase属于CP是强一致性，因为它底层用的HDFS，HDFS默认是三个副本完成数据同步再响应外面请求。 cassandra属于AP是弱一致性，严格来说cassandra是单调一致性，它有一个公式由读复制数(R)、写复制数(W)、复制因子(N),当 R+W>N是强一致性，当R+W<N是弱一致性。mongoDB属于CP是强一致性，它默认的采用RAFT大多数协议，即三个副本有两个副本写成后返回。这样客户端有可能会读到尚未更新的数据副本，MongoDB在这里提供辅助强一致性的手段，提供客户端函数让读请求只读主副本，并且在服务端设置某个最新数据副本读请求访问后，往后的读请求看到的也是同样的数据。
图模型是很特别的存在，如果要聊图模型，就必须要提elaticSearch，看似elaticSearch的分类偏文档型数据库多一点，实际上图数据库和elaticSearch更偏向智能计算，为知识图谱和用户画像服务，区别于过去的单纯的数据管理和数据计算。当数据库接受一个请求，自动识别请求请求语义，像人理解话里筒中含义。最初，全文搜索引擎的需求是数据库全表扫描的问题 ，类似like的语句，总是进行全盘扫描，而且结果也不理想。 搜索引擎通过对查询结果打分，识别语句的上下文环境，返回用户需要较精确的数据结果。图模型主要描述量事物和事物之间的关系，图模型眼中的世界由实体(节点)、属性、关系(边)三 个模型构成。例如电子交易由节点（个人，商品）和边（购买，收藏）构成的图，每条边可以被赋以权，组成加权图。权可取一定数值，用以表示距离、流量、费用等。加权图可用于研究电子网络、运输网络、通信网络等各种路径优化场景。
nosql把数据库的发展推上一个新的顶锋，增加了功能、提升了性能、扩充了各种AI特性。业务发展，技术创新，永无止境，newsql的时代来临。newsql的定义有很多诠释，更为大众接受的是HTAP， 即是一款既 支持OLTP和OLAP的产品，它同时要解决的是事务的问题和分析的问题。此时SQL回归，毕竟SQL扎根信息行业30多年，培养了忠诚 的老用户和思维使用习惯，为了保证保留SQL的同时提高系统的处理性能，各大厂商饺尽脑汁。 国外厂商诸如memsql、hana、voltDB为了提高系统并发处理性能，他们共同的做法是所有数据的数据全部加载在内存中，通过内存把数据库性能提升到极致。
内存数据库的特点是牺牲内存空间换取执行时间的方式，由头到尾它尽量避免从硬盘加载数据，如果发现它需要从硬盘加载数据，那表示性能降低了，内存空间需要升级了。 算上数据副本在内存数据库中会膨胀，300G的数据最佳使用是100G的数据库空间。内存数据库的最佳使用公式： 业务空间* 数据副本。
这样一算，需要的内存实在是太多，不是一般的公司能够承担这样的费用，所以内存数据库只适用于OLTP领域。硬件成本放在一边，如何快速提高OLTP下的事务处理能力，memsql和voltdb都用了传统MVCC。而memsql对原先的SQL引擎在进行了编译优化处理，并发的情况下可以提高处理性能。voltdb对每个分区的管理使用单线程的方式，因此根本上不需要解决多线程并发发生的排他处理的事务锁和内存锁机制，对事务以存储过程形式先预提交到系统里面。
从SQL到NOSQL，从NOSQL到NEWSQL，最经典的业务案例我们可以看谷歌的故事。为解决海量数据读写的问题，传统SQL数据库无法满谷歌 的需求，于是谷歌Google研发了Bigtable，随后发布了分布式文件系统、分布式数据库、分布式协调系统三篇论文，这也是后面NOSQL运动的一个源头。随着业务发展，谷歌发现很多场合依然离不开事务，bigtable的只有一个region提供读写服务,当该节点宕掉，需要一段时间从硬盘加载数据，加载时间集群处于不稳定状态，并且bigtable不支持sql。于是谷歌又研发了megastore， megastore主要特点解决了bigtable的SQL功能以及单点实例的功能，为bigtable提供友好的传统数据库操作方式并提高使用感受。bigTable每个 region实例作为megastore的数据副本，megastore至少提供三个副本，其中一个是主副本，主副本提供写服务，写成功后，同步数据到另外两个副本，倘若主副本的主机意外宕掉，根据 paxios协选出其中一个副本作为leader，继续提供服务。甚至megastore还提供多种读取方式。
由于megastore的立足bigtable的引擎不够好，谷歌改头换面开发了一套新架构spanner/F1,spanner比起megastore有更好的分布式存储引擎以及分布式事务调度机制。F1往spanner添加ACID事务、SQL标准接口、任务资源管理等丰富的数据库功能。CockroachDB是spanner的克隆版，它的理念是实现实现一个可扩展，多版本，全球分布式并支持同步复制的数据库，与spannner 不同的是。实现银行级别的事务隔离，spanner最高隔离用的是MVCC+2PL的方式，而cockroach用的是MVCC+SSI的方式。
什么是MVCC+2PL，什么是MVCC+SSI，数据库行业把事务级别划分为读未提交、读已提交、可重复读、串行化。串行化处理是数据库事务最高隔离级别，也是金融交易对于数据库的标准要求，但是串行化也意味着性能大幅下降，所以轻易不会启用串行化。MVCC通过快照隔离的方式可以解决先读后写和先写后读的问题，但是不能保证事务是并行化的，不能解决先写后写冲突的问题。两阶段加锁即2PL通过对事务加锁，可以让事务依次运行，但是代价会相对沉重，SSI工作流程与SI相同，但是记录事务工作的状态动态检测是否曾经发生写偏序，以便回滚。相对而言，SSI的方法比2PL更轻量级。
经过十余年的发展，国产数据库从学习到自我创造，数据库在自身实力、产品、技术方面有了质的提升，在中美对抗贸易战日益激烈的今天，国产数据库软件在信息安全，提供本土化服务方面有得天独厚的优势。阿里有oceanbase，腾讯有qbase，其它数据库企业有 pingcap、南大通用、人大金仓库、巨杉等等。
目前排名第一第二pingcap与oceanBase已经在企业业务运用起来。pingcap、oceanBase与cockRoachDB一样，最底层数据存储用的都是sstable，sstable的格式是一个排序的、不可变的、持久的key value存储。pingcap数据存储用的sstable基础的rocksDB，dbms是从rocketDb做起，而oceanBase的dbms直接sstable做起。两者的架构风格也不一样，pingcap的架构有tidb( 计算节点）、tikv（存储节点)、pd(协调节点)，oceanBase则是rootServer(协调节点)、mergeServer(计算节点)、chunkServer(存储节点)、updateServer(数据写入节点)，两者最大不同之外在于oceanBase的集群只有updateServer支持写入，由于只有一个updateServer，在事务方面oceanBase 不必使用2pc，很轻松的实现跨行跨表业务。oceanBase借鉴了memsql的思想，updateServer一个相当于内存数据库，承载所有集群的增量数据。这样整个集群的读写都必须经过updateServer，updateServer的性能显得十分重要。oceanBase的设计考虑了非常高并发的状况。pingcap的架构设计揉合hbase和mongodb的影子，pingcap计算存储分开，正如hbase的regionServer、datanode分开，regionServer是从datanode加载数据，协调节点分开。TiDB Server 在收到 Client 请求时，解析 SQL 语句，找出 Key 的范围，会向 PD 请求获取 Key 所在 Region 的节点，正如mogos 在收到 Client 请求时，解析SQL语句，向config 请求获求segment的节点。Tidb与mongoDB一样都采用raft协议。 可用性方面，pingcap比起oceanBase更加平民，OceaBase的虽然功能和性能很强大，但是维护性和使用体验必须一批专业的工程师去维护。
值得一提的是pingcap的创新，pingcap的口号是100%解决事务问题 ，解决20%的分析问题，以上问题 通过一个数据源解决。 在进行OLTP的时候，自动有一块数据副本落地做OLAP。传统的技术方式是通过数据库接口全盘复制或者识别二进制日志的更新，后台源源不断的进行ETL操作，相对ETL，数据复制更加敏捷轻量级,pingcap最多做到OLAP的20%，其余的80%是什么？OLAP的业务是一个多源异构的大环境，必须混杂多种技术。memsql 为什么不引进spark ，不是生态集成的原因，而且本身就不擅长，必须要spark来填补这方面的空白。OLAP领域的技术发展又是一个长篇故事，有粗粒度索引、时间序列索引、列式压缩、代码生成、分布式并行计算、物理视图冗余等等。数据库发展像单细胞进化，最初是为解决简单数据读写的问题，后面的物种是五花八门、琳琅满目。OLTP和OLAP两套机制，一个讲究安全，一个追求速度，发展到了一个程度，OLTP也需要速度，OLAP也需要数据治理保障数据质量。武林江湖的说法，两套武功，一正一邪，背道而驰，最后却殊途同归。
网友评论