日韩无码专区无码一级三级片|91人人爱网站中日韩无码电影|厨房大战丰满熟妇|AV高清无码在线免费观看|另类AV日韩少妇熟女|中文日本大黄一级黄色片|色情在线视频免费|亚洲成人特黄a片|黄片wwwav色图欧美|欧亚乱色一区二区三区

RELATEED CONSULTING
相關咨詢
選擇下列產品馬上在線溝通
服務時間：8:30-17:00
你可能遇到了下面的問題
關閉右側工具欄

新聞中心

這里有您想知道的互聯(lián)網營銷解決方案
從MySQL和MongoDB的對比，看SQL與NoSQL的較量

貴金屬(注：貴金屬為筆者部門業(yè)務)的行情系統(tǒng)提供的接口通過Redis獲取數(shù)據(jù)，目前使用Redis最多只存儲了大概8000條左右的分鐘k的行情數(shù)據(jù)，考慮到將來可能會有更大數(shù)據(jù)量的查詢需求，需要查詢幾月甚至幾年的行情數(shù)據(jù)，要求數(shù)據(jù)庫在提供功能的同時又能保證性能和穩(wěn)定性。Redis通常只用做較小數(shù)據(jù)量的內存數(shù)據(jù)庫，而傳統(tǒng)關系數(shù)據(jù)庫又有一定的查詢性能瓶頸，所以考慮調研一下其它的NoSQL數(shù)據(jù)庫。

成都創(chuàng)新互聯(lián)公司-專業(yè)網站定制、快速模板網站建設、高性價比臨滄網站開發(fā)、企業(yè)建站全套包干低至880元,成熟完善的模板庫,直接使用。一站式臨滄網站制作公司更省心,省錢,快速模板網站建設找我們，業(yè)務覆蓋臨滄地區(qū)。費用合理售后完善，十多年實體公司更值得信賴。

一、為什么調研MongoDB?

圖1-1是DB-Engines2017年11月數(shù)據(jù)庫的排名統(tǒng)計，可以看到MongoDB總排名在第5，在NoSQL數(shù)據(jù)庫中排名第1。

圖1-1 DB-Engines2017年11月數(shù)據(jù)庫的排名統(tǒng)計

優(yōu)點：

  • 社區(qū)活躍，用戶較多，應用廣泛
  • MongoDB在內存充足的情況下數(shù)據(jù)都放入內存且有完整的索引支持，查詢效率較高
  • MongoDB的分片機制，支持海量數(shù)據(jù)的存儲和擴展

缺點：

  • 不支持事務
  • 不支持join、復雜查詢

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

二、壓測性能對比

1、準備條件

(1)MySQL 、MongoDB數(shù)據(jù)庫所在服務器硬件環(huán)境

表2-1 服務器硬件環(huán)境主要參數(shù)

(2)***的數(shù)據(jù)庫版本

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)數(shù)據(jù)庫表結構及索引

MongoDB索引為dateTime 且是唯一索引。我們實際測試使用的MongoDB數(shù)據(jù)結構及字段如圖2-1所示。

圖2-1 MongoDB數(shù)據(jù)表記錄示例

MySQL索引為DATETIME,PARTNER_ID,GOODS_ID,SCOPE且是唯一索引。我們實際測試使用的MySQL數(shù)據(jù)結構及字段如圖2-2所示。

圖2-2 MySQL數(shù)據(jù)表記錄示例

SQL語句根據(jù)datetime字段進行時間范圍的查詢

(4)連接池***連接數(shù)都設置為200個，SQL語句調到***

2、百萬、***別的下不同查詢量不同并發(fā)量的壓測結果

數(shù)據(jù)庫表中記錄數(shù)總量在百萬、***別的壓測數(shù)據(jù)及結果如表2-2所示。

表2-2 百萬、***別的壓測數(shù)據(jù)及結果

3、億級別的下不同查詢量不同并發(fā)量的壓測結果

數(shù)據(jù)庫表中記錄數(shù)總量在億級別的壓測數(shù)據(jù)及結果如表2-3所示。

表2-3 億級別的壓測數(shù)據(jù)及結果

壓測結果分析：

  • 當每次查詢數(shù)據(jù)量在500條時，無論表中數(shù)據(jù)總量千萬或者億級別，MySQL和MongoDB在100線程并發(fā)的情況下查詢性能相當，表現(xiàn)良好，平均響應時間在500ms以內，TPS在230左右。
  • 當每次查詢數(shù)據(jù)量在5000條時，表中數(shù)據(jù)總量為***別時，MongoDB在50線程并發(fā)情況下查詢性能不及MySQL 的一半，100線程并發(fā)情況查詢性能都很差，平均響應時間在4500ms左右，表中數(shù)據(jù)總量為億級別時，在50個及以上的并發(fā)情況下，MongoDB和MySQL性能都較差。

在本案例簡單數(shù)據(jù)模型下時間范圍內的等值查詢應用場景下，MongoDB在高并發(fā)條件下的大數(shù)據(jù)量查詢性能并沒有比MySQL更好。另外還有一點需要注意的是，在本案例中，數(shù)據(jù)總量由***別到***別再到億級別的變化過程中，對于查詢性能的影響都不是很大，但對于查詢數(shù)據(jù)量的數(shù)倍增長卻十分敏感，所以在考量數(shù)據(jù)庫查詢性能時，也要重點考量應用的單次查詢量的需求。

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

三、MySQL和MongoDB內存結構

1、InnoDB內存使用機制

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

圖3-1 InnoDB體系結構

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

innodb_buffer_pool_size指的是InnoDB緩沖池的大小，本例中InnoDB緩沖池大小為20G，該參數(shù)的大小可通過命令指定innodb_buffer_pool_size 20G。緩沖池使用改進的LRU算法進行管理，維護一個LRU列表、一個FREE列表，F(xiàn)REE列表存放空閑頁，數(shù)據(jù)庫啟動時LRU列表是空的，當需要從緩沖池分頁時，首先從FREE列表查找空閑頁，有則放入LRU列表，否則LRU執(zhí)行淘汰，淘汰尾部的頁分配給新頁。

innodb_read_ahead_threshold相對應的是數(shù)據(jù)預加載機制，innodb_read_ahead_threshold 30表示的是如果一個extent中的被順序讀取的page超過或者等于該參數(shù)變量的，InnoDB將會異步的將下一個extent讀取到buffer pool中，比如該參數(shù)的值為30，那么當該extent中有30個pages被sequentially的讀取，則會觸發(fā)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中沒有被訪問，而驅逐出內存的頁數(shù)。

可以看出來，MySQL的緩沖池機制是能充分利用內存且有預加載機制，在某些條件下目標數(shù)據(jù)完全在內存中，也能夠具備非常好的查詢性能。

2、MongoDB的存儲結構及數(shù)據(jù)模型

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

圖3-2 WiredTiger Engine的結構

WiredTiger Cache的實現(xiàn)原理圖如圖3-3所示。

圖3-3 WiredTiger Cache的實現(xiàn)原理圖

Wiredtiger的Cache采用Btree的方式組織，每個Btree節(jié)點為一個page，root page是btree的根節(jié)點，internal page是btree的中間索引節(jié)點，leaf page是真正存儲數(shù)據(jù)的葉子節(jié)點;btree的數(shù)據(jù)以page為單位按需從磁盤加載或寫入磁盤。

可以通過在配置文件中指定storage.wiredTiger.engineConfig.cacheSizeGB參數(shù)設定引擎使用的內存量。此內存用于緩存工作集數(shù)據(jù)(索引、namespace，未提交的write，query緩沖等)。

(2)數(shù)據(jù)模型

內嵌

MongoDB的文檔是無模式的，所以可以支持各種數(shù)據(jù)結構，內嵌模型也叫做非規(guī)格化模型(denormalized)。在MongoDB中，一組相關的數(shù)據(jù)可以是一個文檔，也可以是組成文檔的一部分。

圖3-4 內嵌文檔示例

內嵌類型支持一組相關的數(shù)據(jù)存儲在一個文檔中，這樣的好處就是，應用程序可以通過比較少的的查詢和更新操作來完成一些常規(guī)的數(shù)據(jù)的查詢和更新工作。

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

如果數(shù)據(jù)關系是一種一對一的包含關系，例如下面的文檔，每個人都有一個contact字段來描述這個人的聯(lián)系方式。像這種一對一的關系，使用內嵌類型可以很方便的進行數(shù)據(jù)的查詢和更新。

 
 
 
 
    
  
  
  
  
  1. {
    2. 
  
  
  
  
  2. ??”_id”: ,
    3. 
  
  
  
  
  3. ??”name”: “Wilber”,
    4. 
  
  
  
  
  4. ??”contact”: {
    5. 
  
  
  
  
  5. ???? “phone”: “12345678”,
    6. 
  
  
  
  
  6. ???? “email”: “wilber@shanghai.com”
    7. 
  
  
  
  
  7. ?? }
    8. 
  
  
  
  
  8. } 
    9.

如果數(shù)據(jù)的關系是一對多，那么也可以考慮使用內嵌模型。例如下面的文檔，用posts字段記錄所有用戶發(fā)布的博客。在這中情況中，如果應用程序會經常通過用戶名字段來查詢改用戶發(fā)布的博客信息。那么，把posts作為內嵌字段會是一個比較好的選擇，這樣就可以減少很多查詢的操作。

 
 
 
 
    
  
  
  
  
  1. {
    2. 
  
  
  
  
  2.  ?? “_id”: ,
    3. 
  
  
  
  
  3.  ?? “name”: “Wilber”,
    4. 
  
  
  
  
  4.  ?? “contact”: {
    5. 
  
  
  
  
  5.  ????”phone”: “12345678”,
    6. 
  
  
  
  
  6.  ????”email”: “wilber@shanghai.com”
    7. 
  
  
  
  
  7.  ??},
    8. 
  
  
  
  
  8.  ??”posts”: [
    9. 
  
  
  
  
  9.  ??{
    10. 
  
  
  
  
  10.  ????”title”: “Indexes in MongoDB”,
    11. 
  
  
  
  
  11.  ????”created”: “12/01/2014”,
    12. 
  
  
  
  
  12.  ????”link”: “www.linuxidc.com”
    13. 
  
  
  
  
  13.  ??},
    14. 
  
  
  
  
  14.  ??{
    15. 
  
  
  
  
  15.  ????”title”: “Replication in MongoDB”,
    16. 
  
  
  
  
  16.  ????”created”: “12/02/2014”,
    17. 
  
  
  
  
  17.  ????”link”: “www.linuxidc.com”
    18. 
  
  
  
  
  18.  ??},
    19. 
  
  
  
  
  19.  ??{
    20. 
  
  
  
  
  20.  ????”title”: “Sharding in MongoDB”,
    21. 
  
  
  
  
  21.  ????”created”: “12/03/2014”,
    22. 
  
  
  
  
  22.  ????”link”: “www.linuxidc.com”
    23. 
  
  
  
  
  23.  ??}
    24. 
  
  
  
  
  24.  ?]
    25. 
  
  
  
  
  25.  } 
    26.

根據(jù)上面的描述可以看出，內嵌模型可以給應用程序提供很好的數(shù)據(jù)查詢性能，因為基于內嵌模型，可以通過一次數(shù)據(jù)庫操作得到所有相關的數(shù)據(jù)。同時，內嵌模型可以使數(shù)據(jù)更新操作變成一個原子寫操作。然而，內嵌模型也可能引入一些問題，比如說文檔會越來越大，這樣就可能會影響數(shù)據(jù)庫寫操作的性能，還可能會產生數(shù)據(jù)碎片(data fragmentation)。

引用

相對于嵌入模型，引用模型又稱規(guī)格化模型(Normalized data models)，通過引用的方式來表示數(shù)據(jù)之間的關系。這里同樣使用來自MongoDB文檔中的圖片，在這個模型中，把contact和access從user中移出，并通過user_id作為索引來表示它們之間的聯(lián)系。

圖3-5 引用文檔示例

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

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

四、應用場景分析

1、MongoDB的應用場景

(1)表結構不明確且數(shù)據(jù)不斷變大

MongoDB是非結構化文檔數(shù)據(jù)庫，擴展字段很容易且不會影響原有數(shù)據(jù)。內容管理或者博客平臺等，例如圈子系統(tǒng)、存儲用戶評論之類的。

(2)更高的寫入負載

MongoDB側重高數(shù)據(jù)寫入的性能，而非事務安全，適合業(yè)務系統(tǒng)中有大量“低價值”數(shù)據(jù)的場景。本身存的就是json格式數(shù)據(jù)。例如做日志系統(tǒng)。

(3)數(shù)據(jù)量很大或者將來會變得很大

MySQL單表數(shù)據(jù)量達到5-10G時會出現(xiàn)明細的性能降級，需要做數(shù)據(jù)的水平和垂直拆分、庫的拆分完成擴展，MongoDB內建了sharding、很多數(shù)據(jù)分片的特性，容易水平擴展，比較好的適應大數(shù)據(jù)量增長的需求。

(4)高可用性

自帶高可用，自動主從切換(副本集)[[209973]]

不適用的場景

(1)MongoDB不支持事務操作，需要用到事務的應用建議不用MongoDB。

(2)MongoDB目前不支持join操作，需要復雜查詢的應用也不建議使用MongoDB。

2、關系型數(shù)據(jù)庫和非關系型數(shù)據(jù)庫的應用場景對比

關系型數(shù)據(jù)庫適合存儲結構化數(shù)據(jù)，如用戶的帳號、地址：

  • 這些數(shù)據(jù)通常需要做結構化查詢，比如join。這時候，關系型數(shù)據(jù)庫就要勝出一籌
  • 這些數(shù)據(jù)的規(guī)模、增長的速度通常是可以預期的
  • 事務性、一致性

NoSQL適合存儲非結構化數(shù)據(jù)，如文章、評論：

  • 這些數(shù)據(jù)通常用于模糊處理，如全文搜索、機器學習
  • 這些數(shù)據(jù)是海量的，而且增長的速度是難以預期的
  • 根據(jù)數(shù)據(jù)的特點，NoSQL數(shù)據(jù)庫通常具有***(至少接近)伸縮性
  • 按key獲取數(shù)據(jù)效率很高，但是對join或其它結構化查詢的支持就比較差

本文題目：從MySQL和MongoDB的對比，看SQL與NoSQL的較量
文章出自：http://www.5511xx.com/article/cdddejh.html