正文
第二个，前面提到的那个infrastructure团队，对客户要提供一层JDBC的封装，让内部的技术能力，也通过SQL的形式暴露出来。因为有了类似Hive这样的工具，在这种情况下应用层的部分可以尽可能地保持稳定，原本的Oracle下的sql有改动和转换，但依然是SQL，只不过执行的不再是数据库引擎，而是MapReduce任务了。我觉得这件事情很有意思，也很有挑战性。困难很多，比如索引的问题，运算透明性（包括调试）的问题（SQL有执行计划之类的工具可以让我们对其执行机制了解清楚，但是换成MapReduce job以后显然问题就困难得多了）等等。但是带来的收益是显而易见的，比如说，整个运算资源是弹性的——重要的急迫的任务优先级高，分配资源多，参与运算的instance多，从而缩短得出结果的时间。
去Oracle是否意味着关系型数据库不成功？
当然不是——
关系型数据库不但在过去的几十年内很成功，而且成功到被乱用滥用了。冯大辉以前说过一个被滥用的例子，阿里旺旺在用户量那么高的情况下，居然还用Oracle数据库在做存储。而我身边也有这样的例子，在我换组前，我原来的组，就把持着整个Amazon内部最大的Oracle数据库，一大堆分区，动不动成天几千万行的数据读写。其实不但是数据库这一层跟不上节奏了，还有工作流引擎也是，老的工作流引擎要淘汰，老团队不维护了，但是因为当时我们组在这个老东西上面的job太多，没法切换，成为钉子户，被迫揽下了维护这个老工作流引擎的任务，直到它退休，成为全公司唯一使用它，并且是这一方面淘汰老技术最慢的……
其实整体看来，Amazon这样的互联网公司淘汰老旧的技术的速度已经算很快了（尤其是和传统软件公司比起来），有时候会遇到引进新技术和造轮子过度的问题（比如好多组都有自己搞的一套听起来高大上的数据存储系统，还有就是工作流系统，也是遍地开花），但是总的思路还是挺激进的：随时准备拆了轮子重造。问题小就解决，问题大就重写。且不说这做法利弊各占多少，每次搞宣传招人的时候，造新轮子和大轮子这一点，确实是吸引人啊。
再一个例子，记得刚工作那会儿，去北京联通开局，负载分担是F5，服务器挂在单板上，存储用的是磁盘阵列，数据库双机用的是IBM小型机（和美国车一样，“保修期”内屁事儿没有，“保修期”一过就开始噼里啪啦乱出问题，然后赚修车费）。在当时这几个玩意儿听听就是不差钱的主儿才能购置装配的东西，看看互联网公司谁敢这么搞？无论是云存储还是云计算，用的都是成本很低的硬件，有的功能直接替代由软件完成，但是这恰恰解释了和关系型数据库的发展到辉煌，再到演退相同的现象，这些硬件也是在一定时期内代表了特定的技术流行，如今也慢慢被单设备成本低，但是规模更大的集群代替。
