mysql遷移到mongodb shared架構的過程中踩到的一個坑

    Mysql庫中有一個表，數據量在10億左右，基本上對于這個表的操作都是沒有意義的，因此想測試一下遷移到mongodb的shared架構上是否會有所改善。于是哼哧哼哧的搭建了一個3分片的mongo環境，并將mysql中這個大表的數據導出成了csv的格式，最終使用mongoimport工具成功將10億多的數據導入mongo集群中去。但是導完后查看了下mongodb中對應的db的信息，差點沒嚇出尿來，請看：

## 在mongos中查看db的信息，顯示遷移后的lens_mobapp_trace庫大小為1197.416GB
mongos> show dbs;
admin                 0.016GB
config                0.109GB
lens_mobapp_trace  1197.416GB
test                  0.031GB

    而我從mysql中導出的數據文件大小只有259GB，格式為csv，如下:

## 大小
$ ll -h 
total 259G
-rw-r--r-- 1 root root 259G Mar 25 16:27 NL_MOB_APP_ERROR_TRACE.txt
## 格式：逗號分隔的csv文件
$ head -2 NL_MOB_APP_ERROR_TRACE.txt 
"1551445226","2015-02-11 00:00:01","4613","5969","2","19796","1","5397","73","0","0","46000","4","0","499","2","903","1","-370443099","http://pingma.qq.com/mstat/report","nbfs://2015/2/11/4613/4613.0.txt?2444,2#93b"
"1551445229","2015-02-11 00:00:01","4611","7259","1","34","2","1038","71","48","4815","16","1","1482","412161","2","903","1","1429877488","http://api.mobile.cosmeapp.cn/cosmeapi","nbfs://2015/2/11/4611/4611.0.txt?38200,750#2c2"

    這259G的數據在mysql庫中的大小如下:

## 數據大小228GB
mysql> select sum(data_length)/1024/1024/1024 as size from information_schema.tables where table_name ='NL_MOB_APP_ERROR_TRACE' and table_schema='lens_mobapp_trace';
+-----------------------+
| size                  |
+-----------------------+
|     227.9790587359032 |
+-----------------------+
1 row in set (0.59 sec)
## 數據+索引總大小404GB
mysql> select sum(data_length+index_length)/1024/1024/1024 from information_schema.tables where table_name ='NL_MOB_APP_ERROR_TRACE' and table_schema='lens_mobapp_trace';
+-----------------------+
| size                  |
+-----------------------+
|     404.3463549343156 |
+-----------------------+
1 row in set (0.00 sec) 
## 記錄數
mysql> select count(*) from  NL_MOB_APP_ERROR_TRACE;
+------------------+
| count(*)         |
+------------------+
| 1079684226       |
+------------------+
1 row in set (23 min 18.06 sec)

    看到遷移到mongodb中數據量變為1197.416GB，一開始我是拒絕的，懷疑是加了特技，因為都說mongodb會預分配大文件用于存儲，于是到mongos上去看了看后端分片真實的存儲狀況

mongos> use lens_mobapp_trace
switched to db lens_mobapp_trace
## 這里只抽取一個分片來說明問題
mongos> db.stats();
{
    "raw" : {
               ........
        "udb-q12c20/10.6.14.38:27017" : {
            "db" : "lens_mobapp_trace",
            "collections" : 4,
            "objects" : 352321865,
            "avgObjSize" : 1005.7750069868641,
            "dataSize" : 354356526232,
            "storageSize" : 371299001584,
            "numExtents" : 711,
            "indexes" : 3,
            "indexSize" : 64238570368,
            "fileSize" : 437856239616,
            "nsSizeMB" : 16,
            "dataFileVersion" : {
                "major" : 4,
                "minor" : 5
            },
            "extentFreeList" : {
                "num" : 4,
                "totalSize" : 180224
            },
            "ok" : 1
        },
                 .......
}

    "objects" : 352321865                    ## 該分片上的記錄數

    "avgObjSize" : 1005.7750069868641        ## 每條記錄平均大小

    "dataSize" : 354356526232                ## 真實的數據大小

    "storageSize" : 371299001584             ## 數據大小+預分配表空間(2G)

    "indexSize" : 64238570368                ## 索引的大小

    "fileSize" : 437856239616                ## 整個數據文件的大小

    可以看到每條記錄在mongodb中占用約1k的空間，而在mysql中每條記錄的平均大小為227bytes，所以數據遷移到mongodb后數據會變的這么大。那么具體原因是什么呢？mongodb對插入的每一條記錄都會自動的添加一個唯一標識的字段_id,該字段大小為12bytes，還有就是mongodb每條記錄都會預留一些replace的空間用于記錄的更新操作，再有就是預分配功能也會占用一定的空間(最大為2GB)。mongodb和mysql對與表空間的管理是不同的，但是有一點是可以肯定的，那就是數據從mysql遷移到mongodb上數據是膨脹的。

    我們上面這個測試采用的版本是mongodb2.6.9。mongodb3.0之后對底層存儲做了改進，使用WiredTiger作為內建的存儲引擎，官方的說這一舉措能夠為MongoDB帶了文檔級鎖的并發控制和高效的文檔壓縮功能，且自身性能也有了重大的提升，提升MongoDB 7-10倍的寫操作性能、降低了80%的存儲占用空間、降低了高達95%操作開銷、支持高達50個副本集，好奇心的驅動，于是做了一個簡單測試，過程如下：mongodb采用WiredTiger引擎啟動，然后導入了5G的數據，最后查看導入后的數據大小。

## mongodb3.0.1采用WiredTiger引擎，啟動服務
mongod --dbpath=/data/db/ --logpath=/data/db/logs/mongodb.log --logappend --port=27017 -storageEngine wiredTiger --fork  >/dev/null
## 數據樣本大小
[root@manager opt]# ll -h xaa
-rw-r--r-- 1 root root 5.0G Apr 22 16:57 xaa
## 數據樣本記錄數
[root@manager opt]# wc -l xaa
21300000 xaa
## 數據樣本格式
[root@manager opt]# head -2 xaa
"1551445226","2015-02-11 00:00:01","4613","5969","2","19796","1","5397","73","0","0","46000","4","0","499","2","903","1","-370443099","http://pingma.qq.com/mstat/report","nbfs://2015/2/11/4613/4613.0.txt?2444,2#93b"
"1551445229","2015-02-11 00:00:01","4611","7259","1","34","2","1038","71","48","4815","16","1","1482","412161","2","903","1","1429877488","http://api.mobile.cosmeapp.cn/cosmeapi","nbfs://2015/2/11/4611/4611.0.txt?38200,750#2c2"

    采用mongoimport的方式導入mongodb，然后在庫中查看庫的大小和記錄數

## 庫中查看
> show dbs;
lens_mobapp_trace  2.847GB
local              0.000GB
> use lens_mobapp_trace
switched to db lens_mobapp_trace
> show collections;
NL_MOB_APP_ERROR_TRACE
> db.NL_MOB_APP_ERROR_TRACE.count();
21300000
## 查看文件系統中數據目錄的大小
[root@manager db]# ll -h 
total 2.9G
-rw-r--r-- 1 mongodb mongodb  16K Apr 22 22:28 collection-0-3862414736807305835.wt
-rw-r--r-- 1 root    root    2.7G Apr 22 23:03 collection-2-3862414736807305835.wt
-rw-r--r-- 1 mongodb mongodb  16K Apr 22 22:28 index-1-3862414736807305835.wt
-rw-r--r-- 1 root    root    185M Apr 22 23:03 index-3-3862414736807305835.wt
drwxr-xr-x 2 mongodb mongodb 4.0K Apr 22 23:03 journal
drwxr-xr-x 2 mongodb mongodb 4.0K Apr 22 22:26 logs
-rw-r--r-- 1 mongodb mongodb  32K Apr 22 22:31 _mdb_catalog.wt
-rwxr-xr-x 1 mongodb mongodb    5 Apr 22 22:27 mongod.lock
-rw-r--r-- 1 mongodb mongodb  36K Apr 22 23:05 sizeStorer.wt
-rw-r--r-- 1 mongodb mongodb   95 Apr 22 22:27 storage.bson
-rw-r--r-- 1 mongodb mongodb   46 Apr 22 22:27 WiredTiger
-rw-r--r-- 1 mongodb mongodb  495 Apr 22 22:27 WiredTiger.basecfg
-rw-r--r-- 1 mongodb mongodb   21 Apr 22 22:27 WiredTiger.lock
-rw-r--r-- 1 root    root     886 Apr 22 23:06 WiredTiger.turtle
-rw-r--r-- 1 mongodb mongodb  44K Apr 22 23:06 WiredTiger.wt

    看到這個結果不由得讓人欣喜，看來mongodb3.0之后，確實提升了很多，導入5GB數據，壓縮比在57%左右，如果導入較大的數據量的話，那么這個壓縮比應該是會有所提高，看來與官方說的80%出入不大，這個測試結果是不是又燃起了你對mongodb的信心？哈哈，看來是有必要學習一下3.0的新版本了，新技術層出不窮，it海中漂泊，唯有day day up。