Amazon全栈工程师:从淘汰Oracle数据库的事说起

简介:

公司搞淘汰Oracle数据库的事情已经搞了好久了,这个事情其实和国内淘宝系搞的去IOE(IBM、Oracle和EMC)是类似的,基本上也是迫不得已,Oracle的维护成本太高,而公司内部基于Oracle数据库的数据仓库,也是问题频出;另一个原因则是scalability。我相信这两个原因许多人都非常清楚。

 

而这个淘汰,也不是简简单单换一个关系数据库,比如把Oracle换成MySQL,或者换到云上(RDS)。而是有明确阶段性地演进,比如替换到DynamoDB这样的NoSQL数据库上面去;或者更彻底地,像我们接触到的某个产品,数据本身换到更廉价的存储S3上去,元数据才存在DynamoDB里,而原本SQL执行的运算的部分用Hadoop或者Spark来完成,这件数据源统一和演进的事情由一个做infrastructure的团队来完成。

 

Oracle数据库要淘汰,而且还看到了NoSQL数据库作为其中的一个替代方案,那是不是说SQL要慢慢淡出历史舞台了?

 

不!

 

因此不仅回答是“不”,还要补充一句——“恰恰相反”,和关系数据库本身不同,SQL不但不会淡出,还要扮演更重要的角色。SQL和编程语言一样,代表的其实是认识世界和描述世界的一种思维方式。比如下面这样的两个例子。

 

第一个,我们组日常都会接触的产品,计算成本和利润的逻辑,使用Scala写的,跑在Spark上面,而随着业务逻辑愈来愈复杂,许多Data Analyst介入来处理各种各样的问题,他们相较于工程师来说,代码的能力显然不是长处。但是他们对SQL很熟悉,对数据很敏感,把数据抽象成一系列二维表简直是手到擒来。所以我们开始尝试把那些核心运算逻辑重写成Spark SQL。

 

第二个,前面提到的那个infrastructure团队,对客户要提供一层JDBC的封装,让内部的技术能力,也通过SQL的形式暴露出来。因为有了类似Hive这样的工具,在这种情况下应用层的部分可以尽可能地保持稳定,原本的Oracle下的sql有改动和转换,但依然是SQL,只不过执行的不再是数据库引擎,而是MapReduce任务了。我觉得这件事情很有意思,也很有挑战性。困难很多,比如索引的问题,运算透明性(包括调试)的问题(SQL有执行计划之类的工具可以让我们对其执行机制了解清楚,但是换成MapReduce job以后显然问题就困难得多了)等等。但是带来的收益是显而易见的,比如说,整个运算资源是弹性的——重要的急迫的任务优先级高,分配资源多,参与运算的instance多,从而缩短得出结果的时间。

 

去Oracle是否意味着关系型数据库不成功?

 

当然不是——

 

关系型数据库不但在过去的几十年内很成功,而且成功到被乱用滥用了。冯大辉以前说过一个被滥用的例子,阿里旺旺在用户量那么高的情况下,居然还用Oracle数据库在做存储。而我身边也有这样的例子,在我换组前,我原来的组,就把持着整个Amazon内部最大的Oracle数据库,一大堆分区,动不动成天几千万行的数据读写。其实不但是数据库这一层跟不上节奏了,还有工作流引擎也是,老的工作流引擎要淘汰,老团队不维护了,但是因为当时我们组在这个老东西上面的job太多,没法切换,成为钉子户,被迫揽下了维护这个老工作流引擎的任务,直到它退休,成为全公司唯一使用它,并且是这一方面淘汰老技术最慢的……

 

其实整体看来,Amazon这样的互联网公司淘汰老旧的技术的速度已经算很快了(尤其是和传统软件公司比起来),有时候会遇到引进新技术和造轮子过度的问题(比如好多组都有自己搞的一套听起来高大上的数据存储系统,还有就是工作流系统,也是遍地开花),但是总的思路还是挺激进的:随时准备拆了轮子重造。问题小就解决,问题大就重写。且不说这做法利弊各占多少,每次搞宣传招人的时候,造新轮子和大轮子这一点,确实是吸引人啊。

 

再一个例子,记得刚工作那会儿,去北京联通开局,负载分担是F5,服务器挂在单板上,存储用的是磁盘阵列,数据库双机用的是IBM小型机(和美国车一样,“保修期”内屁事儿没有,“保修期”一过就开始噼里啪啦乱出问题,然后赚修车费)。在当时这几个玩意儿听听就是不差钱的主儿才能购置装配的东西,看看互联网公司谁敢这么搞?无论是云存储还是云计算,用的都是成本很低的硬件,有的功能直接替代由软件完成,但是这恰恰解释了和关系型数据库的发展到辉煌,再到演退相同的现象,这些硬件也是在一定时期内代表了特定的技术流行,如今也慢慢被单设备成本低,但是规模更大的集群代替。

 

好,从这个问题继续展开,再谈谈“人”和“技能”。

 

罗胖(罗振宇)的罗辑思维里面,讲到了社会化分工带来的社会进步,也讲到了手工艺人。简单劳动,甚至不简单,但是容易被模拟的劳动,还是不可逆转地慢慢地被机器和软件所替代。于是一大帮程序员都在喊技术至上,要做技术,这也是手工艺人谋生的基础。但是同样是技术,可不尽相同,有的也有逐渐被淘汰的趋势,比如说:

 

Java总是在风口浪尖说要被淘汰,而我们也看到随着各路编程语言大张旗鼓地发展繁荣,饱受诟病的Java占有率确实下降了。但是JVM呢,却欣欣向荣,其原因在于,JVM是个平台,而Java只是一门编程语言。编程语言的可替代性在于,随着机器性能的提升,开发一门更现代更符合问题解决思维的语言的成本,要比做成一个更现代化的稳定的虚拟机平台,要低得多。这也是为什么流行的JVM上的语言有那么多,作者往往是个人;但是熟知的JVM就只来自那么几家公司。再有一个,则是编程语言本身的缺陷,更难以被“绕过”。

 

再比如说,一些曾经热炒的职位,比如DBA,对于很多人来说,这样的职业已经很难再风光下去。单纯靠维护赚钱,这本来就是一件无法长久的生计。因为“维护”这一件事情,要么因为简单而能被机器和软件替代掉,要么因为复杂而被革命掉。工具,永远只是媒介,是可以被绕过的,不是最根本和最核心的问题。数据库和很多其他的技术一样,从软件和工程的最本源独立出来,壮大到现在,慢慢再回归本源。再比如,以往小公司都要招折腾硬件的工程师,刚工作的时候和很多同事一样,都折腾过单板和机架,但是现在呢,可以把存储资源和计算资源挂到云上。因此这样的人才需求会慢慢减少,而门槛却不见得降低,最终就只剩下少数几家能够提供云服务的大户。

 

因此,以后再遇到那些卖弄自己技术的人,那些虚张声势的人,我们其实可以思考一下,生成自己的判断,他所显摆的技术,到底是解决核心问题的技术,不容易被革命和替代的,还是只是另一种鲁迅笔下迂腐而无聊的“‘茴’字的三种写法”呢?


本文来自云栖社区合作伙伴"DBAplus",原文发布时间:2016-07-05

目录
相关文章
|
8天前
|
存储 Oracle 关系型数据库
数据库数据恢复—ORACLE常见故障的数据恢复方案
Oracle数据库常见故障表现: 1、ORACLE数据库无法启动或无法正常工作。 2、ORACLE ASM存储破坏。 3、ORACLE数据文件丢失。 4、ORACLE数据文件部分损坏。 5、ORACLE DUMP文件损坏。
41 11
|
21天前
|
Oracle 关系型数据库 数据库
Oracle数据恢复—Oracle数据库文件有坏快损坏的数据恢复案例
一台Oracle数据库打开报错,报错信息: “system01.dbf需要更多的恢复来保持一致性,数据库无法打开”。管理员联系我们数据恢复中心寻求帮助,并提供了Oracle_Home目录的所有文件。用户方要求恢复zxfg用户下的数据。 由于数据库没有备份,无法通过备份去恢复数据库。
|
27天前
|
存储 Oracle 关系型数据库
oracle数据恢复—Oracle数据库文件大小变为0kb的数据恢复案例
存储掉盘超过上限,lun无法识别。管理员重组存储的位图信息并导出lun,发现linux操作系统上部署的oracle数据库中有上百个数据文件的大小变为0kb。数据库的大小缩水了80%以上。 取出&并分析oracle数据库的控制文件。重组存储位图信息,重新导出控制文件中记录的数据文件,发现这些文件的大小依然为0kb。
|
13天前
|
存储 Oracle 关系型数据库
服务器数据恢复—华为S5300存储Oracle数据库恢复案例
服务器存储数据恢复环境: 华为S5300存储中有12块FC硬盘,其中11块硬盘作为数据盘组建了一组RAID5阵列,剩下的1块硬盘作为热备盘使用。基于RAID的LUN分配给linux操作系统使用,存放的数据主要是Oracle数据库。 服务器存储故障: RAID5阵列中1块硬盘出现故障离线,热备盘自动激活开始同步数据,在同步数据的过程中又一块硬盘离线,RAID5阵列瘫痪,上层LUN无法使用。
|
1月前
|
SQL Oracle 关系型数据库
Oracle数据库优化方法
【10月更文挑战第25天】Oracle数据库优化方法
47 7
|
1月前
|
Oracle 关系型数据库 数据库
oracle数据库技巧
【10月更文挑战第25天】oracle数据库技巧
30 6
|
1月前
|
存储 Oracle 关系型数据库
Oracle数据库优化策略
【10月更文挑战第25天】Oracle数据库优化策略
29 5
|
2月前
|
存储 Oracle 关系型数据库
Oracle数据库的应用场景有哪些?
【10月更文挑战第15天】Oracle数据库的应用场景有哪些?
189 64
|
4月前
|
存储 自然语言处理 Oracle
Oracle数据库字符集概述及修改方式
【8月更文挑战第15天】Oracle 数据库字符集定义了数据的编码方案,决定可存储的字符类型及其表示方式。主要作用包括数据存储、检索及跨系统传输时的正确表示。常见字符集如 AL32UTF8 支持多语言,而 WE8MSWIN1252 主用于西欧语言。修改字符集风险高,可能导致数据问题,需事先备份并评估兼容性。可通过 ALTER DATABASE 语句直接修改或采用导出-导入数据的方式进行。完成后应验证数据完整性。此操作复杂,须谨慎处理。
107 5
|
4月前
|
数据采集 Oracle 关系型数据库
实时计算 Flink版产品使用问题之怎么实现从Oracle数据库读取多个表并将数据写入到Iceberg表
实时计算Flink版作为一种强大的流处理和批处理统一的计算框架,广泛应用于各种需要实时数据处理和分析的场景。实时计算Flink版通常结合SQL接口、DataStream API、以及与上下游数据源和存储系统的丰富连接器,提供了一套全面的解决方案,以应对各种实时计算需求。其低延迟、高吞吐、容错性强的特点,使其成为众多企业和组织实时数据处理首选的技术平台。以下是实时计算Flink版的一些典型使用合集。

推荐镜像

更多