在mysql 5.7中做邏輯備份恢復有了乙個新的工具mysqlpump，如果你掌握了mysqldump,那麼使用mysqlpump就是分分鐘的事情，因為很多引數都是很相似的，可以理解它是mysqldump的加強版，乙個亮點就是有了並行的選項，使得資料備份的效能更加強大。
有一點值得說明的是，為了保證資料一致性，我們一般備份都會使用--single-transaction的選項，在5.7.11以前，mysqlpump和並行引數是有衝突的，在這個版本之後做了修復。
但是mysqlpump到底怎麼樣呢，我在5.7.17的版本中做了一些簡單的測試，可以看出一些效能的差異。
為了盡可能保證匯出的資料備份能夠占用少的磁碟空間，我們經常會使用gzip來壓縮，我們就分了幾個場景來對比壓縮，不壓縮，開啟並行後的資料備份的效能差異。
我選取的資料集大小在30g左右。含有5個資料庫，單錶資料量在200萬以上，單庫的表數量在10個以上。
得到的乙個基本測試結果如下，後續的測試結果會一併補上。
optionrealidle%dump_size(byte)
compress=false
6m52.232s
85.92
26199028017
compress=false|gzip
43m12.574s
90.72
12571701197
compress=true
19m24.541s
80.48
26199028017
compress=true |gzip
43m12.515s
84.94
12571200219
parallelism=4
5m30.005s
76.43
26199028017
parallelism=4 |gzip
42m41.433s
90.51
12575331504
parallelism=8
4m44.177s
66.73
26199028017
可以看到預設來說，匯出乙個30g左右的dump需要近7分鐘，而啟用了並行之後，並行度為4的時候，匯出時間是5分半，提公升了1.5分鐘（20%），並行度為8之後提公升了2分鐘左右（30%）。而在系統層面做了壓縮的時候，壓縮率達到了近48%。還是相當不錯的。在compress=true只是在服務端客戶端互動中使用資料報壓縮，最後的備份集大小是沒有任何改變的。後續會測試使用不同的壓縮演算法，備份的效能差異。
R對MongoDB的效能測試 RMongo
在九月初的時候，rmongodb正式發布了修訂版本，這也就意味著，從事數值計算的語言也可以於nosql產品相接軌了，但是鑑於我身邊並沒有公司真的在使用r和mongodb的結合，所以在效率問題上，我們也不敢掉以輕心，所以就做了乙個這樣的測試。測試環境是8核，64位機。用於測試的庫是乙個未經shardi...
R對MongoDB的效能測試 RMongo
在九月初的時候，rmongodb正式發布了修訂版本，這也就意味著，從事數值計算的語言也可以於nosql產品相接軌了，但是鑑於我身邊並沒有公司真的在使用r和mongodb的結合，所以在效率問題上，我們也不敢掉以輕心，所以就做了乙個這樣的測試。測試環境是8核，64位機。用於測試的庫是乙個未經shardi...
R語言 理解R效能
通過了解限制r計算效能的因素，從而更好的利用起r的效能，影響r的因素 cpu,ram,磁碟i o,演算法。所以，當資料量小時，計算複雜度高，會受到cpu影響。資料量大時，會受到磁碟i o還有ram的影響。r是解釋型語句，即每次執行r程式的時候，r 需要重新解釋翻譯成機器 即使 不變。因為每次執行時，...