摘要：摘要表示，歷經(jīng)數(shù)年，內(nèi)存數(shù)據(jù)庫的穩(wěn)定性已得到了長足的發(fā)展，開發(fā)者應該理智地看待這個領(lǐng)域所存在的流言，比如內(nèi)存計算是不可靠和不一致等。盡管如此，當下在內(nèi)存數(shù)據(jù)庫領(lǐng)域仍然存在諸多流言，大量人仍然認為內(nèi)存數(shù)據(jù)庫不可靠性不一致并且伴隨著昂貴的開銷。

摘要：Yiftach 表示，歷經(jīng)數(shù)年，內(nèi)存數(shù)據(jù)庫的穩(wěn)定性已得到了長足的發(fā)展，開發(fā)者應該理智地看待這個領(lǐng)域所存在的流言，比如內(nèi)存計算是不可靠和不一致等。

【編者按】作者 Yiftach Shoolman 是 Redis Labs 的聯(lián)合創(chuàng)始人兼 CTO，擁有著豐富的實踐經(jīng)驗。Yiftach 之前曾是 Crescendo Networks（后被 F5 收購）的總裁、創(chuàng)建者兼 CTO，更早還是 Native Networks 的技術(shù)副總裁。在本文中，Yiftach 直述了當下開發(fā)者對內(nèi)存數(shù)據(jù)庫所存在的偏見，并提出了一些技術(shù)選型參考意見，本文系 OneAPM 工程師編譯整理。

時下，我們正處于一個日新月異的時代，而優(yōu)秀應用的響應時間往往需要被控制在0.1秒內(nèi)。這也意味著，如果可接受網(wǎng)絡(luò)通信時間為50毫秒，那么開發(fā)者必須在剩余的50毫秒內(nèi)處理數(shù)據(jù)并進行響應。要實現(xiàn)這一點毫無疑問會需求毫秒級的數(shù)據(jù)庫響應時間，在同時支撐上萬個請求的場景中更是如此，而這樣的需求當下只有少數(shù)幾個靈活度極高、功能齊全的數(shù)據(jù)庫才能滿足。

在大數(shù)據(jù)處理情景中，洞見必須被快速收集并做出決策，而在沒有復雜優(yōu)化或折中的情況下，內(nèi)存數(shù)據(jù)庫可以在數(shù)秒內(nèi)完成以往傳統(tǒng)數(shù)據(jù)庫數(shù)小時或者數(shù)分鐘的工作。盡管如此，當下在內(nèi)存數(shù)據(jù)庫領(lǐng)域仍然存在諸多流言，大量人仍然認為內(nèi)存數(shù)據(jù)庫不可靠性、不一致并且伴隨著昂貴的開銷。然而最重要的是，還有人認為只要把數(shù)據(jù)庫放到內(nèi)存中就可以獲得所需的性能。

答案顯然是否定的。即使當下大部分內(nèi)存數(shù)據(jù)庫都使用非常高效的語言編寫，比如 C 和 C++，但是它們?nèi)匀粺o法得到所需的響應需求，這主要基于以下幾點原因：

1. 在不同數(shù)據(jù)庫中，處理命令的復雜性是不同的。在高性能數(shù)據(jù)庫中，處理命令會在最小復雜度下執(zhí)行。最直接的影響就是就是，在數(shù)據(jù)集不斷增大的情況下，你可能需要一直優(yōu)化查詢時間。

2. 查詢效率同樣不同。有些時候，數(shù)據(jù)庫會把全部加載進內(nèi)存的數(shù)據(jù)當做單一的 BLOB（類似 memcached 的緩存機制），這顯然是沒有效率的——數(shù)據(jù)庫應該具備分散存儲和查詢值的能力，以及有效地節(jié)約網(wǎng)絡(luò)和內(nèi)存開銷，從而顯著地降低應用程序處理時間。

3. 單線程和多線程架構(gòu)的權(quán)衡。

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

單線程使用了一個非常簡單的執(zhí)行模型，在這個解決方案中不存在鎖的問題，同時也只會耗費少許的計算性能，但毫無疑問的是，計算資源的管理將從數(shù)據(jù)庫移交給用戶。理想的解決方案肯定是讓用戶盡可能少地做資源管理，因為數(shù)據(jù)庫管理本來就是個輕度資源密集型工作。

4. 零共享 vs. 共享 vs. 共享一切。共享會影響到系統(tǒng)的擴展性。在數(shù)據(jù)庫體積不斷增長的同時，性能也必須時刻滿足實例的需求。零共享模型讓所有實體都以獨立單元的形式存在，從而避免了處理暴增后的通信開銷，實現(xiàn)線性擴展能力。

5. 通過避免網(wǎng)絡(luò)方面任務(wù)和減少 TCP 協(xié)議開銷， 零延時分布式代理等內(nèi)置加速組件可以顯著地提升數(shù)據(jù)庫性能。在某些情況下，代理也可能與數(shù)據(jù)庫通信，以確定其是否作為主機上服務(wù)遠程客戶端的另一個本地客戶端進程。

如果吞吐量和延時是主要目標，那么機構(gòu)很顯然需要選擇一個可以實現(xiàn)毫秒級延時并最小化服務(wù)器需求的數(shù)據(jù)庫。

大多數(shù) NoSQL 數(shù)據(jù)庫（不只是內(nèi)存數(shù)據(jù)庫）在提交數(shù)據(jù)到磁盤或者副本之前都為客戶端提供了 acknowledgements （ack）。因此，這里很可能會造成數(shù)據(jù)不一致的情況。

CAP 定理標明任何分布式計算機系統(tǒng)都不能同時具備一致性、可用性和分區(qū)容錯性。不同的數(shù)據(jù)庫會選擇不同的類型，具體情形如下：選擇 CP 模型表示開發(fā)者不用去關(guān)心一致性，但是在網(wǎng)絡(luò)分割事件中寫命令則是不允許的。如果選擇 AP 模型則意味著數(shù)據(jù)庫對讀寫一直可用，但是開發(fā)者在寫應用程序代碼時就需要考慮一致性問題，而不是期望數(shù)據(jù)庫去完成這個操作。因此，請根據(jù)使用場景來選擇合適的數(shù)據(jù)庫模型。

擴展共有兩個途徑。首先通過給托管數(shù)據(jù)庫的服務(wù)器縱向擴展，比如增加更多的 CPU 和內(nèi)存；其次，通過向內(nèi)存集群中添加更多的主機實現(xiàn)橫向擴展。在許多數(shù)據(jù)庫中，你可以在同一個節(jié)點上運行同一個數(shù)據(jù)集的多個分片，因此可以通過更有效率的計算資源利用來延緩擴展需求。同樣，這里也可以將多個服務(wù)器的內(nèi)存整合起來成為一個共享內(nèi)存池，從而突破單機內(nèi)存大小限制。現(xiàn)下，很多內(nèi)存數(shù)據(jù)庫同時允許這兩種方法的擴展，通過動態(tài)的增加分配給數(shù)據(jù)庫的核心和內(nèi)存節(jié)點數(shù)量來最大化應用程序的響應能力。

任何需要快速提升吞吐量的應用都面臨著相同的問題：「一定等級的吞吐量究竟需要花多少錢」。舉個例子，在1500萬 OPS 情景下，運行在單 Amazon EC2 實例上的內(nèi)存數(shù)據(jù)庫會比非內(nèi)存數(shù)據(jù)庫便宜，但是如果使用數(shù)百臺服務(wù)器達到同樣的效果結(jié)果可能就會截然相反。

如果數(shù)據(jù)集規(guī)模是 TB 級別，內(nèi)存的花費很顯然會成為問題，然而當下已經(jīng)有使用閃存擴展內(nèi)存的技術(shù)存在，從而降低花費。但需要注意的是，使用閃存來擴展內(nèi)存勢必會影響到系統(tǒng)性能，因此這里理想的技術(shù)是控制閃存和內(nèi)存的比例以達到一個理想的性價比。

綜上所述，根據(jù)實際場景來選擇合適的數(shù)據(jù)庫技術(shù)將會大幅度提高資源利用效率。同時，新型數(shù)據(jù)庫出現(xiàn)已有很長一段時間，因此拋棄不必要的成見才能讓工作事半功倍。

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

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