緩存是新的內存

英文原文：Cache is the new RAM

　　這是一次在 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，大部分系統都缺乏了一些很重要的東西，好比存儲引擎、查詢優化器，而這些都是基於關係型集合理論設計的。拖延到後期去實現致使了嚴重的性能問題。即便對解決了性能問題的那些(或者經過停駐在內存中來掩蓋此問題)，也缺乏了其餘東西，如合適的備份。

　　我知道一個很是成功的互聯網初創公司(你確定也聽過)使用了4個(!!)不一樣的NoSQL系統來解決問題。

(2014：如今須要什麼來解決一切？)

　　如今已經至關明顯，咱們不會回到單數據庫以及10毫秒一次的隨機定位(10-million-nanosecond random seek，上文幻燈有提到，讀一次硬盤要10毫秒)的那個從前了。在尋找一勞永逸解決全部問題的炒做週期(hype cycle, 也叫技術成熟度曲線)的過程當中，有個有趣的模式：聰明的方法在減輕一個痛點的同時會引入新的痛點。

　　因此下一個添到這張圖上的複雜工具是什麼呢？也許真正的方法是能簡化事情的。

　　例如內存：在數據庫機器上有不少內存，用作緩衝和計算；Memcached機器上也有不少內存。這些系統中的內存總和至少跟你的工做數據集同樣大。若是不是，你就賺到了(under-bought，低階買到好貨)。並且，我很是懷疑你的緩存層是否100%高效。我打賭你有大量數據在被替換掉以前沒有被讀取過，我還打賭你歷來沒跟蹤過。這不意味着你是個壞孩子，而意味着緩存比起其所值，更是個麻煩。

　　這些組件共有的不少特性看起來，是能夠相互組合，而且互補的。只要它們被安排得合理。

　　一旦你採用下面的公理：系統應該是分佈式的，而數據應該是數字化的(solid-state是純電氣的，而不是mechanical機械式的)，有意思的事情出現了：模型更簡單了。在查詢觸發時纔會用到的臨時內存數據結構是僅有的結構。隨機訪問再也不是大罪，而是商業的正常過程。你沒必要擔憂分頁，或者再均衡(rebalancing)，或者數據的位置。

(2014：SQL內存集羣解決一切)

　　這是個優美、簡單的架構。就像負載均衡器抽象了應用程序服務器，SQL聚合器(aggregators)抽象了讀寫的組織細節。把數據存放策略的核心放在穩定的API之下，能夠在少許中斷的狀況下容許兩邊變化。

　　如今，一切都好了，咱們最終到達了歷史最後的美好之地，對吧？

　　無論你在什麼時候，對計算藝術狀態的自滿都是錯誤的。總會有其餘瓶頸。

　　這是AMD的Barcelona芯片，至關現代化的設計。它有4個核，可是大部分表面都被緩存和核心(core)周圍的I/O區域佔據，就像WalMart周圍的大型停車場同樣。奔騰時代，緩存區域只佔晶圓(die)的15%。第三次計算領域的革命在於，CPU相對於內存快了多少。所以晶圓上大片昂貴的區域都爲緩存保留着。

　　過去，數據庫性能的主要關注點在內存和硬盤的延遲，如今咱們打趣CPU和內存的延遲不是一樣的問題，可是它確實是。

　　並且咱們裝做共享內存是存在的，但卻不是。有那麼多核心和內存，總會有些核心離部份內存很近。

　　當你仔細想下，計算機確實只作了兩件事：讀符號，寫符號。性能是個計算機有多少數據要移動，數據要到哪裏去的功能問題。最好的可能情形是大量的順序數據流被讀取一次，很快地處理後，就再也不被用到。GPU是個很好的例子。可是最有意思的負載不是這樣的。

(吞吐量和延遲總會笑到最後)

　　每一個隨機指針都會保證緩存一次不中，每一個對同一塊內存區域(好比寫鎖)的競爭都會引發大量的協調延遲。即便你的CPU緩存命中率達到99%(事實上不可能)，等待內存的時間也會是主導性的。

　　或者這樣說吧：若是磁盤是新的磁帶，內存就是新的硬盤，CPU緩存是新的內存。位置仍然有關係。

　　因此，什麼會解決這個問題？看起來這就是那個相同的古老的矛盾：咱們優化隨機訪問，仍是優化串行？咱們接納寫，仍是讀的性能問題？仍是咱們乾坐着等硬件速度跟上來？也許記憶電阻器(memristor)或者其餘技術會使這些問題可有可無。固然，我也須要些錢(pony, 小馬？)。

　　好消息是分佈式數據庫的整體物理架構基本成型。數據客戶端再也不須要處理4或5個不一樣的子系統的內部細節。這還不完美，也不是主流。可是突破總歸須要一段時間來傳播。

　　但若是瓶頸仍是在存儲位置，這意味着其餘部分都成熟了。創新可能在數據結構和算法領域發生。也不多會有清理架構的改動，來承諾一次解決所有問題。若是咱們幸運，接下來的15年，SQL數據庫會慢慢變得更快更高效，而API是相同的。

　　可是在此以前，工業界將不會平靜。

 

http://kb.cnblogs.com/page/509527/