Mongodb 調校過程記錄

Mongodb




Mongodb簡介


  • NoSQL
  • 以json形式儲存資料
  • 效能高
    • 支援資料內部再嵌入資料
    • 索引可以讓搜尋更快速
      • 內嵌資料與陣列都可以成為索引
  • 豐富的查詢語言
    • 資料聚合
    • 文字搜索
    • 地理位置查詢


Mongodb的主機環境設定

以下主機環境都是以 Ubuntu 14.04

Mongodb預設建立起來的最大連線數只有819
所以如果只是單純建立起來之後沒去改設定的話
很容易造成
"connection refused because too many open connections mongodb"
這個錯誤
所以在啟動的時候可以多加 --maxConns這個參數並設定到適當數值

ex:
bin/mongod --auth --maxConns=640000 --dbpath ./db



註:

  • --dbpath 是指定資料庫檔案存放的地方
  • --auth 啟用驗證機制
  • --maxConns 最大連接數


但是 --maxConns 卻是跟主機的 ulimit -n 的值有關係

ulimit -n 預設最高好像是到1024或4096
若要再調高, 則需要做下列步驟

sudo vi /etc/security/limits.conf
在最底下新增
* soft nofile 64000
* hard nofile 64000
root soft nofile 64000
root hard nofile 64000













註:

  • * 無法套用到root
  • * 也可以改成自己常用的帳號, ex: ubuntu soft nofile 64000之類的


另外在
/etc/pam.d/common-session
/etc/pam.d/common-session-noninteractive
內的最底下都要加上
session required        pam_limits.so








建議在 /etc/profile 最底下新增 ulimit -HSn 64000





之後建議重新啟動, 這樣ulimit -n 就都會是64000了!

echo "262144" > /proc/sys/net/ipv4/tcp_max_syn_backlog
echo "2000000" > /proc/sys/net/ipv4/tcp_max_tw_buckets
echo "262144" > /proc/sys/net/core/netdev_max_backlog
vim /etc/sysctl.conf
net.core.somaxconn=32768
sysctl -p

Mongodb 效能問題

3.x版預設引擎是 WiredTiger
如果不是WiredTiger最好換到此搜尋引擎
wiredTiger可以避免collection-lock造成的問題
註:

  • 就是有人在寫相同的collection,其他人都不能讀；wiredTiger是document lock
  • 一筆一筆的資料就是document
  • Mongodb的collection 就好比是 MySQL的table


其實訣竅就是要建立 index
但是index也不是建立的越多越好
建立越多的index, 相對的, 寫入速度會越慢
所以要針對自己的 query 去建立 index

而且盡量所要查詢的欄位, 與要撈出的欄位, 都在index內!!
最好是單一個 operation都壓在 100ms 以下
當然, 越低越好!

其實可以透過 db.setProfilingLevel() 來紀錄哪些 operation是慢的
假設我們定義超過100ms就算慢的操作
可以設定 db.setProfillingLevel(1,100)
註:

  • 1代表只記錄效能比較差的操作
  • 100 代表 100ms

假設我只要找查詢動作超過 100ms 的語法

db.system.profile.findOne({op:'query',millis:{$gt: 100}})
然後便可以知道需要將哪些查詢語句做進一步的最佳化

那要如何查詢自己使用的 query 有沒有使用到 index呢?
使用 .explain()就可以看得出來

使用 .explain()會回傳一個物件






  • queryPlanner
    • queryPlanner模式下並不會去真正進行query語句查詢，而是針對query語句進行執行計劃分析並選出winning plan
  • explain.queryPlanner.namespace
    • 所查詢的 collection name
  • explain.queryPlanner.winningPlan
    • 查詢優化器針對該query所返回的最優執行計劃的詳細內容
  • explain.queryPlanner.winningPlan.stage
    • 最優執行計劃的stage, 這裡返回是FETCH, 可以理解為通過返回的index位置去檢索具體的文檔
  • explain.queryPlanner.winningPlan.inputStage
    • explain.queryPlanner.winningPlan.stage的child stage, 此處是IXSCAN, 表示進行的是index scanning
    • 如果是 COLLSCAN則是直接去從資料庫裡取, 而不是 index
所要做的就是不要出現 COLLSCAN, 最好都是 IXSCAN!

建立 index
db.collection.createIndex()

留言

張貼留言

這個網誌中的熱門文章

[MySQL] schema 與資料類型優化

圖片
選擇優化的資料類型 原則: 越小越好 因為會佔用最小的磁碟、記憶體與CPU快取。 越簡單越好 操作整數比操作字串代價低，因為字串排序規則 ex: 儲存ip應該用 unsigned int - 4 bytes, 用 varchar 會用到 15 bytes 儲存時間應該用 mysql 內建的時間類型 DATETIME, TIMESTAMP可以儲存相同資料：時間日期，精確到秒 TIMESTAMP 只用 DATETIME 一半的儲存空間，根據時區自動變化 TIMESTAMP 允許的時間範圍比 DATETIME 小很多 避免 NULL 在 innodb 上有單獨的 bit 儲存 null 值，但在 myisam，但還是盡量避免 整數類型 tinyint - 8 bits smallint - 16 bits mediumint - 24 bits int - 32 bits bigint - 64 bits 如果是有正負數的，會因為 1 bits 會用來記錄正負，故範圍為 -2^(n-1) ~ 2^(n-1) unsigned 的範圍則是 -2^n ~ 2^n MySQL 可以為整數指定寬度，例如 INT(11)，其實沒什麼意義，11只是表示與 MySQL 相關工具(client 端的 cli) 用來顯示的長度，對於儲存與計算來說，INT(1)與INT(20)是一樣的。 實數類型 decimal(M,N) - M: 最大位數, N: 小數點後有幾位 ex: decimal(18, 9) => 9位數字.9位數字，總共使用 9 個 bytes float => 4 bytes double => 8 bytes decimal的計算雖然比較精確，但需要額外，但需要額外的空間與計算開銷，資料量較大時，可以用 bigint 代替 decimal，假設需要精準到萬分之一，則可以將數字*1百萬，將結果存在 bigint 內，可以同時避免福點數計算不精準與 decimal 計算代價太高。 字串類型 VARCHAR row_format=fix，這樣就都會固定長度，沒意義 varchar會需要額外1~2 bytes記錄長度, 假設用 latin1 charset, varchar(10) => 11 bytes, varchar(1000) => 1002...
閱讀完整內容

[翻譯] 介紹現代網路負載平衡與代理伺服器

圖片
原文(Source): https://blog.envoyproxy.io/introduction-to-modern-network-load-balancing-and-proxying-a57f6ff80236 什麼是網路負載平衡 (network load balancing) 與 代理伺服器的代理行為 (proxying)? 維基百科是這樣定義負載平衡的 > 負載平衡藉由工作量分配到多台運算資源, 例如: 主機, 主機叢集, 網路連結, CPU,  硬碟等. > 負載平衡盡量最佳化資源的使用, 最大化每個最大化每個資源的吞吐量(生產能力), 最小化反應時間, 避免單一資源工作量過重 > 使用多個資源來當負載平衡來提升可靠與高可用而不是單一個資源 > 負載平衡總是使用獨立的軟體或硬體, 例如獨立的 multilayer switch, 或是 DNS主機的程式 上面的定義用於各資訊領域的各方面, 不單單只有網路而已. 作業系統使用負載平衡在實體處理器去分配運算任務, 容器編排服務像是K8S使用負載平衡在不同的主機叢集中去分配任務, 而網路負載平衡器則是將網路上進來的任務分配給可用的後端主機們. 剩下的文章主要都是講解關於網路負載平衡. 圖1 圖1展示了從應用層來看網路負載平衡. 許多的用戶端(Client)透過只需要向 load balancer 請求, load balancer就會將這些request, 也就是上述提到的任務分配給可用的後端服務. Load balancer位於Client 與後端之間執行幾個重要的任務: 服務發現 (Service discovery) 後端的服務在系統的哪裡, 他們的IP(位置)是什麼? (也就是load balancer該如何與後端主機溝通) 服務的狀態檢查 (Health checking) 現在的服務是否是可接受請求的 負載平衡 (Load Balancing) 該用什麼樣的演算法去平均將request分配給可用的服務 在分散式系統使用負載平衡主要有幾個好處: 主機抽象 (Naming abstraction): 每個client 不需要知道每個後端服務在哪, 只需要利用預先定義好的機制向負載平衡器...
閱讀完整內容