mysql迁移mongodb_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。