9

在尝试使用来自大约 50 亿个数据库的查询来运行数据库转储时，进度条时间似乎表明该转储不会在任何合理的时间（100 多天）内完成。查询似乎在大约 22 小时后以 0% 结束后也冻结了 - 之后的行是 metadata.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} } ] }"

我的最后几行输出是（键入，因为我还不能发布图像。）

[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

任何有助于提高性能的想法或任何想法为什么需要这么长时间？

4

1 回答 1

17

我刚刚遇到这个问题，问题mongodump是基本上不是很聪明。它正在遍历_id索引，这可能意味着大量的随机磁盘访问。对我来说，转储几个集合mongodump只是由于游标超时而崩溃。

此处也描述了该问题：https ://jira.mongodb.org/browse/TOOLS-845 。但是，这并没有真正提供“按设计工作”的出色分辨率部分。索引可能有一些有趣的地方，但我认为在我的情况下，它只是一个足够大的集合，磁盘访问量对于我可怜的小 Mac Mini 来说是非常艰苦的工作。

一种解决方案？关闭写入然后使用，这会顺序传递数据，如果您使用自定义字段（我是）--forceTableScan，这可能比使用索引更快。_id_id

文档有点粗略，但读起来好像正常mongodump行为可能是_id使用快照遍历索引，然后按查询过滤。换句话说，它可能是按_id顺序遍历所有 50 亿条记录，而不是按存储数据顺序（即随机）完成查询。因此，您最好构建一个从真实索引读取并直接写入的工具。

对我来说，--forceTableScan这就足够了，这意味着（a）它实际上成功完成，并且（b）它是一个数量级或更快的数量级。

于 2017-06-26T20:42:50.823 回答