甲骨文-数据库技术的发展演变与创新

Copyright©2014Oracleand/oritsaffiliates.Allrightsreserved.|数据库技术的发展，演变与创新李珈高级技术咨询总监甲骨文（中国）软件系统有限公司1Copyright©2014Oracleand/oritsaffiliates.Allrightsreserved.|演讲人–李珈JoyceLiConfidential2•超过十五年Oracle数据库、数据仓库及企业应用软件领域相关工作经验，丰富的电信、金融及政府和制造业行业经验，曾主持设计电信及金融行业大型关键业务系统及大型数据仓库系统，对关系型数据库系统、ERP、CRM系统及大数据应用有深刻理解,致力于企业信息化战略及IT架构设计与咨询领域，对于数据库业界软件、硬件一体化的信息化建设有较多经验。Copyright©2014Oracleand/oritsaffiliates.Allrightsreserved.|内容•数据库技术的发展历史•关系数据库与开源数据库和NoSQL/Hadoop的比较和定位•新一代数据库技术的创新与大数据•中国移动数据处理平台的关键技术探讨OracleConfidential–Internal/Restricted/HighlyRestricted3Copyright©2014Oracleand/oritsaffiliates.Allrightsreserved.|时下热点话题•关系型数据库的发展趋势：被取代？或不可替代？•部分观点–采用开源数据库代替商用数据库，如Mysql等–采用Hadoop+NoSQL代替关系型数据库–混合持久化，RDBMS+Nosql+Hadoop？OracleConfidential–Internal/Restricted/HighlyRestricted4Copyright©2014Oracleand/oritsaffiliates.Allrightsreserved.|关系型数据库的价值-优雅而简洁大量数据的持久化存储，比文件系统及层次数据库易于访问其中部分数据，易管理，安全性好解决并发访问的问题，多个用户访问及修改一份数据的问题，关系数据库通过“事务-Transaction”解决多个用户直接的交互操作，回滚机制多应用之间数据共享与集成近乎标准的关系模型，坚实的理论基础，优雅而简洁标准的访问语言-SQL成熟的商业化数据库产品，广泛的应用领域与成熟的支持体系，保障几百万客户在不同平台及版本上的产品能力OracleConfidential–Internal/Restricted/HighlyRestricted5Copyright©2014Oracleand/oritsaffiliates.Allrightsreserved.|数据库技术的发展历史•20世纪60年代，存储数据的多为文件系统及层次数据库，这个就是前数据库时代-网状及层次数据库阶段•1970年，关系数据库之父EdgarFrankCodd发表了业界第一篇关于关系数据库理论的论文首次提出了关系模型的概念，简单明了，易于扩充管理•1977年SoftwareDevelopLab成立，这就是后来的Oracle，数据库管理系统的诞生带来了计算机信息管理一场巨大的革命•1979年在VAX机器上第一个商业关系数据库-OracleV1面世，进入关系数据库时代；同年Teradata成立•1983年Oracle公司成立，第一个跨平台的32位RDBMS出现，同年IBM大机上的DB2面市Copyright©2014Oracleand/oritsaffiliates.Allrightsreserved.|数据库技术的发展历史•1986年ANSI把SQL作为关系数据库语言的美国标准，同年公布了标准SQL文本。SQL在1986年成为了正式工业标准•2000年之后，随着互联网的发展，数据库技术一直充满活力和不断创新，2009年NoSQL峰会，提出Nosql名字，特指不仅仅是SQL，大部分开源的数据库•2008年10月Oracle推出数据库一体机，之后随着IBM、EMC、SAP、MS纷纷推出自己一体化产品，2010年被称为一体化年•2013年7月，面向数据库云服务的Oracle12c推出,DBaaSCopyright©2014Oracleand/oritsaffiliates.Allrightsreserved.|关系数据库技术的持续创新大数据移动云Internet存储过程分区并行查询非结构化数据支持对象关系型资源管理集群数据保护XML数据库云多租户内存计算大数据JSON200320131993Copyright©2014Oracleand/oritsaffiliates.Allrightsreserved.|今天的数据库市场•Gartner改用数据库管理系统(DBMS)而不是关系型数据库管理系统(RDBMS)–包含NoSQL厂商•传统数据库厂商继续保持领先地位–Oracle,包括OracleDatabase,TimesTen,BerkeleyDB,OracleNoSQLDatabase,MySQL–Microsoft–IBM,包括DB2,Informix,pureDataOracleConfidential–Internal/Restricted/HighlyRestricted9Gartner:操作型数据库管理系统魔力象限-2013年10月Copyright©2014Oracleand/oritsaffiliates.Allrightsreserved.|分布式计算中著名的CAP-帽子原理•互联网IT数据库架构：EricBrewer,加州大学伯克利分校的教授,Inktomi公司的共同创办人以及首席科学家于2000年提出：–Consistency(一致性),所有节点数据一致性，更新，所有数据变动都是同步的–Availability(可用性),好的响应性能及稳定性–Partitiontolerance(分区容错性)可靠性，系统中任何节点失败不会影响系统的继续运作定理：任何分布式系统设计中只可同时满足上面两个属性，任何横向扩展的策略都要依赖于数据分区，没法三者兼顾。–忠告：架构师不要将精力浪费在如何设计能满足三者的完美分布式系统，而是应该进行取舍。Copyright©2014Oracleand/oritsaffiliates.Allrightsreserved.|分布式计算中的CAP-帽子原理Web服务无法同时满足以下3个属性：数据一致性、可用性和分区容错性Page11A(Availability)可用性-保证每个请求不管成功或者失败都有响应C(Consistency)数据一致性-所有节点在同一时间具有相同的数据P(Partitiontolerance)分区容错性-系统中任何节点失败不会影响系统的继续运作CAOracle/DB2/MS/MySQL…传统企业关键业务系统电信金融企业支付宝数据强一致性需求CPBigtable(Google)/Hbase/Redis(新浪微博)海量存储需求&面向文档的数据库采用分布式架构实现CP，必然面临性能及可用性难题APCassandra(Facebook)Voldemort(LinkIn)SampleDB(Amazon)互联网企业典型的Web2.0应用高可扩展性和可用性的分布式计算最终一致性Copyright©2014Oracleand/oritsaffiliates.Allrightsreserved.|数据库技术基本模式–ACID&BASE•关系数据库的ACID模型拥有高一致性+可用性：C+A•原子性(Atomicity).事务中的所有操作,要么全部成功,要么全部不做.•一致性(Consistency).在事务开始与结束时,数据库处于一致状态.•隔离性(Isolation).事务将假定只有它自己在操作数据库，彼此不知晓.•持久性(Durability).一旦事务完成此操作将不可逆转•BASE模型-反ACID模型，牺牲高一致性，获得可用性或可靠性A+P•基本可用(BasicallyAvailable)支持分区失败(e.g.sharding碎片划分数据库)•软状态(Softstate)状态可以有一段时间不同步，异步•最终一致(Eventuallyconsistent)，最终数据是一致的就可以了，而不是时时高一致例如移动的大部分数据必须是准确一致的，当一个资源的状态被更改后，所有访问这个资源的应用都必须马上能够看到这个变化；反之BASE模式：淘宝上的网店的库存在一段时间里面是不准的，但是这不影响淘宝的业务OracleConfidential–Internal/Restricted/HighlyRestricted12Copyright©2014Oracleand/oritsaffiliates.Allrightsreserved.|电信核心系统一致性和可靠性要求要大于扩展性-CA13电信核心业务——一致性、可靠性优先分布式架构——可扩展性优先数据适合按省或集中式部署数据水平切分，分布式部署对数据库要求高，可通过数据库处理复杂逻辑数据库任务简单，不适合承载复杂逻辑数据强一致性保障通过中间件和应用程序配合实现最终一致性数据运维简单需要通过复杂的数据运维工具，运维复杂业务大事务、长流程大事务要解耦成多个异步处理的环节强一致性保障客户敏感业务的感知最终一致性需要客户敏感业务作出一定平衡和让步服务化要求可选必须进行服务化Copyright©2014Oracleand/oritsaffiliates.Allrightsreserved.|核心业务需要数据强一致性保障（如：缴费业务）•用户缴费业务涉及多个系统中的多张表的操作，最终一致性模型在处理客户敏感业务过程中会出现数据不一致，用户状态不确定等问题•数据水平切分与读写分离不仅容易造成信息不准确或更新较慢，而且带来应用的复杂性和对应用的耦合度紧密结论：在电信核心系统里面关系型数据库不可替代14客户CRM1.缴费申请12.缴费业务完成8.销帐和帐户资金管理BOSS13.信用控制10.打印缴费票据3.帐务信息查询2.用户资料查询和鉴权5.返回帐务信息6.缴费处理请求9.返回缴费结果7.缴费处理11.记录缴费受理日志14.转入缴费开机流程（见缴费开机流程图）4.帐务信息查询Copyright©2014Oracleand/oritsaffiliates.Allrightsreserved.|互联网公司引领大数据新兴技术•MapReduce(2004,Google),Hadoop(2005,Yahoo!)–非关系型数据模型,键-值对,针对大规模分布式并行简单计算设计•Bigtable(2006,Google),HBase–非关系型数据模型,NoSQL,数据是不能解释的字符串,无类型列,二级索引,触发器,高级查询语言,…•Dynamo(2007,Amazon)–键值对,非关系型模式,最终一致性•Cassandra(2010,Facebook)–键值对,noSQL定制化应用实现扩展性和可用性Copyright©2014Oracleand/oritsaffiliates.Allrightsreserved.|即使Google在扩展MySQL时也有问题•这个应用[AdWords]后台原来是基于MySQL数据库并且手工分布，非压缩的数据集是数十个Terabytes,这…已经足够大造成分片MySQL的问题.•随着客户和数据量的增长重新分片这个收入关键的数据库代价是极其昂贵的。为了降低风险需要在许多团队之间进行大量的协调和测试，经过了两年的辛苦努力最终的重新分片终于完成。而这项复杂的工作还需要经常做。作为结论：团队不得不限制MySQL数据库中数据量的增长，把其中一些数据存放在外部Bigtables中，在事务行为与能够查询所有数据的能力之间进行妥协。摘自Google,OSDI2012Copyright©2014Oracleand/oritsaffiliates.Allrightsr