亚马逊Aurora搞垮PrimeDay这点事

最近出差进行到下半场，特别繁忙，写稿有点懈怠。今天就聊一个事情吧。

这篇文章的详情大家可以去阅读原文，我这里原封不动的引用一下文章的总结:

据外媒CNBC获得的内部文件显示，亚马逊迁离Oracle的数据库使用Aurora PostgreSQL是Prime Day促销日陷入瘫痪的主要原因。

这次故障突显了亚马逊希望在2020年之前完全摆脱Oracle数据库的过程中可能面临的挑战。

近年来亚马逊和Oracle在打口水仗，声称自家数据库软件和云工具的性能更胜一筹。

亚马逊现在算是领教了迁离Oracle数据库软件有多困难。

简单总结来说，亚马逊为了去Oracle，把内部的业务搬迁到自研的云端数据库Aurora上。这个搬迁导致在PrimeDay业务出现了问题。在亚马逊自己的调查报告中，声称这次故障导致了15000件包裹延迟发货，并浪费了90000美元劳动力成本。

在我看来，这篇CNBC的文章有点危言耸听了，亚马逊其实做得很好。

我们先说一下Aurora这个产品。很长一段时间里，Aurora这个产品除了兼容mySQL(以及还有一个Postgres版本)以外，外界对其如何实现这个系统所知不多。

Aurora团队在数据库顶级会议SIGMOD2017年和2018年各自发表了一篇文章，介绍了Aurora这个系统的系统架构和实现过程中遇到的各种问题。这两篇论文是亚马逊发表的论文里水准非常高的论文。

2017年的论文介绍了Aurora的基本架构。我第一次读到这篇论文的时候，我的感觉首先是吃惊：妈蛋，数据库还能这么搞，其次是深深的敬佩。不得不说，Aurora团队给出了一个特别适合云端，特别优雅的架构。让我忍不住要去拜一拜学习一下的感觉。具体架构好在哪里我就不展开了。网上评论文章不少。

我当时就觉得这个架构不太像是我们这些循规蹈矩，被关系数据库理论给熏坏了的传统数据库人能搞出来的。后来偶然机会遇到知情人，对方告诉我说，是做操作系统的人搞出来的。我还遇到过一个微软级别很高的人，对方一直感叹Aurora团队为什么要做活雷锋，把这样一个优雅的架构堂而皇之的公开发表了，这个做法一点也不亚马逊。我必须说我是非常的佩服Aurora团队的技术实力的。

换个角度看，Oracle数据库自然是代表关系数据库有历史以来，通用数据库可以达到的高度。这个集合Oracle几十年技术结晶，给Oracle带来无数财源的系统，绝对不可小视。那些拍着脑袋以为能够去IBM小型机和EMC存储那样可以把Oracle轻松去掉的人，都有点傻。换句话说能去Oracle的，那的确代表着高水平。

我是做过系统开发的。大系统最重要的就是通过业务去打磨。在架构不犯错的前提下，通过业务不断打磨才有可能把系统做得稳定下来。所以亚马逊决定用自己的Aurora替换Oracle，尤其是在自己的核心应用上替换，这不仅仅是勇气的体现，更是亚马逊最终去掉Oracle必然要走的步骤。

这种打磨的过程，如果不出一点点事故，那就是笑话了。要是出了事故又能顺利解决，这才可能打造出一个强悍的自研系统，并顺利去掉Oracle。从这个角度来看，这个事故既表明了亚马逊去Oracle的决心，更是亚马逊去Oracle的道路上必然会付出的代价。对于这种做法，CNBC是有点胡说八道了。在我看来，相反的，亚马逊敢这样做，才有成功的可能。

有人问如果这样来说阿里巴巴去Oracle是不是更伟大。当然，从某个意义上来讲阿里巴巴去Oracle非常的伟大。但是两家公司的策略还是有差别的。应该说，两家公司各有各的牛。

在大数据和数据库相关的领域，我首先是一个技术人员。技术人员应该有自由去发表自己对技术的观点和看法。这些观点可能是不全面的，也可能是正确的。但是作为业务层面的各个公司，对技术人员聊技术保持最基本的尊重。

今天我得到了来自某人代表亚马逊的感谢，主要是感谢我跳出来就CNBC明显不对的观点给亚马逊的Aurora站台。但是我站台其实也是就是论事从技术的角度出发，我认为CNBC说得不对。

我曾经就亚马逊的Redshift写过一篇文章：干货分享!坑爹的亚马逊之Redshift。这篇文章我写了对Redshift的顾虑。以及后面写的文章从Redshift一文出发聊聊创作的问题解释了我对这种顾虑的来龙去脉。

今天旧事重提，是因为当时我发表的第一篇文章之后，收到了来自亚马逊中国的公关。公关分两路，一路是有人留言代表了Redshift说我说的不对。读我号比较久的人都知道，我这里即使有和我完全不同意见和观点的留言，我从来都是放出来的。所以明显代表Redshift观点的留言我也放出来了。