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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

本文系 OneAPM 工程師編譯整理。想閱讀更多技術(shù)文章，請(qǐng)?jiān)L問(wèn) OneAPM 官方博客。