缓存是新的内存

缓存| 2014-11-24

这是一次在 defrag 2014的演讲。

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

Screen Shot 2014-11-11 at 3.37.53 PM

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

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

Screen Shot 2014-11-11 at 3.42.16 PM

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

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

Screen Shot 2014-11-11 at 3.42.40 PM

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

Screen Shot 2014-11-11 at 3.43.37 PM

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

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

Screen Shot 2014-11-11 at 3.44.15 PM (史前时代，从下文看应该是2000年前，用户被描述成恐龙，作者的小幽默)

那时候，架构图里的每个组件都有一个确定的描述与之相关。每个东西都是一个单独的功能： “the” database(数据库)， “the” web server(服务器), characters in a one-room drama(用户). 顺便提一下，这就是“the cloud”这个词的来源。一个轻软/毛茸茸的云是WAN的标准符号，而WAN的细节我们完全不用操心。

Screen Shot 2014-11-11 at 3.45.10 PM (2000年，负载均衡解决一切)

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

Screen Shot 2014-11-11 at 3.45.42 PM (2002：备份解决一切)

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

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

Screen Shot 2014-11-11 at 3.46.59 PM (2004：memcached/缓存解决一切)

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

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

Screen Shot 2014-11-11 at 3.47.06 PM (2004：memcached解决一切，添加了缓存失效)

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

Screen Shot 2014-11-11 at 3.47.12 PM (2006：水平分区/切分解决一切)

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

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

Screen Shot 2014-11-11 at 3.47.18 PM (2008：NoSQL解决一切)

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

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

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

Screen Shot 2014-11-11 at 3.47.25 PM (2010：Map/Reduce解决一切)

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

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

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

Screen Shot 2014-11-11 at 3.47.32 PM (2012：NoSQL再次解决一切)

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

Screen Shot 2014-11-11 at 3.47.46 PM

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

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

我知道一个非常成功的互联网初创公司(你肯定也听过)使用了4个(!!)不同的NoSQL系统来解决问题。

Screen Shot 2014-11-11 at 3.47.54 PM (2014：现在需要什么来解决一切？)

现在已经相当明显，我们不会回到单数据库以及10毫秒一次的随机定位(10-million-nanosecond random seek)的那个从前了。在寻找一劳永逸解决所有问题的炒作周期(hype cycle, 也叫技术成熟度曲线)的过程中，有个有趣的模式：聪明的方法在减轻一个痛点的同时会引入新的痛点。

Screen Shot 2014-11-11 at 3.48.01 PM

所以下一个添到这张图上的复杂工具是什么呢？也许真正的方法是能简化事情的。

例如内存：在数据库机器上有很多内存，用做缓冲和计算；Memcached机器上也有很多内存。这些系统中的内存总和至少跟你的工作数据集一样大。如果不是，你就赚到了(under-bought，低阶买到好货)。而且，我非常怀疑你的缓存层是否100%高效。我打赌你有大量数据在被替换掉之前没有被读取过，我还打赌你从来没跟踪过。这不意味着你是个坏孩子，而意味着缓存比起其所值，更是个麻烦。

这些组件共有的很多特性看起来，是可以相互组合，并且互补的。只要它们被安排得合理。

Screen Shot 2014-11-11 at 3.48.07 PM

一旦你采用下面的公理：系统应该是分布式的，而数据应该是数字化的(solid-state是纯电气的，而不是mechanical机械式的)，有意思的事情出现了：模型更简单了。在查询触发时才会用到的临时内存数据结构是仅有的结构。随机访问不再是大罪，而是商业的正常过程。你不必担心分页，或者再均衡(rebalancing)，或者数据的位置。

Screen Shot 2014-11-11 at 3.48.13 PM (2014：SQL内存集群解决一切)

这是个优美、简单的架构。就像负载均衡器抽象了应用程序服务器，SQL聚合器(aggregators)抽象了读写的组织细节。把数据存放策略的核心放在稳定的API之下，可以在少量中断的情况下允许两边变化。

Screen Shot 2014-11-11 at 3.48.24 PM

现在，一切都好了，我们最终到达了历史最后的美好之地，对吧？

Screen Shot 2014-11-11 at 3.48.30 PM

不管你在何时，对计算艺术状态的自满都是错误的。总会有其他瓶颈。

Screen Shot 2014-11-11 at 3.48.35 PM

这是AMD的Barcelona芯片，相当现代化的设计。它有4个核，但是大部分表面都被缓存和核心(core)周围的I/O区域占据，就像WalMart周围的大型停车场一样。奔腾时代，缓存区域只占晶圆(die)的15%。第三次计算领域的革命在于，CPU相对于内存快了多少。因此晶圆上大片昂贵的区域都为缓存保留着。

过去，数据库性能的主要关注点在内存和硬盘的延迟，现在我们打趣CPU和内存的延迟不是同样的问题，但是它确实是。