从硬件发展及特性看数据库发展 – 作者:龙渊实验室LongYuanLab-安全小百科

今天这篇文章主要从计算机硬件发展的角度，来分享数据库技术的趋势。

关系型数据库依然占据着半壁江山，随着大数据的发展，也在催生更多的数据应用和分析场景。

其他类型数据库也不断地在细分领域稳固市场。比如，Key-value存储、文档存储、图数据库、时序数据库、面向对象 DBMS、RDF 存储（知识图谱领域）、检索引擎、Wide column存储、多值（Multivalue DBMS）、XML（Native XML DBMS）、事件存储（Event Stores）等等。

下面的这个该分析模型主要从下面几个维度进行了排名：

a、利用google search、bing、yandex 统计相关数据库搜索结果条数。

b、利用googel 趋势，搜索频率。

c、利用一些IT 的QA站点 Stack Overflow 和 DBA Stack exchage 统计感兴趣用户和相关问题

d、利用一些招聘网站，提供的相关数据库职位的数量。Indeed、Simply Hired

e、社交网站上，相关关键字统计，比如Twitter

f、专业的网络上个人简历中的相关关键字统计，LinkedIn、Upwork。

大家可以参考。

12年，Googel发表了论文Spanner和F1，可以说是一个指明未来关系型数据库发展方向的里程碑的项目。具体论文的翻译或者原文可以参看下面的链接：https://www.jianshu.com/p/6ae6e7989161

2016年，Gartner，提出融合事务和分析型处理的概念，HTAP。主要目的，在于打破事务处理和数据分析之间的界限。

与此同时，有几家公司成立了

国内：Pingcap 2015年成立，产品TiDB，HTAP，2018年获得复星和晨兴 C轮 5000万美元融资。国外，Cockroach Labs，也是2015年成立，目前，网上可查信息，2017年5月，获得A+轮 2700万美元融资。当然，现在国内还有阿里、腾讯，以及国外的GigaSpaces等一些公司也发布了其HTAP数据库产品。

再从另外一个角度看一下，由于现在新型硬件（计算与存储硬件的发展）的发展。在国内，在2016年，成立的Zillizi专注于开发基于GPU硬件加速的新型数据库公司。在外国，2013年成立的OmnSci，旨在通过硬件来发挥数据库在OLAP、大数据交互式分析、机器学习场景下的数据处理性能。其中，Zillizi 在2018年获得了1000万美元的A1轮融资。

存储方面，基于闪存的SSD性价比越来越高，如果以价格/KB处理的角度来看的话。其次，与机械硬盘相比，SSD的读写性能基本上都是数量级的提升。所以，作为数据库或者存储行业从业人员，在软件层面的优化可能最高可以做到10%的性能提升，但是基于硬件、通过合理的算法和数据结构，充分发挥硬件的特性，却可以获得10倍、甚至百倍的性能提升。

接下来，我们简单了解一下TiDB吧

首先，可以看下TiDB，作为数据库领域，国内优质的开源项目，个人觉得其存储、计算及架构设计方面的一些思想，确实可以去学习。

TiDB 作为典型的 OLTP 行存数据库，同时兼具强大的 OLAP 性能，配合 TiSpark，可提供一站式 HTAP解决方案，一份存储同时处理OLTP & OLAP(OLAP、OLTP的介绍和比较 )无需传统繁琐的 ETL 过程。

可以看下TiDB的组件架构：其中，TiDB通过LB 获取任务请求，语法解析、查询计划制定和优化、执行查询计划、获取和处理数据；PD 存储集群的元信息、分配全局递增ID、TiKV调度和负载均衡。TiKV 作为分布式的提供事务的 Key-Value 存储引擎，以Region作为数据管理单位，Raft协议做复制，保持数据的一致性和容灾，底层存储依赖于RocksDB。

在HTAP场景下，通常， AP场景请求更多的是吞吐偏好性及长Query，会有批量的数据读写、大数据量聚合、关联和排序等操作，部分请求会占用大量内存。TP，主要是面向短平快的请求，会产生高频的随机读写，增删改查。那针对两种场景，TiDB如何去考虑的呢？

1、架构层面，SQL 层与存储层松耦合，可以对接不同的计算引擎。并且不同类型的场景，对于SQL层的物理资源需求也不同，可以将不同负载定向到不同的物理资源进行处理，具有很大的灵活性。

2、数据存储层面，Range-based的分片相对于Hash-based,对于Table scan、Index Scan、顺序写更加友好，可以将数据顺序的存储在某个节点的region中，避免数据太过于分散。

3、生态兼容层面，相对于螳螂数据库（Cockroach）选择兼容postgresql的而言，从db-engine-ranking上看，开源领域，Mysql依然是关系型数据库的老大。这对于以往基于Mysql所构建的应用生态进行具有很好的兼容性。

4、计算层面（数据在TiKV中全局有序），对于TP来说，大部分场景覆盖针对行数据、索引的Insert、update、delete 、select点差和范围查。对于AP来说，大部分是针对列数据的关联、聚合。

在TiDB中，计算层面主要体现在针对在SQL层如何将SQL任务转化成针对KV的操作和优化，比如，select count(*) from user where name=”T”。

基本流程如下：

1、找到库表，确定region。

2、确定startkey，endkey范围，Readline每行数据。

3、比较name=T 的行，进行过滤。

4、Count++。

5、迭代计算，返回Count。

但是，这个过程存在几个问题。

1、readline每行数据的时候，对于内存空间及磁盘IO来说，很浪费，因为，其他行信息来说，在count的时候，基本上是用不到的。

2、Filter数据，其实中间读取了很多name!=T的数据，也是内存空间及磁盘IO的浪费。

所以，在SQL层面，对以上查询计算做了一些优化。

1、Filter 算子下推到scan，只返回必要的数据。降低内存空间及磁盘IO。

2、聚合算子下推到本地，进行计算，只返回必要的计算结果，然后进行合并。

这种是sql 优化比较简单的一种场景，应该还有更多优化策略会在SQL层进行实现吧。

OK，简单概述了下TiDB的架构、计算及存储方面的一些设计思路。期望对大家有些启发吧。接下来，从组件架构层面来看的话，其实螳螂数据库，和TiDB大同小异。不同的就是，SQL层的兼容策略。螳螂数据库选择了PostGresql。具体细节的对比，我想网上很多。我这里只是粗浅地做个说明。

最后，看一下DB-Engine的排名，这个排名是19年3月的统计结果。不过，在GitHub上，TiDB的Star、Contributor 都比CockroachDB多一些哈。

然后，我们看一下基于硬件加速的新型数据库

基于GPU进行硬件加速的新型数据库公司，国内的ZILLIZ 确实没有看到太多产品资料。所以，这里选择MapD Core（OmniSci）来进行一个简单的介绍吧。

OmniSci Core: 号称The World’s Fastest Open-Source SQL Engine

1、MapD core三级缓存的内存管理，数据分了热、暖、冷三级分别对应了GPU RAM、CPU RAM和SSD。

2、向量化执行，Vectorized code allows a processor to compute multiple data items simultaneously. This is necessary to achieve optimal performance on GPUs, which can comprise thousands of execution units. 不过，MapD 这里核心是体现的GPU的多核处理能力。其实，CPU本身也提供了SIMD、MIMD 向量化执行的指令集，只不过毕竟CPU还是控制、调度复杂计算作为其本身的核心能力。所以与GPU上千core的向量化执行相比，CPU肯定在大规模数据处理层面上有先天劣势。

除此之外，MapD 的HA、LB、分布式（商业版提供）以及其对空间数据类型（点、线）、标准SQL、JIT on build LLVM的快速编译的支持都是大部分数据库产品的基本功能。这里需要特别说明一点，MapD core对于已编译查询计划的缓存管理，避免了SQL任务在语法解析、语法树构建、查询优化、执行计划编译等方面的开销，对于相对稳定的数据处理场景，具有一定的性能提升。这部分在一些成熟的商业数据库中也有一些支持，感兴趣朋友可以了解下IBM DB2和Oracle在这一块的支持。

其实，为什么会有基于GPU或者FPGA新型硬件的数据库产品被孵化出来，对于数据库产品来说，核心就是如何在存储能力和计算能力不对称的情况下，在保证安全、稳定的前提下，提升数据的处理能力。这里我引用Zillizi老大的一句话：“由于内存比固态硬盘又多了一个数量级的访问速度，那一旦给出更多数据，CPU 计算能力又跟不上了。于是，又只能到处理器那里做文章，以此陷入新一轮你上我下的死循环之中。” 所以，基于新型硬件的数据库出来了。在这里，其实通过下面图，我们可以看到CPU的尴尬，在05年左右的时候，CPU的发展其实基本进入到非常缓平的状态。

这个时候，我们看一下并行计算的GPU，这是我截了一个短图。这里有两个SM（Streaming MultiProcess），4*8 croes /SM，总共就有64个core。目前，面向服务器领域的，国产FT-2000也就64个core。但是，CPU一般需要做复杂的调度、控制和计算，其内部结构复杂，提供了非常多的控制指令和计算指令。对于，当前大规模数据集处理的大部分场景，其实我们只需要向小学生会做加减乘除就可以了。不需要向CPU一样成为通用技术大牛。总的来说，GPU还是比较适合做大量的同构数据的向量化运算的。

比如下面，卷积神经网络，一个5*5的图像矩阵，在做步幅为2、Filter 3*3的的特征选择的时候，是典型的SIMD的数据处理过程。这个时候充分利用GPU的多核并行计算的特性，进行多数据流的卷积计算时非常Nice的。

可能下面连接中这个视频，更能表达CPU和GPU之间在数据处理方面的差异，很有意思，可以看一下。

https://v.youku.com/v_show/id_XNjY3MTY4NjAw.html

另一个方面，CPU和GPU之间如何配合进行数据处理的加速呢？下面这个图，是从Nvida官网上找的，也就是说程序的串行部分在 CPU 上运行，而并行部分则在 GPU上运行。如此一来，能够最大程度地提高程序运行的效率。