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

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

建议继续学习：

1. 我对技术方向的一些反思    (阅读：9945)
2. Oracle or MySQL ?    (阅读：3450)
3. Java陷阱(2010版)    (阅读：3313)
4. 如何正确安装ORACLE使ORACLE状态最优    (阅读：3313)
5. Oracle Database 12c架构图    (阅读：3304)
6. Oracle+Fusionio+Dataguard的高可用方案    (阅读：2584)
7. Oracle Database Appliance    (阅读：2709)
8. 分享点Oracle相关的资料    (阅读：2651)
9. 云和恩墨版Oracle Database 12c 最新体系结构图下载    (阅读：2494)
10. 核心业务系统数据库平台迁移： Oracle -> MySQL    (阅读：2254)