mysql迁移到mongodbshared架构的过程中踩到的一个坑
MySQL库中有一个表,数据量在10亿左右,基本上对于这个表的操作都是没有意义的,因此想测试一下迁移到MongoDB的shared架构上是否会有所改善。于是哼哧哼哧的搭建了一个3分片的mongo环境,并将mysql中这个大表的数据导出成了csv的格式,最终使用mongoimport工具成功将10亿多的数据导入mongo集群中去。但是导完后查看了下mongodb中对应的db的信息,差点没吓出尿来,请看:
创新互联公司长期为1000多家客户提供的网站建设服务,团队从业经验10年,关注不同地域、不同群体,并针对不同对象提供差异化的产品和服务;打造开放共赢平台,与合作伙伴共同营造健康的互联网生态环境。为麻山企业提供专业的成都做网站、网站设计,麻山网站改版等技术服务。拥有10多年丰富建站经验和众多成功案例,为您定制开发。
## 在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。
网页标题:mysql迁移到mongodbshared架构的过程中踩到的一个坑
文章转载:http://scyanting.com/article/pscojo.html