|
|
@@ -51,10 +51,15 @@ find/export 示例：
|
|
|
|
|
|
**`SimCardManage`（SIM 卡，`_id` = GICCID 19位）关键字段**：
|
|
|
- `_id`（GICCID，19位）、`status`（UNKNOWN/NOT_ACTIVATED/ACTIVATED/DEACTIVATED/RETIRED）、`platform`（SmartHub/Acceleronix）
|
|
|
-- `allDataUsage`（累计用量字节）、`month`（yyyy-MM）、`expirationTime`、`updateTime`
|
|
|
+- `allDataUsage`（累计用量，**单位 KB**）、`month`（yyyy-MM）、`expirationTime`、`updateTime`
|
|
|
- 敏感字段（会被脱敏）：`imei`、`imsi`、`msisdn`
|
|
|
|
|
|
-**`SimCardMonthlyData`（SIM 月用量）**：`simId`(GICCID)、`month`、`allDataUsage`、`dailyUsage`。
|
|
|
+**`SimCardMonthlyData`（SIM 月用量）**：`simId`(GICCID)、`month`、`allDataUsage`（**单位 KB**）、`dailyUsage`。
|
|
|
+
|
|
|
+> **流量单位换算（写阈值必看）**：`allDataUsage`、`dailyUsage.dataUsage` 一律为 **KB**。
|
|
|
+> 换算：1 MB = 1024 KB，1 GB = 1048576 KB。
|
|
|
+> 常用阈值：**200MB = 204800**、500MB = 512000、1GB = 1048576、2GB = 2097152。
|
|
|
+> 因此"流量大于 200M"应写 `{"allDataUsage": {"$gt": 204800}}`，不要用 200 或 200000000。
|
|
|
|
|
|
#### JOIN 关系图谱（跨集合关联键）
|
|
|
|
|
|
@@ -87,6 +92,41 @@ find/export 示例：
|
|
|
{ "collection": "SiteInfoManageData", "pipeline": "[{\"$match\":{\"province\":\"Puerto Rico\"}}, ...]" }
|
|
|
```
|
|
|
|
|
|
+#### 配方：按 SIM 流量阈值反向筛出站点信息（如"流量 > 200M 的站点"）
|
|
|
+
|
|
|
+从 SIM 侧起点：先按用量过滤 SIM，再关联回站点，一步得到"高流量站点"清单。
|
|
|
+关键点：起点集合是 `SimCardManage`，用量阈值按 **KB**（200MB = 204800）；
|
|
|
+站点侧 `iccId` 前 19 位才等于 GICCID，故在 `$lookup` 的子 pipeline 里用 `$substrBytes` 对齐后再匹配。
|
|
|
+
|
|
|
+```json
|
|
|
+[
|
|
|
+ { "$match": { "allDataUsage": { "$gt": 204800 } } },
|
|
|
+ { "$lookup": {
|
|
|
+ "from": "SiteInfoManageData",
|
|
|
+ "let": { "giccid": "$_id" },
|
|
|
+ "pipeline": [
|
|
|
+ { "$addFields": { "siteGiccid": { "$substrBytes": ["$iccId", 0, 19] } } },
|
|
|
+ { "$match": { "$expr": { "$eq": ["$siteGiccid", "$$giccid"] } } },
|
|
|
+ { "$project": { "sn": "$_id", "province": 1, "city": 1, "activeStatus": 1 } }
|
|
|
+ ],
|
|
|
+ "as": "sites"
|
|
|
+ }},
|
|
|
+ { "$match": { "sites": { "$ne": [] } } },
|
|
|
+ { "$project": {
|
|
|
+ "giccid": "$_id", "allDataUsage": 1, "platform": 1, "simStatus": "$status",
|
|
|
+ "sites": 1
|
|
|
+ }}
|
|
|
+]
|
|
|
+```
|
|
|
+调用（pipeline 作为 JSON 字符串传入）：
|
|
|
+```json
|
|
|
+{ "collection": "SimCardManage", "pipeline": "[{\"$match\":{\"allDataUsage\":{\"$gt\":204800}}}, ...]" }
|
|
|
+```
|
|
|
+说明：
|
|
|
+- 阈值改其它值时按 KB 换算（见上面「流量单位换算」）。
|
|
|
+- 只关心站点、不关心 SIM 明细时，可在末尾加 `{"$unwind":"$sites"}` + `{"$replaceRoot":{"newRoot":"$sites"}}` 直接输出站点文档。
|
|
|
+- 只要计数（"有多少个这样的站点"）时，末尾用 `{"$unwind":"$sites"}` 后接 `{"$count":"siteCount"}`，不要把明细拉回上下文。
|
|
|
+
|
|
|
#### 配方：按州统计站点数与激活率
|
|
|
|
|
|
```json
|
|
|
@@ -102,6 +142,8 @@ find/export 示例：
|
|
|
|
|
|
#### 约束与反模式
|
|
|
|
|
|
+- **跨集合关联必须在库侧一步完成（硬约束）**：凡是"站点 ↔ SIM ↔ 月用量"之间的关联/条件筛选（如"流量>200M的站点""某州站点的SIM状态"），**必须**用 `data_mongo_aggregate` 的 `$lookup` 在数据库侧完成。**禁止**分别 `data_mongo_find`/`data_sim_*` 拉两张表的明细，再在 Agent 上下文里手工遍历、匹配、过滤——这会把大量数据灌入上下文导致膨胀/超时，正是要避免的反模式。
|
|
|
+- 若一次聚合难以表达，可先用 `$match`+`$group`/`$count` 在库侧收敛出**少量键**（如符合条件的 GICCID/SN 列表），再用该小列表做下一步；始终让"大数据量筛选"发生在数据库侧。
|
|
|
- **不要**用 `$project`/`$group` 把敏感字段（`contactNumber`/`imei`/`longitude` 等）**重命名**成新字段名或拼接进字符串——脱敏按字段名匹配，改名可能绕过脱敏，导致隐私外泄。保留敏感字段原名或直接不输出。
|
|
|
- `$lookup` 关联大集合时注意被关联集合的关联字段应有索引（`SimCardManage._id`、`SimCardMonthlyData.simId` 已有）。
|
|
|
- 只需计数/分组时优先 `$group`，不要把明细 `$push` 出来再在 Agent 侧数。
|
Jerry Liang