參考资料:
(1) 《OLTP Through the Looking Glass, and What We Found There》
(2) 《The End of an Architectural Era》。VLDB 2007
越来越多的程序猿開始做移动App的开发,真正做底层系统开发的程序猿还是少数。看到国内数据库系统发展的资料不是非常多,我也把自己对当前数据库系统发展的认识写成博文, 和大家分享,希望能够互相学习。
数据库系统的最近发展和分类
随着操作系统发展趋于稳定(不包含移动端OS),越来越的的研究集中在数据库系统的发展上,没有多少人说要又一次做一个操作系统,很多其它的人是在现有的OS上做各式各样的应用。可是过去的10年,是数据库井喷式发展的阶段,各式各样的产品迸发出来,比如文件存储数据库(如MongoDB),列存储数据库(如Vertica), 各种NewSQL数据库(如VoltDB)。之全部有如此的发展,归结于数据量不断高速膨胀,传统数据库在大数据上的处理性能不能满足需求等。
人们趋于去开发针对不同应用类型的数据库,来满足对特定数据处理的需求。在操作系统上开发数据库系统应用非常像是在开发移动App一样。出现了蓬勃似得发展。因为当下Big Data依然是很火热的话题。在未来的一段时间内。提供底层数据管理服务的数据库,仍旧会是计算机发展比較快的领域之中的一个。
很多人会把数据库系统和其它某些概念混淆在一起,事实上数据库作为一个大的系统。就对眼下市场上产品来讲,能够分好多类:
1. 关系型数据库管理系统(Relational DBMS),比如:Oracle,SQL Server, MySQL。 PostgreSQL
2. 键-值 存储,比如:Redis。Memcached, DynamoDB
3. 文件存储,比如:MongoDB,CouchDB,Couchbase
4. 大数据存储系统, 比如:Cassandra,HBase。Google‘s Bigtable
5. 基于Hadoop的数据分析系统。比如:Hive,Spark。Impala(第四类和第五类,多多少少有些交叉。)
6. 文本查询系统, 比如:Solr, Elasticsearch.
除了上面的常见类型,还有其它非常多小分支,如图形数据库,对象数据库等。这里不作为讨论的重点。 本文主要探讨第一类传统关系型数据库系统(RDBMS)。
不同类型的数据库,适用于不同的需求,他们之间有相似也有不同。
作为第一类传统关系型数据系统。与其它类型数据库最明显的差别有几点:A)支持全部SQL语句。B)支持事务(Transaction)的ACID属性。
第二类和第三类就不具备的特点A和B,第四类和第五类大多不支持A和B。即使其它类别支持A或B。也是和RDBMS所支持的A,B有非常大不同。对于A而言。其它类别数据库也仅仅是支持某些SQL的子集。而不是整个SQL标准,或者说是较老的SQL标准,比方SQL92+。
对于B而言,不是在Row级别支持全部事务的ACID属性,那些eventually consistency什么的,都是商业宣传词汇。事实上就是no consistency。
这里并非说其它类别的数据库不好。仅仅是我们进入了一个数据库多元化的时期。不同的数据库都有自己的特点和擅长的地方,不可一概而论。比方对于Consistency来言,银行的业务就须要strong consistency,确保资金出入正确,而微博这样的应用能够舍弃一些consistency来换取系统高吞吐量。用户不是很关心是否能即使(比方时间延误小于2秒)看到朋友的微博状态。
传统关系型数据库系统系统依据应用还能够大致分为两类:OLTP(Online Transaction Processing)和OLAP(Online analytical processing)。当中OLTP处理并发,多线程管理等事务,OLAP用于大量数据分析,是BI(Business Intelligence)的一部分。第一类的关系型数据库系统大都包括了OLTP和OLAP的功能,属于通用型的数据库。下文也着重讨论OLTP类型的数据库。
传统关系型数据库性能分析及瓶颈
近些年有关传统数据库性能的分析,已经有非常多非常多。
我个人比較看好惠普HP和麻省理工大学MIT联合研究出的一片文献《OLTP Through the Looking Glass, and What We Found There》。简单的讲,他们的对当代数据库进行了解刨式地分析。得出结论:传统关系通用型数据库,仅仅有10%左右的时间是处理有效数据。剩下90%的时间都浪费在其它辅助工作上:Buffer manager,Latching,Locking。logging,Btree keys等。
上图这是他们跑TPC-C benchmark得出不同数据库部分的性能图标,左側为指令的百分比。右側为CPU cycle(即CPU运行时间)的百分比。白色部分为真正实用的数据处理,剩下的都是传统数据库不可或缺的部分,可是消耗了大量的资源。由上图所看到的,缓存管理和锁,门闩和日志都是传统关系型数据库实际较大的开销。
传统数据库的性能缺陷一直没有提到大家的日程上,主要还是由于在过去数据量太小的缘故。随着近10年因特网的发展,尤其是近5年移动端应用爆炸式的涌现,数据量也在井喷式的增长。
在当代,谁能处理好大数据,谁能挖掘Big data的商业价值。谁就能赚到钱。
不少科技公司的竞争,就是数据处理能力的竞争。
这也是为什么近10年涌现出非常多NoSQL的数据库和NewSQL的数据库。NoSQL发展的早些,现有非常多知名的系统,比如Google的Big Table,Amazon的DynamoDB,Apache的HBase,Cassandra等。NewSQL系统出现的晚于NoSQL大概5,6年吧。如今流行的有VoltDB,NuoDB。Clustrix等。
他们的共同点都是解决大数据的处理性能问题,不同点是NewSQL系统,旨在解决NoSQL不支持标准SQL语言和事务Transaction不全支持ACID属性的特点。
换句话说,NewSQL的功能要比NoSQL更加全面,更加兼容传统数据。
好多人想问,为什么市面上流行的数据库居然如此差。设计成这个样子?难道大家都错了吗?事实上这个问题非常easy,传统数据库开发得非常早,最早可追述到上世纪七八十年代。距今至少也有30个年头了。这样的数据库系统实际架构和模式,是由当时总体计算机硬件水平和理论水平而决定的。
近些年硬件发展速度相当迅猛,不管是从Disk/RAM的大小到价格,还是CPU的性能和多核(Multi-core)技术等,比起30年前,都有飞跃式的发展。虽然摩尔定律这两年半导体技术发展的增长速度已经放缓,可是还在不断进步。再者就是由于。30年前数据库的应用非常单一非常easy,经过这么多年的发展,我们的实际的数据处理需求也在不断多样化。传统数据库也随之不断地添加不同的功能,使之越来越庞大。
新型OLTP数据库的架构
为了去除传统数据库的性能瓶颈。MIT大学的研究者,依据当前的硬件水平,全然又一次设计了数据库,而不在之前的传统数据库上进行微笑更改。
当代新型数据库也来越注重分布式scale out。而传统数据库则还在提高单台机器的处理能力scale up。对于普通用户来讲,不可能像大型企业一样资金雄厚。购买价格昂贵的大型机和数据库软件。
假设要对数据进行备份,做到High Avaliability的话,就须要至少再购买并执行一个副本。
新型OLTP数据库解决方式:
数据库系统的更改目的 | 新型OLTP数据库技术 |
去除logging开销 | 使用新型logging |
去除locking,latching等开销 | 数据分区 + 单线程运行 |
去除buffer manager开销 | 使用内存,代替磁盘读写 |
依据相关学者研究的结果看。去除这些重大开销后。OLTP关系型数据库Transaction的吞吐量提高了至少20倍。