在尝试使用来自大约50亿个数据库的查询来运行数据库转储时,进度条时间似乎表明该转储不会在任何合理的时间(超过100天)内完成。查询似乎在0%处结束(大约22个小时后)后也冻结了–后一行是metas.json行。
转储行是:
mongodump -h myHost -d myDatabase -c mycollection --query "{'cr' : {\$gte: new Date(1388534400000)}, \$or: [ { 'tln': { \$lte: 0., \$gte: -100.}, 'tlt': { \$lte: 100, \$gte: 0} }, { 'pln': { \$lte: 0., \$gte: -100.}, 'plt': { \$lte: 100, \$gte: 0} } ] }"
Run Code Online (Sandbox Code Playgroud)
我的最后几行输出是(键入,因为我还不能发布图像。)
[timestamp] Collection File Writing Progress: 10214400/5066505869 0% (objects)
[timestamp] Collection File Writing Progress: 10225100/5066505869 0% (objects)
[timestamp] 10228391 objects
[timestamp] Metadata for database.collection to dump/database/collection.metadata.json
Run Code Online (Sandbox Code Playgroud)
是否有任何有助于提高性能的想法,或有关为什么要花这么长时间的想法?
我刚刚遇到了这个问题,问题mongodump是基本上不是很聪明。它遍历_id索引,这可能意味着很多很多随机磁盘访问。对我来说,转储多个集合mongodump只是由于游标超时而崩溃。
此处还描述了该问题:https : //jira.mongodb.org/browse/TOOLS-845。但是,这并不能真正提供“按设计工作”的出色分辨率。索引可能有一些有趣的地方,但我认为对于我来说,这只是一个足够大的集合,磁盘访问量对于我可怜的小Mac Mini来说是非常艰苦的工作。
一种解决方案?关闭写入,然后使用--forceTableScan,它将对数据进行顺序传递,_id如果您使用的是自定义_id字段(我过去),这可能比使用索引要快。
该文档有点粗略,但它的读取方式似乎是正常mongodump行为可能是_id使用快照遍历索引,然后按查询进行过滤。换句话说,它可能是按_id顺序而不是存储的数据顺序遍历所有50亿条记录,即随机遍历以完成查询。因此,您最好构建一个可以从真实索引读取并直接写入的工具。
对我而言,--forceTableScan就足够了,它意味着(a)它实际上成功完成了,并且(b)它是一个数量级或更快速。
| 归档时间: |
|
| 查看次数: |
3841 次 |
| 最近记录: |