技术开发 频道

SAP卢东明:再说数据库技术之争

        【IT168 评论】其实,Oracle数据库和SAP数据库之争重要的不是在市场上,更多的是产品架构设计上的。

  数据库软件发展至今40年有余,关系型数据库得到市场普遍认可,成为企业数据库选型中几乎不二的选择也有20多年了,从开始直到今天,O家的强项众所周知,一直努力做成一个优秀通用性的数据库,在所有行业、所有客户面前都试图表现“最权威的数据库”。在20年前OLAP需求极少,OLTP挑战巨大的前提下,以行的形式存储数据,对OLTP是自然、方便、快速的,对OLAP的支持只能说是凑合,特别是大数据量的分析会遇到各种各样的复杂而艰深的问题,很多O系的DBA们靠自己的聪明才智创造了各种各样的从手拉肩扛到土枪土炮(和数据库软件内部实现相比)的方法来改善性能瓶颈。原来我也曾经是他们中的一员,我的工作经历中在美国,在中国都见到过这样的优秀的DBA,自己写Shell脚本做备份,自己写Perl程序做性能监控,甚至自己有自己一整套DBA Script Library。现在看起来,既佩服自己当时的精力和辛劳,也庆幸自己没有在那条路上一直走下去。

  混合型数据库在初期是不错的选择,但是最近10年间,到底如何定位,如何侧重,我看到越来越多的纠结,以Exadata为例,最早一版和HP合作,宣传口号是针对Data Warehouse的:

SAP卢东明:再说数据库技术之争

  然而两年后和HP决裂,收购Sun阵营,又推出了“First Database Machine for OLTP":

SAP卢东明:再说数据库技术之争

  反正永远是First,永远是Best;一会专长OLTP,一会专长OLAP,万金油,随便用。根本不变的是行式存储的机理,永远是IOPS,根据不同场景加以微调,分区表啦,物化视图啦,蓝宝石玻璃啦……BlahBlahBlah……

  这些纠结和取舍和产品底层的设计理念有很大的关系,行式数据库面对大量数据,特别是在几列数据上的分析具有与生俱来的劣势,DBA们整天面对的全表扫描,大量索引等问题并没有很好的办法。而把数据库的所谓列式压缩选项打开又直接影响OLTP的效率、甚至可能性。用一句英文来说就是:stuck between a rock and a hard place.

SAP卢东明:再说数据库技术之争

  SAP的数据库产品理念不同,从Sybase的时代开始,除了在行式数据库上的直接竞争之外,发展了不同场景下的专用数据库产品系列,例如:

  1,OLAP领域享有盛名的Sybase IQ,开创了海量数据高效存储、高效分析的列式数据库技术,以更小的存储空间,更少的CPU资源,实现了更快的分析速度;

  2,数据流分析领域现在大家普遍关注和认可的CEP软件,不对数据进行实际存储,而关注于在数据的流动过程中实时做复杂分析及实时响应,在金融、证券、电信等行业存在多种实际而优秀的应用场景。

  3,小型数据库SQL Anywhere,以MB级的资源空间来实现各种数据在嵌入式设备、移动设备上、小型设备上的存储、使用、简单分析,在思科的很多交换设备上都嵌有SAP SQL Anywhere,非常高效灵活地解决着这些设备级的数据库需求。

  4,HANA的理念更是全新,完全放在内存中做分析,列式数据库的技术+内存计算的技术,无需索引,无需物化视图,无需调优,性能上更上一层楼。

  当今数据库应用领域面对的问题比20年前复杂得多,强调混合场景下的特性已经非常难满足中国的大型企业的数据库要求,试图说服客户你有一把瑞士军刀,横切竖砍斜着劈,里杀外突前后聚,通常是不太容易的,专用场景下需要专用数据库的理念被越来越多客户认可,因应用户的需要设计、优化专门的解决方案,是当今数据库界比较先进的解决方案。

0
相关文章