如何優化MongoDB以及其它資料庫?

來源:果殼範文吧 3.12W

我們知道做資料庫最重要的還是做好優化,那麼優化這兩個看似簡單,但是要怎麼做才好呢?下面小編就為大家分享下優化MongoDB以及其它資料庫的方法吧。

如何優化MongoDB以及其它資料庫?

Jared Rosoff 在 Scale Out Camp 發表了一篇簡潔、有效、有趣和令人信服的《8 分鐘 MongoDB 教程》描述瞭如何進行 MongoDB 優化。

文中的方法不僅限於 MongoDB,還可應用到絕大多數資料庫,比如查詢優化、找出你的熱資料、調整檔案系統、選擇正確的磁碟裝置、分片。下面分別對 5 種策略進行說明:

查詢優化:用 B-tree 搜尋的速度顯然比全表掃描來的快,所以你需要優化你的查詢語句。用 explain來分析你的查詢語句,如果返回的結果現實這個查詢用到了 cursor 那麼它會是一個全表掃描,也就是說它會非常慢。分析有多少條記錄會滿足查詢條件,以及查詢會執行多長時間。改進的方法就是為其增加索引。不管你是有 1 臺還是有 100 臺伺服器。

找出你的熱資料尺寸:在資料庫前面使用 Memcached 其實挺可笑的,因為現在記憶體很便宜,你可以使用大量的記憶體來快取資料庫內容,MongoDB 就是這樣乾的。熱資料 = 活躍記錄 + 使用過的索引。在記憶體中命中資料是非常快的,而從磁盤獲取資料就非常慢。假設你有上十億的使用者,但只有十萬使用者當前是活躍的,那麼你的熱資料尺寸就是十萬條。你需要規劃足夠的'記憶體來存放那十萬條熱資料,保證他們能夠從記憶體而不是磁盤裡讀取,別忘了索引也是需要佔用記憶體的。

調整檔案系統:效能問題往往根源是在檔案系統。比如 EXT3 已經過時了,請使用 EXT4、XFS 和其它高效能的檔案系統。對於資料庫來說並不需要每次訪問都去更新檔案,所以關掉檔案的訪問時間跟蹤功能,不然會有很多不必要的磁碟寫操作。在 EXT3 檔案系統預分配一個 2GB 大小的檔案是非常耗時的,因為它必須得在分配時完整初始化整個檔案。

選擇正確的磁碟裝置:尋道時間是需要關注的問題,因為大多數時候磁碟的 IO 操作是隨機的。尋道時間取決於機械臂在磁碟上來回移動的速度,磁碟的平均尋道操作能力是每秒鐘能完成 200 次。高速磁碟之所以讀取資料更快,是因為他們有更高的頻寬容量,除此之外他們的尋道時間並沒有區別。使用單個磁碟時,你可以獲得每秒 200 次尋道;而使用 RAID 0(跨多個磁碟),3 塊磁碟可以讓你獲得每秒 600 次的尋道速度;那麼使用 RAID 10(映象 + 跨越),6 塊磁碟甚至能讓你獲得每秒 1200 次尋道。所以要考慮用 RAID 來進行優化。如今的 SSD 儲存就更誇張了,一次尋道只要 0.1 毫秒,是機械磁碟的 50 倍,更適用於隨機的讀取操作。

分片:如果你的程式效能很差,索引又建的不正確,磁碟裝置的速度也很慢,那麼單點的效能也就非常差了。改善這種情況的方法就是用分片來做橫向擴充套件,分片可以讓你把系統負責分散到由更多機器組成的高可用的 replica sets 叢集。資料將會按一定範圍被切分成很多的區塊,然後橫向擴充套件到上百臺伺服器,上千次的寫操作在被拆分後每臺伺服器只需要處理十來次操作。分片讓橫向擴充套件變得容易。

熱門標籤