圍繞著記憶體資料庫的 4 個流言

時下，我們正處於一個日新月異的時代，而優秀應用的響應時間往往需要被控制在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級別，記憶體的花費很顯然會成為問題，然而當下已經有使用快閃記憶體擴充套件記憶體的技術存在，從而降低花費。但需要注意的是，使用快閃記憶體來擴充套件記憶體勢必會影響到系統效能，因此這裡理想的技術是控制快閃記憶體和記憶體的比例以達到一個理想的價效比。

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

作者Yiftach Shoolman是Redis Labs的聯合創始人兼CTO，擁有著豐富的實踐經驗。Yiftach 之前曾是Crescendo Networks（後被F5收購）的總裁、建立者兼CTO，更早還是Native Networks的技術副總裁。