漫谈数据库系列（一）数据库种类浅析

1.数据库技术发展的新阶段
关系数据库技术经过了将近40年的发展，成为一门成熟的、同时仍在不断演进的主流数据管理和分析技术。成熟的关系数据库产品覆盖了90%的结构化数据存储和分析处理场景。近10年以来，互联网应用的爆炸式增长，对数据库提出了新的需求：高性能读写、海量数据高效率存储、高可用和弹性按需扩展计算能力和存储容量。传统的关系数据库面临难以克服的障碍，不能胜任时代的新要求。
为数据库系统引入分布式架构，使用并行处理技术，应对不断增长的海量数据的存储和快速处理需求，是数据库技术领域发展必然的结果。并行数据库的概念由来已久，它以高性能(线性加速比)、高可用性与高扩充性（线性伸缩比）为目标，充分利用多处理器平台的能力，通过多种并行技术，在数据分析应用中提供优化的响应时间与事务吞吐量。本世纪的头10年并行数据库（典型如Greenplum）开始大规模的出现和商用。
另一方面NoSQL数据库异军突起。NoSQL数据库种类繁多，它们都是特定应用场景下的特殊实现,典型的非关系型数据库分为KV数据库、列族数据库，文档数据库以及图数据库。它们相同特征是结构（Schema）不固定，不再以二维表的关系模型作为数据存储的方式。NoSQL数据库是解决关系数据库在特定应用场景下各类难题的有益补充。
下文分别介绍数据处理典型数据处理场景以及几个典型的关系数据库和NoSQL。

2.典型数据处理场景
一般来说，我们可将数据应用类型分为OLTP(OnLine Transaction Processing ，联机事务处理)和OLAP(OnLine Analysis Processing，联机分析处理)两种。OLTP是传统关系型数据库的主要应用，其主要面向基本的、日常的事务处理，例如银行交易。OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。
1) OLTP(OnLine Transaction Processing)
OLTP是面向交易的处理系统，其基本特征是可以即时地处理输入的数据、及时地响应，因此OLTP又被称为实时系统(Real Time System)。衡量OLTP系统的性能指标，包含实时响应时间(Response Time)和每秒事务处理量(TransactionPerSecond)。随着企业业务系统的不断扩张、愈发重视实时性以及业务连续性受到重视，单个数据库在性能和可靠性上都无法满足企业关键OLTP应用的需求，数据库产品在架构上做出相应的演进，诞生了各种集群数据库（典型如：Oracle RAC和DB2 PureScale）和内存数据库（典型如：Oracle TimesTen， IBM SolidDB, 分布式内存数据库VoltDB）。
2) OLAP(OnLine Analysis Processing)
联机分析处理的概念最早由关系数据库之父E.F.Codd于1993年提出的。Codd认为联机事务处理（OLTP）已不能满足终端用户对数据库查询分析的要求，SQL对大数据库的简单查询也不能满足用户分析的需求。用户的决策分析需要对关系数据库进行大量计算才能得到结果，而查询的结果并不能满足决策者提出的需求。因此，Codd提出了多维数据库和多维分析的概念，即OLAP。OLAP委员会对联机分析处理的定义为：从原始数据中转化出来的、能够真正为用户所理解的、并真实反映企业多维特性的数据称为信息数据，使分析人员、管理人员或执行人员能够从多种角度对信息数据进行快速、一致、交互地存取，从而获得对数据的更深入了解的一类软件技术。OLAP系统按照其存储器的数据存储格式可以分为关系OLAP（RelationalOLAP，简称ROLAP）、多维OLAP（MultidimensionalOLAP，简称MOLAP）和混合型OLAP（HybridOLAP，简称HOLAP）三种类型。顾名思义，ROLAP使用了关系数据库技术，它将分析用的多维数据存储在关系数据库中并根据应用的需要有选择的定义一批事实视图作为表也存储在关系数据库中。不必要将每一个SQL查询都作为实视图保存，只定义那些应用频率比较高、计算工作量比较大的查询作为事实视图。对每个针对OLAP服务器的查询，优先利用已经计算好的事实视图来生成查询结果以提高查询效率，同时用作ROLAP存储器的RDBMS也针对OLAP作相应的优化，比如并行存储、并行查询、并行数据管理、基于成本的查询优化、位图索引、SQL的OLAP扩展(cube,rollup)等等。
3) OLTP与OLAP对比

3.关系数据库
1970年，IBM的研究员E.F.Codd博士在刊物《Communication of the ACM》上发表了一篇名为“A Relational Model of Data for Large Shared Data Banks”的论文，提出了关系模型的概念，奠定了关系模型的理论基础。后来Codd又陆续发表多篇文章，论述了范式理论和衡量关系系统的12条标准，用数学理论奠定了关系数据库的基础。
1974年，IBM的Ray Boyce和Don Chamberlin将Codd关系数据库的12条准则的数学定义以简单的关键字语法表现出来，里程碑式地提出了SQL(Structured Query Language)语言。关系模型有严格的数学基础，抽象级别比较高，而且简单清晰，便于理解和使用。关系型数据库系统以关系代数为坚实的理论基础，经过几十年的发展和实际应用，技术越来越成熟和完善。其代表产品有Oracle、IBM公司的DB2、微软公司的MS SQL Server以及Informix等等。各种不同的数据库对SQL语言的支持与标准存在着细微的不同。这是因为有的产品的开发先于标准的公布，另外各产品开发商为了达到特殊的性能或新的特性，需要对标准进行扩展。
为应对高性能、高可靠、高扩展的需求，关系数据库分别采用了MPP（Massively Parallel Processing）和SMP集群架构，更为苛刻的性能要求衍生出了内存数据库。下面分别介绍这几类典型的数据库架构。

1)数据库集群
数据库集群是一种SMP架构，如下图所示，它通常采用具有如下要素：共享存储，通过全局锁和全局缓存保持数据一致性。这个系统的最大的特点就是共享所有资源。多个CPU之间没有区别，平等地访问内存和数据存储。如果两个处理器同时请求访问一个资源（例如同一段内存地址），由硬件、软件的锁机制去解决资源争用问题。

数据库集群主要解决两个问题：
a)数据库的扩展性和性能；
b)数据库的高可用性；
数据库集群的特点是：
集群共享存储资源，在实现分布式事务和保障ACID上容易实现，适合OLTP负载；
采用共享存储资源的Share-Everything架构，每个计算节点都能够访问到数据库中的所有数据；
横向能力有限，如RAC一般4到8个节点，而pureScale可达128节点，相比Shared-nothing架构数据库的扩展能力是有差距的；
主要的厂家有Oracle RAC/ Oracle Exadata、DB2 pureScale。数据库集群分为两个流派：
a)普通Share-Everything架构，代表是Oracle RAC；

b)混合Share-Everything架构，融合了Share-Everything和第三方架构，代表是IBM pureScale。

MPP系统因为要在不同处理单元之间传送信息，所以它的效率要比SMP要差一点。因此当前使用的OTLP应用中，用户访问一个中心数据库，如果采用SMP系统结构，它的效率要比采用MPP结构要快得多。

2) MPP数据库
如下图所示，MPP数据库通常由多个SMP服务器通过一定的节点互联网络进行连接，协同工作，完成相同的任务，从用户的角度来看是一个服务器系统。其基本特征是由多个SMP服务器 (每个SMP服务器称节点)通过节点互联网络连接而成，每个节点只访问自己的本地资源(内存、存储等)，是一种完全无共享(Shared-Nothing)结构，因而扩展能力最好，理论上其扩展无限制。

MPP数据库主要解决两个问题：
a)单点数据库无法提供的高性能、高容量，这需要数据库系统具备极高的横向扩展性；
b)数据库系统应具备高可用性；
目前业界的MPP数据库的主要特点是：
实现分布式事务保障ACID成本非常高，因此该架构一般不用于OLTP事务处理场景；
每个数据库实例只访问自己的数据，不存在IO竞争，提高的整体性能；
扩展性非常好，接近线性扩展能力，甚至可达上千个节点；
数据的分布需要特殊的处理，以尽量保证系统中各个节点的负载基本平衡；
部分算法（联表、排序等）以及扩展、删除节点时会导致数据在整个系统范围内的重分布。
主要的厂家有Teradata、Greenplum、Vertica和Netezza。
MPP系统不共享资源，因此对它而言，资源比SMP要多，当需要处理的事务达到一定规模时，MPP的效率要比SMP好。由于MPP系统因为要在不同处理单元之间传送信息，在通讯时间少的时候，那MPP系统可以充分发挥资源的优势，达到高效率。也就是说：操作相互之间没有什么关系，处理单元之间需要进行的通信比较少，那采用MPP系统就要好。因此，MPP系统在OLAP决策支持和数据挖掘方面显示了优势。
新兴的MapReduce技术在广泛用于搜索相关的数据分析工作之后，随着其性能的不断提升和应用领域的扩展，迅速成为MPP数据库的年轻的竞争者，两者的竞争也促进了其相互学习和渗透。除了Greenplum等新兴公司以外，Oracle、Teradata、IBM等传统数据库厂商也致力于MapReduce 和RDBMS 的集成。

3)内存数据库
内存数据库主要解决两个问题：
a)微秒级实时OLTP；
b)具备事务处理能力和高可用的高性能数据库前端cache；
主要的厂家有Oracle Timesten、IBM SolidDB、Huawei GMDB。
内存数据库在架构上与磁盘数据库有较大差别，它的架构特点是：
支持嵌入式部署和C/S部署方式；
不具备日志、缓存管理等模块；
工作数据都存放在内存中；
数据使用T-Tree索引组织；
磁盘存储作为数据备份方式；

内存OLTP数据库可作为磁盘数据库的前端缓存部署。

4)面向实时数据分析的数据库
基于内存OLTP数据库构建实时OLAP数据库，主要解决：实时分析大量事务性数据和历史数据，支持实时决策应用。
主要的厂家有Oracle Exalytic、SAP HANA。
它的架构特点是：
强调实时性，融合内存OLTP数据库和OLAP数据库；
同时支持行存储和列存储；
工作数据放置在内存中，同时也持久化到磁盘系统；

综合上述介绍，从数据库发展的历程来看，数据库按照用户对数据处理的方式和对性能、可靠性的需求，发展为三大类别：
1)面向联机事务处理的OLTP数据库，其又细分为：基础OLTP数据库、集群OLTP数据库
2)面向数据分析和决策支持市场的OLAP数据库，根据规模细分为：基础OLAP数据库和集群OLAP数据库
3)面向实时应用的内存数据库，根据应用场景分为：OLTP内存数据库和内存实时OLAP数据库

4. NoSQL数据库
NoSQL数据库大部分是特殊数据处理场景下OLTP关系数据库的替代，它们有的通过弱化关系数据库中不必要的功能（SQL、强事务性）来提升系统的性能和扩展能力，有的采用迥异于二维表的灵活的数据模型来应对快速变化的业务模型，有的甚至采用颠覆性的数据模型来描述数据间的复杂关系。NoSQL还处于一个蓬勃发展的阶段，各种产品层出不穷，它不再是关系数据库那样的“one fit for all”的通用产品，因此使用NoSQL数据库需要严格的审视应用场景，判断何种数据库更为满足业务需要。
1) KV数据库
使用者可以通过这种数据库将键值对存储到持久化存储中，随后使用键来读取值。那么对于这种初看起来用途非常有限的解决方案来说有哪些好处呢？在根据键来保存/读取值时，系统是非常高效的，因为它没有SQL处理器、索引系统以及分析系统等诸多限制。这种解决方案提供了最高效的性能，代价最低的实现以及可伸缩性。
优点：
a)RDBMS太慢了，SQL游标的负担过于沉重。
b)采用RDBMS的解决方案来存储少量数据的代价有些大。
c)没必要使用SQL查询、索引、触发器、存储过程、临时表、表单以及视图等等。
d)由于其轻量级的设计，键值数据库可以很容易实现可伸缩性以及高性能。
缺点：
a)关系型数据库的限制可以从底层就确保数据的完整性，而键值存储就没有这些限制，数据的完整性是由应用来控制的。在这种情况下，数据的完整性可能会由于应用代码的错误而做一些妥协。
b)在RDBMS中，如果模型设计良好，那么数据库的逻辑结构就能完全反映出存储数据的结构，并且与应用的结构有所不同（数据是独立于应用的）。对于键值存储来说，要想取得这种效果是非常困难的事情。
典型代表：Amazon DynamoDB、Riak、Redis、LevelDB、Scalaris、MemcacheDB、Kyoto Cabinet
2) ColumnFamily数据库
面向列的DBMS是这样一种数据库管理系统，它将数据表存储为数据列而非行的形式。从物理上来说，表是列的集合，每一列从本质上来说都是只有一个字段的表。这些数据库通常用于分析系统、商业智能与分析型数据存储。
优点：
a)可以比较数据，因为在表的一列中，数据通常都是同种类型的。
b)可以通过便宜、性能一般的硬件实现高速的查询性能；由于压缩的原因，相对于关系型数据库来说，这种方式磁盘上的数据所占据的空间要少5到10倍。
缺点：
a)通常没有事务。
b)对于熟悉传统RDBMS的开发者来说存在不少限制。
典型代表：HBase、Cassandra、Accumulo、Amazon SimpleDB
3)文档数据库
文档存储指的是用于存储、搜索与管理面向文档的信息（半结构化数据）的程序，其中心概念就是文档。具体的面向文档数据库的实现是不同的，不过总的来说，他们都会以各种标准化格式对数据（文档）进行封装与加密，主要格式有XML、YAML、JSON、BSON、PDF等等。
优点：
a)足够灵活的查询语言。
b)易于水平扩展。
缺点：
a)在很多时候原子性是得不到保障的。
典型代表：MongoDB、Couchbase、CouchDB、RethinkDB
4)图数据库
图论的巨大用途被得到了认可，它跟不同领域的很多问题都有关联。最常用的图论算法包括各种类型的最短路径计算、测地线（Geodesic Path）、集中度测量（如PageRank、特征向量集中度、亲密度、关系度、HITS等）。图数据库的理论依据就是图论，它通过结点、边与属性来表示和存储数据及数据间的关系。根据定义，图数据库是一种提供了无需索引而彼此邻接的存储系统。这意味着每个元素都包含了直接指向邻接元素的指针，因此没必要再通过索引进行查找了。图数据库能够描述对象间的复杂关联关系，主要应用于社交关系网数据的存储和查找。如果一个数据模型在关系数据库中需要大量的表关联、或者需要迭代查询（Subquery或者CTE），可以考虑使用图数据库。
优点：
a)对于关联数据集的查找速度更快。
b)可以很自然地扩展为更大的数据集，因为他们无需使用代价高昂的连接运算符。
缺点：
a) RDBMS可以用在更为通用的场景下，图型数据库只适合类似于图的数据。
典型代表：Neo4j、FlockDB、InfoGrid、OrientDB、AllegroGraph