圍繞着內存數據庫的4個流言

摘要：Yiftach 表示，歷經數年，內存數據庫的穩定性已獲得了長足的發展，開發者應該理智地看待這個領域所存在的流言，好比內存計算是不可靠和不一致等。

【編者按】做者 Yiftach Shoolman 是 Redis Labs 的聯合創始人兼 CTO，擁有着豐富的實踐經驗。Yiftach 以前曾是 Crescendo Networks（後被 F5 收購）的總裁、建立者兼 CTO，更早仍是 Native Networks 的技術副總裁。在本文中，Yiftach 直述了當下開發者對內存數據庫所存在的偏見，並提出了一些技術選型參考意見，本文系 OneAPM 工程師編譯整理。

時下，咱們正處於一個突飛猛進的時代，而優秀應用的響應時間每每須要被控制在0.1秒內。這也意味着，若是可接受網絡通訊時間爲50毫秒，那麼開發者必須在剩餘的50毫秒內處理數據並進行響應。要實現這一點毫無疑問會需求毫秒級的數據庫響應時間，在同時支撐上萬個請求的場景中更是如此，而這樣的需求當下只有少數幾個靈活度極高、功能齊全的數據庫才能知足。

在大數據處理情景中，洞見必須被快速收集並作出決策，而在沒有複雜優化或折中的狀況下，內存數據庫能夠在數秒內完成以往傳統數據庫數小時或者數分鐘的工做。儘管如此，當下在內存數據庫領域仍然存在諸多流言，大量人仍然認爲內存數據庫不可靠性、不一致而且伴隨着昂貴的開銷。然而最重要的是，還有人認爲只要把數據庫放到內存中就能夠得到所需的性能。

流言1：全部內存數據庫都很快

答案顯然是否認的。即便當下大部份內存數據庫都使用很是高效的語言編寫，好比 C 和 C++，可是它們仍然沒法獲得所需的響應需求，這主要基於如下幾點緣由：

1. 在不一樣數據庫中，處理命令的複雜性是不一樣的。在高性能數據庫中，處理命令會在最小複雜度下執行。最直接的影響就是就是，在數據集不斷增大的狀況下，你可能須要一直優化查詢時間。

2. 查詢效率一樣不一樣。有些時候，數據庫會把所有加載進內存的數據當作單一的 BLOB（相似 memcached 的緩存機制），這顯然是沒有效率的——數據庫應該具有分散存儲和查詢值的能力，以及有效地節約網絡和內存開銷，從而顯著地下降應用程序處理時間。

3. 單線程和多線程架構的權衡。

多線程會盡量的利用計算能力，無需數據庫用戶作任何處理，可是這個解決方案一樣須要作大量的內部管理和同步，從而消耗大量的計算資源。在多線程模式下，鎖開銷可能會大幅度下降數據庫性能。

單線程使用了一個很是簡單的執行模型，在這個解決方案中不存在鎖的問題，同時也只會耗費少量的計算性能，但毫無疑問的是，計算資源的管理將從數據庫移交給用戶。理想的解決方案確定是讓用戶儘量少地作資源管理，由於數據庫管理原本就是個輕度資源密集型工做。

4. 零共享 vs. 共享 vs. 共享一切。共享會影響到系統的擴展性。在數據庫體積不斷增加的同時，性能也必須時刻知足實例的需求。零共享模型讓全部實體都以獨立單元的形式存在，從而避免了處理暴增後的通訊開銷，實現線性擴展能力。

5. 經過避免網絡方面任務和減小 TCP 協議開銷， 零延時分佈式代理等內置加速組件能夠顯著地提高數據庫性能。在某些狀況下，代理也可能與數據庫通訊，以肯定其是否做爲主機上服務遠程客戶端的另外一個本地客戶端進程。

若是吞吐量和延時是主要目標，那麼機構很顯然須要選擇一個能夠實現毫秒級延時並最小化服務器需求的數據庫。

流言2：內存計算是不可靠和不一致的

大多數 NoSQL 數據庫（不僅是內存數據庫）在提交數據到磁盤或者副本以前都爲客戶端提供了 acknowledgements （ack）。所以，這裏極可能會形成數據不一致的狀況。

CAP 定理標明任何分佈式計算機系統都不能同時具有一致性、可用性和分區容錯性。不一樣的數據庫會選擇不一樣的類型，具體情形以下：選擇 CP 模型表示開發者不用去關心一致性，可是在網絡分割事件中寫命令則是不容許的。若是選擇 AP 模型則意味着數據庫對讀寫一直可用，可是開發者在寫應用程序代碼時就須要考慮一致性問題，而不是指望數據庫去完成這個操做。所以，請根據使用場景來選擇合適的數據庫模型。

流言3：內存計算很難擴展

擴展共有兩個途徑。首先經過給託管數據庫的服務器縱向擴展，好比增長更多的 CPU 和內存；其次，經過向內存集羣中添加更多的主機實現橫向擴展。在許多數據庫中，你能夠在同一個節點上運行同一個數據集的多個分片，所以能夠經過更有效率的計算資源利用來延緩擴展需求。一樣，這裏也能夠將多個服務器的內存整合起來成爲一個共享內存池，從而突破單機內存大小限制。現下，不少內存數據庫同時容許這兩種方法的擴展，經過動態的增長分配給數據庫的核心和內存節點數量來最大化應用程序的響應能力。

流言4：內存計算是昂貴的

任何須要快速提高吞吐量的應用都面臨着相同的問題：「必定等級的吞吐量究竟須要花多少錢」。舉個例子，在1500萬 OPS 情景下，運行在單 Amazon EC2 實例上的內存數據庫會比非內存數據庫便宜，可是若是使用數百臺服務器達到一樣的效果結果可能就會截然相反。

若是數據集規模是 TB 級別，內存的花費很顯然會成爲問題，然而當下已經有使用閃存擴展內存的技術存在，從而下降花費。但須要注意的是，使用閃存來擴展內存勢必會影響到系統性能，所以這裏理想的技術是控制閃存和內存的比例以達到一個理想的性價比。

綜上所述，根據實際場景來選擇合適的數據庫技術將會大幅度提升資源利用效率。同時，新型數據庫出現已有很長一段時間，所以拋棄沒必要要的成見才能讓工做事半功倍。

原文連接：Busting 4 Myths of In-Memory Databases

本文系 OneAPM 工程師編譯整理。想閱讀更多技術文章，請訪問 OneAPM 官方博客。