从自建MongoDB高效导出6500万条数据至BigTable的方案咨询

针对你要把6500万条（约200GB）MongoDB集合迁移到Google BigTable的需求，核心瓶颈确实卡在MongoDB的读取吞吐上——毕竟BigTable的高并行写入能力完全能跟上节奏。结合你已经尝试过的Node.js直接查询、mongoexport、mongodump方案，我整理几个更具针对性的优化思路，帮你把导出速度提上去：

一、先从MongoDB本身的读取配置挖潜力 #

• 调大游标批次大小：默认的查询游标batchSize太小，会导致频繁的磁盘/网络IO交互。不管用mongoexport还是mongodump，都可以加--batchSize 10000（甚至更高，根据单条文档大小调整），减少游标拉取数据的次数。另外，开启--noCursorTimeout避免长时间导出时游标超时，记得导出完成后手动关闭游标。
• 分片集群直接拆分分片导出：如果你的MongoDB是分片集群，直接针对每个分片节点单独导出，能并行利用所有分片的磁盘和CPU资源。先通过sh.status()找到每个分片对应的节点，然后在分片节点上跑导出命令，指定只拉取该分片的数据（或者直接用--dbpath读取本地数据文件，前提是能让分片短暂只读或停机）。
• 临时扩容MongoDB缓存：如果是单节点MongoDB，临时把wiredTigerCacheSizeGB调大到机器内存的70%左右（只要不影响其他关键服务），让更多数据缓存在内存里，减少磁盘IO的压力。调整后需要重启MongoDB，迁移完成后记得改回原配置。

二、并行导出的极致玩法 #

你提到mongodump比mongoexport快，但仍不够理想，那可以把并行策略拉满：

• 按数据范围拆分多进程导出：如果集合的_id是ObjectId（本身包含时间戳），或者有自增ID、时间戳字段，直接把数据分成N个区间，每个区间用一个独立的导出进程处理。比如用mongoexport拆分ObjectId区间的命令：

  mongoexport --db your_db --collection your_coll --query '{"_id": {"$gte": ObjectId("600000000000000000000000"), "$lt": ObjectId("610000000000000000000000")}}' --out part1.json
  

  多开几个终端跑不同的区间，把机器的CPU和磁盘IO充分利用起来（只要机器能扛住）。
• 离线读取数据文件：如果能接受短暂的停机，直接拷贝MongoDB的WiredTiger数据文件，然后启动一个临时的MongoDB实例（用mongod --dbpath指定数据目录），在这个实例上跑导出——本地读取数据文件的速度比通过网络查询快得多。这个方法适合能接受短时间服务中断的场景，或者用最近的磁盘快照来启动临时实例。

三、结合GCP生态的加速方案 #

既然你部署在GCP上，完全可以利用GCP的服务来突破单机器的瓶颈：

• 用Dataproc+Spark并行读取：创建一个Dataproc集群，用MongoDB Spark Connector读取数据，然后直接写入BigTable。Spark的分布式并行能力很强，能同时从MongoDB拉取多个分区的数据，而且Dataproc可以按需扩容机器（比如用c2-standard-32这种高CPU高IO的实例），迁移完成后销毁集群，成本可控。
• 多机器挂载快照并行导出：如果MongoDB部署在GCE实例上，先给磁盘打个快照，然后创建多个GCE实例挂载这个快照的磁盘，每个实例处理一个数据区间的导出——把磁盘IO压力分散到多台机器上，避免单机器的IO瓶颈。

四、关于mongodump的BSON文件解析问题 #

你不用担心mongodump导出的BSON文件解析难度，MongoDB官方提供了bsondump工具可以直接转换成JSON，而且大部分编程语言的MongoDB驱动都支持直接读取BSON文件（比如Python的pymongo用BSON.decode()，Spark也有BSON数据源）。反而BSON比JSON更紧凑，导出和传输的速度更快，是更高效的导出格式。

总结一下：优先尝试按范围拆分并行导出+调大batch size和缓存参数，如果还是达不到数小时的目标，就上Dataproc或者多机器并行读取快照，应该能把导出速度提上去。

内容的提问来源于stack exchange，提问作者polson136