数据库存储技术的发展

数据库作为信息技术的存储介质，其本身也伴随着信息技术的发展而发展。随着互联网技术的发展，数据库技术也从原来以关系型数据库为主的阶段，发展到如今的仅依靠关系数据库无法解决问题的阶段。从2008年左右以web2.0的兴起，互联网呈现爆炸式增长，传统的关系数据库开始显露出自身的不足。业界急需一些新的数据存储技术来满足业务的发展。尤其是大数据、云计算、移动互联网的兴起，促使了一些非关系型数据库（如：MongoDB、ElasticSearch、HBASE、Hadoop等）乘势兴起，这些非关系型数据库能很好的支撑业务的发展。2015年，国家提出“互联网+”战略，这是互联网首次上升到国家战略层面。随着“互联网+”战略的提出，越来越多的行业都将触“网”，需存储的数据会越来越多，场景越来越复杂。对传统的数据存储技术提出新的挑战，为了满足各类复杂的场景，Google研发了全球级的分布式数据库Spanner，但由于其未开源，外界对他的掌握并不是很深入。针对Spanner还发布了一篇论文《Spanner: Google's Globally-Distributed Database》。Spanner虽然有外部一致性、类SQL接口和常见事务支持，但和传统关系型数据库相比功能仍不够丰富。所以，Google在Spanner的基础上又开发了F1,扩展Spanner已有特性使其成为现在很火的NewSQL数据库。但无论是Spanner还是F1，Google都未开源，都仅限内部使用。在国内，PingCAP公司在研究了Google的论文后，自研并开源了新的数据库TiDB，功能媲美Spanner/F1。下图按时间顺序分别对每个阶段的具有代表的数据存储技术做一个介绍。

一、关系数据库

在关系数据库时期，对应的IT技术主要服务于大组织，大公司的信息管理系统，功能主要用于记录公司的各类数据，并能出一些简单的报表为主。系统多以内网部署为主，部署在公网上的系统主要以信息展示，信息宣传为主。数据库在这个时期主要以单库为主。但随着电商、互联网的发展，开始出现数据的激增，传统企业IT管理系统出现数据存储瓶颈，原有的数据库存储方案不能满足业务的发展，加之电商、互联网多为创新创业型企业，无法付出高昂的费用在数据存储上。基于此，对数据库进行分库、分表的技术在这一时期得以发展。尤其是针对MySQL数据库的分库分表技术。

分库分表暂时解决了数据的存储问题，随之而来的问题是分库分表时，非拆分键（partition key）的查询又无法满足业务查询的问题。比如：一个表里有订单号、运单号、下单时间及其他信息，当把运单号做为拆分键分库分表后，如果需要按照订单号直接查询就没法查询。此时，针对按订单号查询，可以把订单号和运单号做一个关联表，按订单号查询时先查询关联表，查询出运单号，再按运单号查询运单信息；或者是订单号和运单号生成时，针对分库分表规则，把订单号、运单号的单号上带上满足分库分表规则的基因（假如单号是long类型，分成64个表，long总共8字节占64位，可以把低8位取模得到分表的下标），这样按订单号查询时，也可按运单号的分库分表规则进行查询。

在上述的分库分表查询中，还有一类查询，按下单时间查询的。按下单时间查询我们不能说再按下单时间做一个下单时间和运单号的映射关系。在实际业务中，如果真有按下单时间查询类似的需求，其本质也是一个报表查询，或者说是一个OLAP类的场景，需要用到非关系型数据库技术来解决。我们传统的关系型数据库主要解决的还是OLTP类的场景。

二、非关系数据库

在08年以后，随着web2.0的到来，传统的关系数据库已经无法满足业务的发展。业内逐步发展起来的文档型存储技术得到了极大的发展。这其中比较具代表性的如：MongoDB、ElasticSearch、Hadoop等技术得到了广泛的应用。如我们上述的例子如果按下单时间查询，我们可以用ElasticSearch来存储我们的运单相关的信息，利用ElasticSearch的全文检索特性，很方便的就满足了业务的需求。再如，运单报表，运单数据分析，借助Hadoop，把数据同步到Hadoop后，利用Hadoop的高效、高可靠、低成本等特点能很好的满足业务需求。而且Hadoop对数据的类型无任何要求，无论是什么类型的数据，Hadoop都会转换为key/value键值对进行存储，key/value是其基本的数据单元。

无论是ElasticSearch还是Hadoop，亦或是其他的非关系数据库，其主要应用场景还是OLAP。由于电商、互联网的快速发展，每一个组织、企业对同一份数据需要存储多份，以满足不同业务场景的使用。而这些海量数据存储一份就得很多存储资源，更何况要存储多份，这对存储资源来说是较大的浪费，无论是强事务性的场景还是弱事务或无需事务场景，如果能用一份或两份数据存储就能满足该两类需求，那对组织、企业来说存储资源将节约一半，甚至更多。同时，该类数据库一般不支持SQL工业标准，事务处理能力弱，没join等复杂的连接操作。基于此，急需一类新的数据库存储技术，即能满足OLTP需求的场景也能支持OLAP的需求场景，此时NewSQL就应运而生。

三、NewSQL数据库

在上面讲到的无论是关系数据库还是非关系数据库，都各自有自己的缺点。为了满足既支持OLTP类需求，也支持OLAP类需求，一种新型的数据库NewSQL呼之欲出。目前比较有代表性的为：Spanner/F1,CockroachDB,TiDB。Spanner/F1仅Google内部使用；CockroachDB在国内运用得不是很多；TiDB目前在国内运用的企业较多，已知的美团、滴滴、58等都有在使用。TiDB是PingCAP 公司受 Google Spanner / F1 论文启发而设计的开源分布式数据库，他是一个不仅适合 OLTP 场景还适OLAP 场景的混合数据库。

TiDB的架构如下，下面分别对每一部分的作用进行说明。

TiDB Server：TiDB Server 负责接收 SQL 请求，处理 SQL 相关的逻辑，并通过 PD 找到存储计算所需数据的 TiKV 地址，与 TiKV 交互获取数据，最终返回结果。TiDB Server 是无状态的，其本身并不存储数据，只负责计算，可以无限水平扩展，可以通过负载均衡组件（如LVS、HAProxy 或 F5）对外提供统一的接入地址。

PD Server：Placement Driver (简称 PD) 是整个集群的管理模块，其主要工作有三个：一是存储集群的元信息（某个 Key 存储在哪个 TiKV 节点）；二是对 TiKV 集群进行调度和负载均衡（如数据的迁移、Raft group leader 的迁移等）；三是分配全局唯一且递增的事务 ID。

PD 通过 Raft 协议保证数据的安全性。Raft 的 leader server 负责处理所有操作，其余的 PD server 仅用于保证高可用。建议部署奇数个 PD 节点。

TiKV Server：TiKV Server 负责存储数据，从外部看 TiKV 是一个分布式的提供事务的 Key-Value 存储引擎。存储数据的基本单位是 Region，每个 Region 负责存储一个 Key Range（从 StartKey 到 EndKey 的左闭右开区间）的数据，每个 TiKV 节点会负责多个 Region。TiKV 使用 Raft 协议做复制，保持数据的一致性和容灾。副本以 Region 为单位进行管理，不同节点上的多个 Region 构成一个 Raft Group，互为副本。数据在多个 TiKV 之间的负载均衡由 PD 调度，这里也是以 Region 为单位进行调度。

TiSpark：TiSpark 作为 TiDB 中解决用户复杂 OLAP 需求的主要组件，将 Spark SQL 直接运行在 TiDB 存储层上，同时融合 TiKV 分布式集群的优势，并融入大数据社区生态。

至此，TiDB 可以通过一套系统，同时支持 OLTP 与 OLAP，免除用户数据同步的烦恼。TiDB更多的资料，可到https://pingcap.com/查阅。

       本文把整个数据库的发展历程做了一个简单的回顾、整理，便于理清未来数据库发展的方向，查缺补漏，对一些不熟悉的存储技术做出学习，以便用于工作中，提升工作效率。