作者介紹

張家江，網易樂得高階工程師。

貴金屬（注：貴金屬為筆者部門業務）的行情繫統提供的介面通過Redis獲取資料，目前使用Redis最多隻儲存了大概8000條左右的分鐘k的行情資料，考慮到將來可能會有更大資料量的查詢需求，需要查詢幾月甚至幾年的行情資料，要求資料庫在提供功能的同時又能保證效能和穩定性。Redis通常只用做較小資料量的記憶體資料庫，而傳統關係資料庫又有一定的查詢效能瓶頸，所以考慮調研一下其它的NoSQL資料庫。

一、為什麼調研MongoDB？

圖1-1是DB-Engines2017年11月資料庫的排名統計，可以看到MongoDB總排名在第5，在NoSQL資料庫中排名第1。

圖1-1 DB-Engines2017年11月資料庫的排名統計

優點：

• 社群活躍，使用者較多，應用廣泛
• MongoDB在記憶體充足的情況下資料都放入記憶體且有完整的索引支援，查詢效率較高
• MongoDB的分片機制，支援海量資料的儲存和擴充套件

缺點：

• 不支援事務
• 不支援join、複雜查詢

初步調研下來，MongoDB具備我們需要的特性，而缺點不影響應用場景，故接下來我們就開始做實際的效能壓測。

二、壓測效能對比

1、準備條件

（1）MySQL 、MongoDB資料庫所在伺服器硬體環境

表2-1 伺服器硬體環境主要引數

（2）最新的資料庫版本

MongoDB server version: 3.4.5
MongoDB client version: mongo-java-driver-2.14.3
MySQL server version:5.6.34
MySQL connector version: MySQL-connector-java-6.0.6
MongoDB使用的儲存引擎wiredTiger
MySQL使用的儲存引擎InnoDB

（3）資料庫表結構及索引

MongoDB索引為dateTime 且是唯一索引。我們實際測試使用的MongoDB資料結構及欄位如圖2-1所示。

圖2-1 MongoDB資料表記錄示

MySQL索引為DATETIME,PARTNER_ID,GOODS_ID,SCOPE且是唯一索引。我們實際測試使用的MySQL資料結構及欄位如圖2-2所示。

圖2-2 MySQL資料表記錄示例

QL語句根據datetime欄位進行時間範圍的查詢

（4）連線池最大連線數都設定為200個，SQL語句調到最優

2、百萬、千萬級別的下不同查詢量不同併發量的壓測結果

資料庫表中記錄數總量在百萬、千萬級別的壓測資料及結果如表2-2所示。

表2-2 百萬、千萬級別的壓測資料及結果

3、億級別的下不同查詢量不同併發量的壓測結果

資料庫表中記錄數總量在億級別的壓測資料及結果如表2-3所示。

表2-3 億級別的壓測資料及結果

壓測結果分析：

• 當每次查詢資料量在500條時，無論表中資料總量千萬或者億級別，MySQL和MongoDB在100執行緒併發的情況下查詢效能相當，表現良好，平均響應時間在500ms以內，TPS在230左右。
• 當每次查詢資料量在5000條時，表中資料總量為千萬級別時，MongoDB在50執行緒併發情況下查詢效能不及MySQL 的一半，100執行緒併發情況查詢效能都很差，平均響應時間在4500ms左右，表中資料總量為億級別時，在50個及以上的併發情況下，MongoDB和MySQL效能都較差。

在本案例簡單資料模型下時間範圍內的等值查詢應用場景下，MongoDB在高併發條件下的大資料量查詢效能並沒有比MySQL更好。另外還有一點需要注意的是，在本案例中，資料總量由百萬級別到千萬級別再到億級別的變化過程中，對於查詢效能的影響都不是很大，但對於查詢資料量的數倍增長卻十分敏感，所以在考量資料庫查詢效能時，也要重點考量應用的單次查詢量的需求。

儘管MongoDB在我們的這種應用場景下並沒有達到預期的效能，我們也簡單地的調研了下MySQL和MongoDB對於記憶體的使用機制以及一些可能影響查詢效率的內部配置。

三、MySQL和MongoDB記憶體結構

1、InnoDB記憶體使用機制

InnoDB體系結構如圖3-1所示。

圖3-1 InnoDB體系結構

壓測MySQL使用的是InnoDB儲存引擎，InnoDB關於查詢效率有影響的兩個比較重要的引數分別是innodb_buffer_pool_size，innodb_read_ahead_threshold。

innodb_buffer_pool_size指的是InnoDB緩衝池的大小，本例中InnoDB緩衝池大小為20G，該引數的大小可通過命令指定innodb_buffer_pool_size 20G。緩衝池使用改進的LRU演算法進行管理，維護一個LRU列表、一個FREE列表，FREE列表存放空閒頁，資料庫啟動時LRU列表是空的，當需要從緩衝池分頁時，首先從FREE列表查詢空閒頁，有則放入LRU列表，否則LRU執行淘汰，淘汰尾部的頁分配給新頁。

innodb_read_ahead_threshold相對應的是資料預載入機制，innodb_read_ahead_threshold 30表示的是如果一個extent中的被順序讀取的page超過或者等於該引數變數的，InnoDB將會非同步的將下一個extent讀取到buffer pool中，比如該引數的值為30，那麼當該extent中有30個pages被sequentially的讀取，則會觸發InnoDB linear預讀，將下一個extent讀到記憶體中；在沒有該變數之前，當訪問到extent的最後一個page的時候，InnoDB會決定是否將下一個extent放入到buffer pool中；可以在MySQL服務端通過show InnoDB status中的Pages read ahead和evicted without access兩個值來觀察預讀的情況：

• Innodb_buffer_pool_read_ahead：表示通過預讀請求到buffer pool的pages；
• Innodb_buffer_pool_read_ahead_evicted：表示由於請求到buffer pool中沒有被訪問，而驅逐出記憶體的頁數。

可以看出來，MySQL的緩衝池機制是能充分利用記憶體且有預載入機制，在某些條件下目標資料完全在記憶體中，也能夠具備非常好的查詢效能。

2、MongoDB的儲存結構及資料模型

（1）本例中MongoDB使用的儲存引擎是WiredTiger，WiredTiger的結構如圖3-2所示。

圖3-2 WiredTiger Engine的結構

WiredTiger Cache的實現原理圖如圖3-3所示。

圖3-3 WiredTiger Cache的實現原理圖

Wiredtiger的Cache採用Btree的方式組織，每個Btree節點為一個page，root page是btree的根節點，internal page是btree的中間索引節點，leaf page是真正儲存資料的葉子節點；btree的資料以page為單位按需從磁碟載入或寫入磁碟。

可以通過在配置檔案中指定storage.wiredTiger.engineConfig.cacheSizeGB引數設定引擎使用的記憶體量。此記憶體用於快取工作集資料（索引、namespace，未提交的write，query緩衝等）。

（2）資料模型

內嵌

MongoDB的文件是無模式的，所以可以支援各種資料結構，內嵌模型也叫做非規格化模型（denormalized）。在MongoDB中，一組相關的資料可以是一個文件，也可以是組成文件的一部分。

圖3-4 內嵌文件示例

內嵌型別支援一組相關的資料儲存在一個文件中，這樣的好處就是，應用程式可以通過比較少的的查詢和更新操作來完成一些常規的資料的查詢和更新工作。

當遇到以下情況的時候，我們應該考慮使用內嵌型別：

如果資料關係是一種一對一的包含關係，例如下面的文件，每個人都有一個contact欄位來描述這個人的聯絡方式。像這種一對一的關係，使用內嵌型別可以很方便的進行資料的查詢和更新。

相對於嵌入模型，引用模型又稱規格化模型（Normalized data models），通過引用的方式來表示資料之間的關係。這裡同樣使用來自MongoDB文件中的圖片，在這個模型中，把contact和access從user中移出，並通過user_id作為索引來表示它們之間的聯絡。

圖3-5 引用文件示例

當我們遇到以下情況的時候，就可以考慮使用引用模型了：

• 使用內嵌模型往往會帶來資料的冗餘，卻可以提升資料查詢的效率。但是，當應用程式基本上不通過內嵌模型查詢，或者說查詢效率的提升不足以彌補資料冗餘帶來的問題時，我們就應該考慮引用模型了。
• 當需要實現複雜的多對多關係時，可以考慮引用模型。比如我們熟知的例子，學生-課程-老師關係，如果用引用模型來實現三者的關係，可能會比內嵌模型更清晰直觀，同時會減少很多冗餘資料。
• 當需要實現複雜的樹形關係時，可以考慮引用模型。

四、應用場景分析

1、MongoDB的應用場景

（1）表結構不明確且資料不斷變大

MongoDB是非結構化文件資料庫，擴充套件欄位很容易且不會影響原有資料。內容管理或者部落格平臺等，例如圈子系統、儲存使用者評論之類的。

（2）更高的寫入負載

MongoDB側重高資料寫入的效能，而非事務安全，適合業務系統中有大量“低價值”資料的場景。本身存的就是json格式資料。例如做日誌系統。

（3）資料量很大或者將來會變得很大

MySQL單表資料量達到5-10G時會出現明細的效能降級，需要做資料的水平和垂直拆分、庫的拆分完成擴充套件，MongoDB內建了sharding、很多資料分片的特性，容易水平擴充套件，比較好的適應大資料量增長的需求。

（4）高可用性

自帶高可用，自動主從切換（副本集）

不適用的場景

（1）MongoDB不支援事務操作，需要用到事務的應用建議不用MongoDB。
（2）MongoDB目前不支援join操作，需要複雜查詢的應用也不建議使用MongoDB。

2、關係型資料庫和非關係型資料庫的應用場景對比

關係型資料庫適合儲存結構化資料，如使用者的帳號、地址：

• 這些資料通常需要做結構化查詢，比如join。這時候，關係型資料庫就要勝出一籌
• 這些資料的規模、增長的速度通常是可以預期的
• 事務性、一致性

NoSQL適合儲存非結構化資料，如文章、評論：

• 這些資料通常用於模糊處理，如全文搜尋、機器學習
• 這些資料是海量的，而且增長的速度是難以預期的
• 根據資料的特點，NoSQL資料庫通常具有無限（至少接近）伸縮性
• 按key獲取資料效率很高，但是對join或其它結構化查詢的支援就比較差

原文來自微信公眾號：DBAplus社群