京公网安备11010502063487号实测哈希与 ranged 分片键的 chunk 分布:哈希键建集合时每个分片一个 chunk、连续键对半分(30,451 对 29,549),ranged 连续键 100% 在一个分片;随机键的 ranged 集合靠 balancer 分开;70% 文档同一个键值时哈希也救不了(85% 在一个 chunk);哈希键的等值查询 targeted,范围与 $in 多值 scatter-gather。
实测 mongos 路由:3 个分片上带分片键的等值/范围查询是 SINGLE_SHARD,跨段范围或 $in 多值或不含分片键是 SHARD_MERGE(问所有分片,各分片计数器各 +100);sort + limit 是 SHARD_MERGE_SORT,每个分片各返回 5 个再归并;9.0.2 上不带分片键的 update_one / delete_one 也能成功。
实测 zone sharding:给分片打 zone 标签并用 updateZoneKeyRange 声明键范围后,balancer 把 eu 的 8,000 个文档迁到 EU 分片、us 的留在 US 分片,没有 zone 的 apac 平均分到其它分片;chunk 在 zone 边界被切开;改 zone 后 us 的数据又跟着搬到新的分片。
实测分片集合上唯一索引的限制:非分片键的 unique 被拒(code 67);必须以分片键为前缀,但这样只保证同一个分片键值下唯一;_id 在分片键不是 _id 时可以在两个分片上重复;让唯一字段做分片键才能全局唯一;哈希分片键不能声明 unique(code 72),_id 哈希分片时 _id 实际全局唯一。
实测 3 分片集群上聚合 pipeline 的拆分:带分片键条件只命中相关分片、无 splitPipeline;$group 拆成分片上的部分分组 + 合并阶段的 $mergeCursors/$group(每个分片扫描 10,000 个文档只返回 50 个);$sort+$limit 把 limit 并进分片排序;$lookup/$merge 在 mergerPart;$sort 放在 $group 前面时耗时从 3.9 ms 变成 18 ms。
实测写入进行中的 mongodump:不带 --oplog 恢复后两个集合不在同一时间点(n − w = −623);--oplog 生成 oplog.bson(627 条 applyOps),--oplogReplay 重放 1254 个操作后 n == w;不带 --oplogReplay 恢复则 oplog.bson 被无提示忽略;--oplogLimit 取中间点会不一致;--oplog 只支持整库。
实测 profiler:默认级别 0、slowms = 100;阈值 100 ms 时 20 次全表扫描一条 Slow query 日志都没有,5 ms 时是 28 条(20 个 find + 8 个 getMore);级别 1/2 往 system.profile 写;system.profile 默认 1 MB capped,级别 2 的开销是 1.15 倍且 18,000 条操作只剩 4,280 条;sampleRate = 0.1 只记约 10%。
实测 $currentOp 与 killOp:另一个连接里的慢 find 能看到完整命令、planSummary 与 microsecs_running;killOp 之后 0.0 秒收到 11601 Interrupted(不杀要 2.6 秒),$where 的 sleep 与 $function 的 JS 循环都能打断;maxTimeMS = 1000 在 1.02 秒后以 50 MaxTimeMSExpired 中止;$currentOp 也会列出后台线程和它自己。
实测 serverStatus 里该盯的指标:opcounters 的增量(insert 记文档数,serverStatus 自己也算一次 command)、metrics.document 与 queryExecutor 的 scanned/scannedObjects(无索引 49,891 个文档 vs 有索引 499)、connections(每个 pymongo 客户端 3 个连接)、wiredTiger.cache 与 opLatencies。
实测 mongostat 与 mongotop:默认列的含义与空闲时的数值;对着每秒 300/100/50/20 的已知负载,mongostat 首行吻合、后面几行因采样窗口不对齐而偏差;-o 与 --json;mongotop 的 total/read/write;批量写入时 insert 约 31 万/秒、dirty 1.8% → 4.4%;以及 qrw/arw 与 serverStatus 对不上的现象。
实测 SCRAM 认证:--auth 下未认证 code 13、localhost 例外;system.users 里只存 salt/iterationCount/storedKey/serverKey(SHA-256 是 15000 次迭代);手写 saslStart/saslContinue 握手(2 条命令)并验证 storedKey;密码错与用户不存在返回同一个 code 18;角色授予回收立即对同一连接生效;SCRAM-SHA-256 认证约 3.4 ms。
实测 mongod 的连接与线程模型:连接数从 4 加到 1003,线程数 73 → 1072(一个连接一个线程),RSS 约 73 KB/连接,关闭后线程回落但 RSS 不回落;--maxConns 50 时 44 成功 16 被拒(connections.rejected、日志 Connection refused…);available 与 --maxConns 的关系;新建连接比复用慢 7.4 倍。