Home > Database > Mysql Tutorial > body text

传统数据库没落,OLTP新型数据库发展火热

WBOY
Release: 2016-06-07 15:59:35
Original
1247 people have browsed it

参考资料: (1) 《OLTP Through the Looking Glass, and What We Found There》 (2) 《The End of an Architectural Era》,VLDB 2007 越来越多的程序员开始做移动App的开发,真正做底层系统开发的程序员还是少数。看到国内数据库系统发展的资料不是很多,我

参考资料:

(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更加全面,更加兼容传统数据。

好多人想问,为什么市面上流行的数据库竟然如此差,设计成这个样子?难道大家都错了吗?其实这个问题很简单,传统数据库开发得很早,最早可追述到上世纪七八十年代,距今至少也有30个年头了。这种数据库系统实际架构和模式,是由当时整体计算机硬件水平和理论水平而决定的。近些年硬件发展速度相当迅猛,无论是从Disk/RAM的大小到价格,还是CPU的性能和多核(Multi-core)技术等,比起30年前,都有飞跃式的发展。尽管摩尔定律这两年半导体技术发展的增长速度已经放缓,但是还在不断进步。再者就是因为,30年前数据库的应用很单一很简单,经过这么多年的发展,我们的实际的数据处理需求也在不断多样化,传统数据库也随之不断地增加不同的功能,使之越来越庞大。

新型OLTP数据库的架构

为了去除传统数据库的性能瓶颈,MIT大学的研究者,根据当前的硬件水平,完全重新设计了数据库,而不在之前的传统数据库上进行微笑更改。

当代新型数据库也来越注重分布式scale out,而传统数据库则还在提高单台机器的处理能力scale up。对于普通用户来讲,不可能像大型企业一样资金雄厚,购买价格昂贵的大型机和数据库软件。如果要对数据进行备份,做到High Avaliability的话,就需要至少再购买并运行一个副本。

新型OLTP数据库解决方案

数据库系统的更改目的 新型OLTP数据库技术
去除logging开销 使用新型logging
去除locking,latching等开销 数据分区 + 单线程执行
去除buffer manager开销 使用内存,取代磁盘读写

根据相关学者研究的结果看,去除这些重大开销后,OLTP关系型数据库Transaction的吞吐量提高了至少20倍

Related labels:
source:php.cn
Statement of this Website
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn
Popular Tutorials
More>
Latest Downloads
More>
Web Effects
Website Source Code
Website Materials
Front End Template