缓存是新的内存 已翻译 100%

这是一次在 defrag 2014的演讲。 

这是经过长时间地多次技术变革后的（多个）技术优势之一。你看到了实际上突破。如果你只是看到了其中的一部分，很难正确推断。你要么短期有进展，要么落后很远。令人惊讶的不是事物变化的速度，而是一点一滴长期工程实践的突破。这是史端乔交换机，一个自动连接电话线路设备，在1891年发明的。

1951年，正是转向数字交换技术之时，一个典型的集中式交换中心基本上还是维多利亚时期的技术的放大版。每个转接过来的电话都有自己单独的strowger交换机。

当时来看，这已经是最牛逼的技术。当然我们看来，这只不过是当时世界上最大的蒸汽朋克(Steampunk，背景设在19世纪的科幻小说)风格的装置艺术(art installations)。

对此感到优越感可能是不对的。虽然集成电路(integrated circuit)已经面世65年了，仍然有数亿计的这种设备嗡嗡咔咔地运行着。直到现在，我们才真正地处在完全电子计算(solid-state computing, solid-state与机械相对，指基于半导体的)的转折点。

最令人兴奋的技术转变，一个是新的模型成为可行，另一个是旧的限制不再存在。在我们的工业界，这两种类型的转变都在上演。

分布式计算(distributed computing)现在是贯穿整个软件栈的主导性的编程模型。所谓的中央处理单元(central processing unit)不再是中心化的，甚至都不是一个单元了。它仅仅算是数据之山(a mountain of data)上爬行的一群虫子(Bugs)中的一个。数据库是最后的堡垒。

同时，内存与硬盘存储间的延迟正在变得无关紧要。30年来，数据库性能的主要关心点，在于访问内存与硬盘存储上的随机数据的巨大差别。既然现在我们可以把数据全部放在内存中，这些烦恼统统不用考虑了。当然不是这么简单，你不能用一个B树，mmap一下，然后就能搞定。在完全基于内存的设计方案推出之前还有很多相关的东西要解决。

这两种新趋势产生了完全崭新的方式来思考、设计、构建应用。现在我们来谈下我们怎么达到，我们怎么做的，未来给我们的启示。

(史前时代，从下文看应该是2000年前，用户被描述成恐龙，作者的小幽默)

那时候，架构图里的每个组件都有一个确定的描述与之相关。每个组件都是一个单独的功能：数据库、web服务器，都成为一屋之剧中的不同角色(一屋指的是机房或data center)。 顺带提一下，这就是“the cloud”这个词的来源。一个轻软/毛茸茸的云是WAN的标准符号，而WAN的细节我们完全不用操心。

(2000年，负载均衡解决一切)

容易实现的分布式计算得到了主流的亲睐。多个完全相同的应用程序服务器藏在一个负载均衡器(load balancer)之后，这个均衡器把负载差不多平均地分配到应用程序服务器上去。只负载均衡那些架构中状态无关的部分回避了很多哲学上的问题(理论上的情况？)。当系统扩展时，这些组件从侧翼包抄，最后包围了“the” database。我们告诉自己，给数据库换上更快的磁盘、更快的CPU很正常，毕竟还是只需要一台机器。硬件提供商很高兴地赚着我们的钱。

(2002：备份解决一切)

最后，数据库备份成为合情合理的，加了一个热备份数据库(hot spare database)后，我们的良心得到些许宽慰。然后我们告诉自己，不会再有任何故障了。当然，这种正确性只存在了几分钟。

当然，热备份经常是空闲的(sitting idle)。一旦商业分析员意识到，他们可以在不触及生产数据的情况下，也能对生产数据进行大规模查询，那么所谓的热备份也几乎跟生产数据一样开始忙碌并且至关重要了。我们又告诉自己，在紧急情况下把热备份暂时拿出来也还好。但这就如同说，我们完全没必要带备胎，因为我们可以从其他车上偷一个过来！

(2004：memcached/缓存解决一切)

然后，Brad Fitzpatrick发布了memcached，一个可以在内存中缓存数据的守护程序(因此叫memcached, memory cached)。这是个简化版的分布式哈希表，而且确实非常实用，因而之后就在学术界流行起来。它拥有很多特性：备份(a form of replication?)，水平分区，负载均衡，简单数学运算等。 我们再次告诉自己，既然大部分的负载都是读，我们为什么还要催促数据库从磁盘一遍一遍做相同的查询？你只需要一组内存很大的小规模(small-calibre,小口径)服务器，当然硬件提供商也高兴地赚我们(买内存)的钱。

也许需要你写些缓存失效(cache invalidation)代码，这听起来不难，对吧。

(2004：memcached解决一切，添加了缓存失效)

确如其声称，memcached的方案使我们受益很长时间。它把硬盘的随机IO操作替换为内存的随机IO操作。尽管如此，那台数据库机器还是越来越大，越来越忙。我们意识到，缓存的内存开销至少会跟工作集一样大(不然就是无效了)，再加上让人不能忍的缓存持久化。我们告诉自己，这就是网络级规模(web scale？)的开销。

(2006：水平分区/切分解决一切)

更令人担心的是应用越来越复杂，越来越聊天化(chattier，可能聊天程序对数据库写的次数很多)。几乎每次都会进行多次数据库写操作。现在，写，而不是读，成为了瓶颈。这时我们才最终认真对待数据库切分。Facebook最初是根据university字段来切分其用户数据，然后做成了"哈佛数据库(The Harvard Database)"，并且维持了很长一段时间。Flickr是另一个好例子。他们使用PHP手动建立了一个切分系统，这个系统使用用户ID的哈希值来切分数据库，跟memcached根据key来切分很像。在技术交流会上，他们透露，不得不对数据表去规范化(denormalize)，以及对一些对象(比如评论、消息、喜欢)进行两次写(doule-write)。

要解决无限伸缩(infinite scaling)总要付出点代价，对吧。

(2008：NoSQL解决一切)

手动切分关系型数据库的问题是，你的关系型数据库已经没了。切分API实际上成为你的查询语言了。你对操作的头疼还没好，而修改一组模式(schema)更加痛苦。

这就需要大家深呼一口气，列出大家选用的SQL实现的所有不足和瑕疵，然后因此责怪SQL。一波潮人似的NoSQL，难民似的XML数据库出现了，并且都作出了根本办不到的承诺。它们提供了自动切分，灵活的模式，一些冗余，...，一开始也就这么多。但是总比自己写要好多了。

你知道，“不用自己写”成为主要卖点的东西总是令人绝望。

(2010：Map/Reduce解决一切)

转移到NoSQL并不比使用手动切分差，因为我们已经放弃了使用常用的客户端工具控制和分析数据的希望。但这没好多少。之前由商业人员(business folks)编写的SQL查询变成了开发人员维护的报表代码。

还记得用于备份和分析的热备份数据库吧？现在它变身为Hadoop filestores以及上层的Hive查询而卷土重来了。既然奏效，商业人员再也不来烦我们了。但一个大问题是，这些系统的操作复杂性。就像航天飞机一样，它们是作为可靠且几乎不用维护的产品出售的，但是最后还是需要大量的手动操作。另一个大问题是，数据的存入和取出：花费一整天的时间已经相当不错了。第三个大问题是IO同时成为网络和磁盘的瓶颈。我们告诉自己，这就是从大数据(big data)毕业的代价。

不管怎样，Google就是这样做的，对吧。

(2012：NoSQL再次解决一切)

随着一些NoSQL数据库的逐渐成熟，它们的API发生了诡异的变化：它们开始长得像SQL一样。这是因为SQL是关系型集合理论(relational set theory)的相当直接的实现，而数学不是那么好愚弄的。

我重述下Paul Graham对Lisp那难以忍受、并自鸣得意的评论：一旦你添加了group by, filter, join，你也不能声称发明了新的查询语言，因为这仅仅算是SQL的一个新方言。而且语法很差，还没有优化器。

由于我们绕过了SQL，大部分系统都缺少了一些很重要的东西，比如存储引擎、查询优化器，而这些都是基于关系型集合理论设计的。拖延到后期去实现导致了严重的性能问题。即使对解决了性能问题的那些(或者通过停驻在内存中来掩盖此问题)，也缺少了其他东西，如合适的备份。