在R语言里接入MongoDB，最直接的做法是安装mongolite包。这个包不像早期的RMongo那样依赖Java，也不走HTTP REST接口，而是直接调用官方C驱动mongo-c-driver。正因如此，它在连接建立、认证、TLS握手和游标读取等网络IO环节上有明显性能优势，并且能够复用底层连接。安装后通过mongo()函数指定数据库和集合，后续的find、aggregate、insert等方法就能以类似本地数据框的方式操作文档数据。
一、连接解析：从URL到认证参数
mongo()的核心参数是collection、db和url。URL采用标准的MongoDB连接串格式，例如mongodb://ruser:rpass@127.0.0.1:27017/?authSource=admin，其中账号密码、主机端口、认证源都可以在串里直接声明。对于副本集和分片集群，连接串长度会增加，但mongolite会把这些参数交给底层驱动处理，R侧不需要额外解析。
实际连接时，建议不要在每次操作前重新创建mongo对象。对象创建开销不算大，但第一次网络请求会触发TCP建连和认证，频繁创建会让服务器日志里出现大量连接切换。一个脚本通常只需要在开头创建一个mongo对象，后续所有读写复用该对象即可。
library(mongolite) m = mongo( collection = "users", db = "appdb", url = "mongodb://ruser:rpass@127.0.0.1:27017/?authSource=admin" ) print(m$count())
认证源的选择是企业环境里最容易忽略的问题。MongoDB默认认证源通常与数据库同名，但使用Docker或云数据库时，账号可能创建在admin库下，此时需要在URL的查询参数中写authSource=admin。测试网络连通性可以用m$count()，它能返回集合文档数量，同时验证账号权限。对于网络延迟较大的服务器，创建对象后第一次调用可能会阻塞，这是底层驱动在选择可用节点，不能简单认为R脚本卡死。
二、数据框映射与嵌套文档处理
find最让人省心的一点是返回结果为data.frame。BSON文档的顶层字段会被映射为R向量，整型数值通常成为integer或numeric，日期成为POSIXct，而ObjectId会转换为字符串。嵌套文档和数组则不会默认展开，它们通常被序列化为JSON字符串放在某一列中。这种设计可以避免列类型混乱，但也要求开发者在后续分析时手动处理嵌套结构。
res = m$find(
query = '{"status": "paid"}',
fields = '{"_id": 0, "customer": 1, "amount": 1, "detail": 1}',
limit = 200
)
str(res)
if (nrow(res) > 0) {
detail = jsonlite::fromJSON(res$detail[1])
print(detail$address)
}
示例里先用fields参数裁剪返回字段，避免把无用的大字段拉到本地。取到的detail列仍然是JSON字符串，需要借助jsonlite::fromJSON解析成列表。这个解析过程发生在R进程内，不涉及网络IO，但对于几十万行数据来说，反复解析JSON会明显增加CPU负担。因此设计MongoDB文档时，建议把高频查询字段放到顶层，把低频展示内容放到嵌套对象中。
写入时，data.frame会被转换成BSON文档。日期列、因子列和字符串列基本能自动处理，但列表列需要格外小心，因为data.frame并不擅长表达混合类型。如果发现写入后的类型不符合预期，可以先在小表上做一次往返测试，再用str()查看R侧的列类型，与MongoDB Compass中的字段类型做对照。
三、查询、聚合与游标分页的网络行为
从网络IO角度看，find和iterate是两种完全不同的模式。find会把匹配结果一次性拉回R内存，适合几百到几万行的OLTP式查询；iterate则使用服务端游标，按批次返回数据，适合导出日志、构建训练集等结果集不可控的场景。如果盲目用find读取一张上千万行的集合，R会话很可能直接耗尽内存，即使内存够用，客户端接收窗口一旦填满，TCP层也会产生明显流量抖动。
it = m$iterate(query = '{"created_at": {"$exists": true}}')
chunk = it$batch(500)
while (!is.null(chunk)) {
print(paste("rows", nrow(chunk)))
chunk = it$batch(500)
}
游标方式的代码稍复杂一点：先拿到iterator对象，再通过batch方法按固定行数取数据，直到返回NULL。每一批数据都是一个完整的data.frame，可以在循环里直接处理。服务端会维持游标状态，客户端处理完一批后才请求下一批，这就是典型的需求拉动式IO，能够把内存峰值压到单批记录的大小。
聚合场景下，能用管道就不要把原始数据拉到R里做group_by。aggregate方法接收JSON格式的pipeline，数据库端完成筛选、分组、排序后再返回汇总结果，网络传输量往往只有原始数据的几十分之一。管道代码建议先在MongoDB Compass或mongosh里验证，确认语法正确后再嵌入R字符串，这样可以减少JSON转义导致的反复调试。
pipeline = '[
{"$match": {"status": "paid"}},
{"$group": {"_id": "$category", "total": {"$sum": "$amount"}}},
{"$sort": {"total": -1}}
]'
res = m$aggregate(pipeline)
print(res)
聚合管道的返回结果同样是一个data.frame。如果分组键包含中文或特殊字符，需要注意连接串和系统locale的编码设置，RStudio在Windows下偶尔会出现中文列名显示异常，但这不是mongolite本身的限制，而是R的字符编码环境问题。
四、网络IO调优：超时、压缩与连接复用
默认情况下，MongoDB驱动可能会因为网络分区或节点切换让客户端阻塞较长时间。对交互式R会话来说，这类挂起体验很差。推荐在URL查询参数中显式设置connectTimeoutMS、socketTimeoutMS和serverSelectionTimeoutMS。第一个控制TCP建连超时，第二个控制单次socket读写的最大等待时间，第三个控制副本集选主过程的时限。
m = mongo( collection = "logs", db = "appdb", url = "mongodb://127.0.0.1:27017/?connectTimeoutMS=5000&socketTimeoutMS=30000&compressors=snappy" )
压缩参数compressors=snappy可以显著降低文档冗余度较高的传输量，比如日志、爬虫文本和监控指标。它在服务端和客户端之间做透明压缩，R进程不需要处理任何压缩细节。网络带宽越小、文档字段重复越多，收益越明显。但压缩也会增加CPU消耗，如果MongoDB服务器CPU已经很紧张，可以改用zstd或暂时关闭压缩。
批量写入方面，insert支持pagesize参数，用来控制单次请求包含多少文档。较大的pagesize能减少往返次数，但会提高单次请求的内存峰值；较小的值更适合文档体积大或网络质量差的场景。最后，不要在lapply或for循环里反复创建mongo对象，同一个对象会复用底层socket；如果确实需要并行处理，应当让每个worker进程创建各自的连接，R的连接对象不能跨进程共享。