这两个关于数据库的概念经常看到，但是一直不明所以，今天读《与开源同行：揭秘PingCAP七年创业实践》算是搞明白了一些，特记录。

数据库中，有两个词肯定绕不开：OLTP（Online Transaction Processing，联机事务处理）与OLAP（Online Analytical Processing，在线分析处理）。从字面上来看OLTP是做事务处理，OLAP是做分析处理；从对数据库的操作来看，OLTP主要是对数据的增删改，OLAP是对数据的查询。

OLTP主要用来记录某类业务事件的发生，如购买行为，当行为发生后，系统会记录是谁在何时何地做了何事，这样的一行（或多行）数据会以增删改的方式在数据库中进行更新处理操作，要求实时性高、稳定性强，并确保数据及时更新成功，像公司常见的业务系统如ERP（企业资源计划）、CRM（客户关系管理）、OA（办公自动化）等都属于OLTP范畴。

当数据积累到一定的程度，需要对过去发生的事情做一个总结分析时，就需要把过去一段时间内产生的数据拿出来进行统计分析，从中获取想要的信息，为业务决策提供支持，这时候就是在做OLAP了。

OLAP不仅是对OLTP的一个补充，事实上它在数据库技术的演进方面提出了全新的设计需求。换言之，数据库的底层设计和实现都必须做彻底的改造，才能够满足OLAP的需求，只在原有模型上做修修补补是不行的，这是数据库发展史上的重要经验教训。采用旧有的模型，根本无法满足OLAP在时间上的要求，因为数据库在完成了满足事务特性的存储后，往往要经过数小时甚至数天以后才能完成相关的计算分析工作。显然，对于大量的互联网创新业务，如大促、秒杀等活动，这是完全不可接受的，即使看上去传统的业务，也会大大地限制数据库的应用场景。从逻辑上推导来看，对OLAP的时间需求一定会逐步过渡到满足实时性要求，即数据的存储和计算分析之间没有时间差，事务完成后就要立刻计算出在新的一致性状态下的分析结果，Gartner公司为此提出了一个专有名词：HTAP（Hybrid Transactional and Analytical Processing，混合事务和分析处理）。对其最简单的理解就是HTAP = OLTP + OLAP。

20世纪80年代，也就是提出关系数据库模型后的10年，关系数据库逐步完成了工程与产品实现，像Oracle、DB2、Sybase、SQL Server等第一批数据库产品开始出现，它们都是商业数据库。到了90年代中后期，MySQL和PostgreSQL这类开源数据库开始萌芽。20世纪末到21世纪初，IT与通信技术这两种技术发生了第一次碰撞，开启了互联网时代，数据量开始爆发式增长。快速发展的各类互联网公司更加青睐MySQL和PostgreSQL这类开源数据库，同时也给这类开源数据库带来丰富的产品生态，比如基于开源数据库的各种分库分表方案的产生。同一时期，2006年，谷歌的“三驾马车”——GFS、BigTable和MapReduce开启了大数据时代，涌现出了像Hadoop和Redis等以NoSQL技术为代表的大数据生态。

2010年前后，IT与通信技术发生了第二次碰撞，4G网络开启了移动互联网时代。在这个时代产生了很多业务与场景创新，底层数据技术更是进入了前所未有的快速通道，数据技术栈的发展方向可谓百花齐放。首先，集成了分布式技术与关系模型的NewSQL数据库开始涌现，代表产品有Spanner、TiDB、CockroachDB等。其次，云计算与大数据发生了很多融合，云原生数据库出现。云计算不仅给数据技术带来了新的变革，也给数据厂商带来了更高效的服务，从而不断涌现出丰富多样的交付商业模式和各种DBaaS的产品。

以前，人们时常听到的一个词叫作“信息化”，信息化就是把以传统方式（如印刷品、磁带、纸质账本等）记录的信息，转化成电子信息形式的过程。如今，人们已经非常习惯以电子信息的形式表示几乎一切生活和工作中要打交道的事物，也就是说，信息化已经推进到了一个比较深入的阶段。在信息化的过程中，数据库的主要角色就是存储转化来的各种信息，比如企业的员工信息、财务信息和交易记录等。

现在，一个更重要的时代趋势是数字化，它远远超越了信息化。信息化仅仅改变了信息的存储方式，而并没改变人们的思想和行为模式。而数字化就不同了，企业在完成数字化转型以后，就会脱胎换骨，以完全不同的模式运营。这时，数据不再仅仅是一种记录，而渗入了企业日常运行和决策的方方面面。如果说信息化时代的数据还是“死”的，那么，数字化时代的数据则彻底地“活”了过来。一方面，数据的收集不再是狭隘的、短暂的、死板的，而是全面的、连续的、灵活的；另一方面，数据的处理不再是滞后的、机械的、人为的，而是实时的、智能的、自动的。目前，各行各业都逐步从信息化向数字化过渡。从技术创新角度看，数字化会催生越来越多的数据技术栈，但使用多种技术栈也大大增加了使用成本。从用户需求的角度看，降低技术栈的使用成本就是将在线处理业务与分析业务进行融合，也就是说，将HTAP作为一种统一的数据服务已经成为数字化时代的一个强需求。

从数据库发展的历程来看，驱动数据技术发展与创新的内因是什么呢？由于数据最终服务于上层应用，所以数据技术发展与创新的驱动力总结起来主要有三个：第一，业务发展；第二，场景创新；第三是基础设施的发展。业务发展需求主要体现在数据容量的持续爆发式增长，数据容量不仅包含数据存储量，而且包括数据的吞吐量。场景创新主要体现在对数据的交互效率与数据模型的多样性上，比如查询语言计算模型、读写延迟要求等。基础设施的发展则主要体现在云基础设施的兴起上。

从数据容量的角度来看，数据库系统总是被动地去适配业务数据量的增长。在早期业务数据量基本在几百GB（吉字节，为230字节）的时代，单节点本地磁盘是最高效的数据架构，单机版关系数据库是主流。随着数据量的增加，人们可以通过加入更多的CPU、更大的内存、更快速的硬盘等升级硬件的方式来应对，也就是大家经常说的纵向扩展，包括引入了像网络存储Shared Everything这样的代表性架构。但当数据量的增加速度远远超过了硬件的升级速度，要达到水平扩展的效率就只能采用分布式的Shared Nothing架构，所以在这个时期“分布式”逐渐成了海量技术的代名词。

其实在互联网普及之前，分布式数据库就已经出现。原因也很简单：单台计算设备的算力和可靠性都太低了，伴随着计算机网络概念的出现，利用网络和集群完成大规模的计算和存储任务的分布式数据库也就应运而生。

如果从数据模型与交互效率的演进这维度来看，除了对水平扩展的需求，数据存储结构的需求也是需要解决的问题。早期的单机数据库查询使用标准SQL支持事务，绝大部分采取了结构化的方式进行存储。而伴随着移动互联网的兴起，在很多场景下结构化的存储方式慢慢显得力不从心，诸如时序数据、地理信息等非结构化数据的需求变得强烈，于是才逐步衍生出了NoSQL数据库。随着NoSQL数据库的快速发展，又一个新的问题摆在人们面前，那就是大部分NoSQL数据库无法支持事务，而事务对于OLTP场景，即在线业务场景，尤其是在线交易而言是不可或缺的，这也是为什么关系数据库依然是当前需求的主流。于是，既要求支持事务，又兼容多种数据模型的可扩展数据库自然就被提了出来。这就是NewSQL出现的内因。