MongoDB on 姚玉亮的网络日志

GaussDB 与 MongoDB 在数据集服务中的选型与应用

Thu, 24 Jul 2025 10:30:00 +0800

全塞 MySQL，两个问题都来了

数据集管理服务要管的东西很杂。一头是数据集本身，属性规整：所属团队、可见性、版本号、文件大小、创建时间、计费字段，全是结构化的。另一头是数据集下挂的文档解析结果，高度半结构化：不同来源的 PDF 抽出来的字段千差万别，有的带 DOI，有的带基金项目，有的带表格数据，schema 根本统一不了。

一开始我们图省事，全塞进 MySQL，解析结果用 JSON 列存。结果两个问题都来了：JSON 字段上的查询，要么扫表，要么得靠生成列建索引，写起来很别扭；解析任务又经常要回写嵌套很深的字段（比如某个 chunk 的 embedding 状态），行锁竞争明显。

于是我牵头做了一次存储选型。

两类数据，两个库

原则说白了就一条：让合适的数据库干合适的事。

GaussDB（华为系兼容 PostgreSQL 的关系库，客户侧有信创要求）存核心元数据：数据集、版本、文件、任务、团队配额、计费流水。这部分强一致、要事务、要复杂 JOIN，关系库是正解。

MongoDB 存文档解析结果和中间态：原始文本切片、chunk 元数据、抽取出来的实体和三元组、向量化任务的进度文档。schema 多变、写多读少、嵌套深，文档模型天然契合。

向量本身不进这两个库，走专用的向量库（Milvus 类），MongoDB 只存 chunk 到向量 ID 的映射。

一边建外键，一边嵌文档

GORM 接 GaussDB 走的是 PostgreSQL 驱动，DSN 和 PG 几乎一致：

1
2
3
4
5
6
7


import "gorm.io/driver/postgres"

dsn := "host=gaussdb.internal user=dataset password=*** port=5432 " +
 "dbname=dataset sslmode=disable TimeZone=Asia/Shanghai"
db, err := gorm.Open(postgres.Open(dsn), &gorm.Config{
 Logger: logger.Default.LogMode(logger.Warn),
})

核心元数据模型严格建外键和唯一索引：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


type Dataset struct {
 ID int64 `gorm:"primaryKey;autoIncrement:false"` // Snowflake
 TeamID int64 `gorm:"not null;index:idx_team"`
 Name string `gorm:"size:128;not null"`
 Visibility string `gorm:"size:16;not null"` // private/team/public
 CurrentVer int `gorm:"not null;default:1"`
 Status string `gorm:"size:16;not null"`
 CreatedAt time.Time
 UpdatedAt time.Time
}

type DatasetVersion struct {
 ID int64 `gorm:"primaryKey;autoIncrement:false"`
 DatasetID int64 `gorm:"uniqueIndex:idx_ds_ver"`
 Version int `gorm:"uniqueIndex:idx_ds_ver"`
 Manifest string `gorm:"type:jsonb"` // 文件清单
 Comment string `gorm:"size:512"`
}

新建数据集和版本是一个事务，保证不会出现"有数据集没版本"的中间态：

1
2
3
4
5


err := db.Transaction(func(tx *gorm.DB) error {
 if err := tx.Create(&ds).Error; err != nil { return err }
 ver := DatasetVersion{DatasetID: ds.ID, Version: 1, Manifest: manifest}
 return tx.Create(&ver).Error
})

MongoDB 侧用官方驱动，文档结构按"一个源文档一个 Document"组织：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


type ParsedDoc struct {
 ID primitive.ObjectID `bson:"_id,omitempty"`
 DatasetID int64 `bson:"dataset_id"`
 FileKey string `bson:"file_key"`
 Chunks []Chunk `bson:"chunks"`
 Entities []EntitySnapshot `bson:"entities,omitempty"`
 Extras bson.M `bson:"extras,omitempty"` // 来源相关的杂项字段
 ParseState string `bson:"parse_state"`
 UpdatedAt time.Time `bson:"updated_at"`
}

type Chunk struct {
 Ordinal int `bson:"ordinal"`
 Text string `bson:"text"`
 VecID string `bson:"vec_id,omitempty"`
 Status string `bson:"status"` // pending/vectorized/failed
}

更新某个 chunk 的向量化状态不需要拉回整文档，用位置运算符：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


filter := bson.M{
 "_id": docID,
 "chunks.ordinal": ord,
}
update := bson.M{
 "$set": bson.M{
 "chunks.$.status": "vectorized",
 "chunks.$.vec_id": vecID,
 "updated_at": time.Now(),
 },
}
_, err := coll.UpdateOne(ctx, filter, update)

先说事务，再说三个坑

事务是我们第一个想清楚的点。MongoDB 4.0 以后支持多文档事务，但性能开销不小。跨库一致性我们没有追强一致：GaussDB 里的"数据集版本"是权威状态，MongoDB 里的解析进度只是附属状态。Mongo 写失败就靠 Temporal Worker 重试，最终一致即可，不值得为它引入分布式事务。

第一个坑是 GaussDB 的 PG 兼容性。绝大多数语法和 PG 14 一致，但某些扩展（比如 pg_trgm）客户环境里不一定装了。我们本来想在数据集名字上做模糊搜索，用 trigram 索引，最后改成把搜索字段同步到 ES，数据库只做精确过滤。

第二个坑是 MongoDB 的文档膨胀。Chunks 数组一直 append，单文档逼近 16MB 上限。后来把 chunk 拆成独立集合 doc_chunks，用 doc_id 关联，反而查询和并发更新都更顺。嵌套文档用着顺手，但会无限增长的数组要警惕。

第三个坑在连接池。Hertz 服务同时连两个库，初期 Mongo 池子开太大，连接数被打满。把 Mongo 的 maxPoolSize 压到 100，GaussDB 侧用 GORM 的 SetMaxIdleConns/SetMaxOpenConns 控制，再配合 KubeSphere 的资源限额，才稳下来。

后来

回头看，这两个库在这个服务里各管一摊：强一致、要事务、要报表的核心元数据给 GaussDB；schema 多变、写多读少、嵌套深的解析中间态给 MongoDB。选型比的从来不是"哪个数据库更先进"，而是把数据按访问模式切开，让每一类数据落在它最舒服的存储里。

封面图：Laenulfean / Flickr · CC BY-SA 2.0

Gin 中间件实战：JWT 认证与请求日志异步落盘 MongoDB

Thu, 23 Nov 2023 10:30:00 +0800

审计日志一条不能丢

宠物医疗 SaaS 的 B/S 版后端需要统一的认证和审计。所有 API 请求都要校验 JWT，把用户和医院上下文提取出来；同时合规要求所有请求日志落盘，请求方法、路径、参数、响应状态码、耗时、操作者，一样不能少，保留半年备查。

同步写日志会拖慢接口响应。日志结构嵌套深、量又大，放 MySQL 里查询和归档都别扭，我选了 MongoDB，通过 channel 异步写，不阻塞主请求。

把身份塞进 Context

JWT 中间件用 golang-jwt/jwt/v5，从 Authorization 头解析 token，校验签名和过期时间，再把用户 ID、医院 ID、角色注入 gin.Context，后面的 handler 直接取用：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36


type Claims struct {
 UserID int64 `json:"uid"`
 HospID int64 `json:"hid"`
 RoleCode string `json:"rol"`
 jwt.RegisteredClaims
}

func JWTAuth(signingKey []byte) gin.HandlerFunc {
 return func(c *gin.Context) {
 tokenStr := c.GetHeader("Authorization")
 if len(tokenStr) > 7 && tokenStr[:7] == "Bearer " {
 tokenStr = tokenStr[7:]
 }
 if tokenStr == "" {
 c.AbortWithStatusJSON(401, gin.H{"code": 401, "msg": "missing token"})
 return
 }

 claims := &Claims{}
 token, err := jwt.ParseWithClaims(tokenStr, claims, func(t *jwt.Token) (interface{}, error) {
 if _, ok := t.Method.(*jwt.SigningMethodHMAC); !ok {
 return nil, fmt.Errorf("unexpected signing method: %v", t.Header["alg"])
 }
 return signingKey, nil
 })
 if err != nil || !token.Valid {
 c.AbortWithStatusJSON(401, gin.H{"code": 401, "msg": "invalid token"})
 return
 }

 c.Set("uid", claims.UserID)
 c.Set("hid", claims.HospID)
 c.Set("rol", claims.RoleCode)
 c.Next()
 }
}

校验的时候要连签名算法一起校验，代码里那个 HMAC 断言就是干这个的，防 alg 混淆攻击。

channel 满了就写文件

日志中间件用 ResponseWriter 包装器捕获响应状态码和响应体大小，通过一个带缓冲 channel 把日志投递给后台 writer。

这里有个和埋点上报不一样的前提。埋点丢几条无所谓，审计日志一条不能丢。所以同样是非阻塞投递，channel 满时的动作不同：不丢弃，降级写本地文件。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65


type AccessLog struct {
 TraceID string `bson:"trace_id"`
 UserID int64 `bson:"user_id"`
 HospID int64 `bson:"hosp_id"`
 Method string `bson:"method"`
 Path string `bson:"path"`
 Query string `bson:"query"`
 ClientIP string `bson:"client_ip"`
 StatusCode int `bson:"status_code"`
 Latency time.Duration `bson:"latency"`
 ReqSize int `bson:"req_size"`
 RespSize int `bson:"resp_size"`
 ErrMsg string `bson:"err_msg,omitempty"`
 CreatedAt time.Time `bson:"created_at"`
}

type bodyWriter struct {
 gin.ResponseWriter
 size int
}

func (w *bodyWriter) Write(b []byte) (int, error) {
 n, err := w.ResponseWriter.Write(b)
 w.size += n
 return n, err
}

func AccessLogMiddleware(logCh chan<- *AccessLog, fallback *os.File) gin.HandlerFunc {
 return func(c *gin.Context) {
 start := time.Now()
 bw := &bodyWriter{ResponseWriter: c.Writer}
 c.Writer = bw

 c.Next()

 entry := &AccessLog{
 TraceID: c.GetString("trace_id"),
 Method: c.Request.Method,
 Path: c.Request.URL.Path,
 Query: c.Request.URL.RawQuery,
 ClientIP: c.ClientIP(),
 StatusCode: c.Writer.Status(),
 Latency: time.Since(start),
 ReqSize: int(c.Request.ContentLength),
 RespSize: bw.size,
 CreatedAt: start,
 }
 if uid, ok := c.Get("uid"); ok {
 entry.UserID = uid.(int64)
 }
 if hid, ok := c.Get("hid"); ok {
 entry.HospID = hid.(int64)
 }
 if len(c.Errors) > 0 {
 entry.ErrMsg = c.Errors.String()
 }

 select {
 case logCh <- entry:
 default:
 // channel 满，降级写本地文件，保证审计日志不丢
 json.NewEncoder(fallback).Encode(entry)
 }
 }
}

后台 writer 攒批写 MongoDB，用的是 BulkWrite：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32


func LogWriter(ctx context.Context, coll *mongo.Collection, ch <-chan *AccessLog) {
 batch := make([]mongo.WriteModel, 0, 200)
 ticker := time.NewTicker(500 * time.Millisecond)
 defer ticker.Stop()

 flush := func() {
 if len(batch) == 0 {
 return
 }
 _, err := coll.BulkWrite(ctx, batch)
 if err != nil {
 log.Printf("mongo bulk write error: %v", err)
 }
 batch = batch[:0]
 }

 for {
 select {
 case e := <-ch:
 m := mongo.NewInsertOneModel().SetDocument(e)
 batch = append(batch, m)
 if len(batch) >= 200 {
 flush()
 }
 case <-ticker.C:
 flush()
 case <-ctx.Done():
 flush()
 return
 }
 }
}

四个坑

第一个坑是请求体。最开始我直接把 c.Request.Body 读出来记日志，读完之后后续 handler 再读就是空的：body 是个流，读一次就没了。要用 io.NopCloser 加 bytes.Buffer 复制一份放回去。另外大 body 必须截断，只记前 1KB，不然日志体积很快失控。

第二个是敏感字段。密码、身份证、手机号不能明文进日志。我在序列化前对 query 和 body 里的 password、id_card、phone 做了掩码。这事必须在入口做，等数据入了库再补救就晚了，合规也不认。

第三个是 MongoDB 写入延迟。BulkWrite 攒到 200 条批量写，平时延迟很稳，但副本集发生主从切换时写入会短暂失败。flush 失败就把批次写回本地文件，一个补传任务定期扫描重放，保证审计数据最终不丢。

第四个是 JWT 的注销。JWT 无状态，token 在过期前没法主动作废。我们在 Redis 里维护黑名单：退出登录或改密码时把 jti 加进去，TTL 设成剩余有效期。代价是每个请求多一次 Redis 查询，我觉得值。

后来

这两个中间件后来成了我所有 Go Web 项目的基础组件。回头看，主流程都不难，难的全是边角：body 读完要放回，日志要异步但不能丢，token 要能注销，敏感字段要在入口脱敏。边角处理好了，才算能用。

封面图：Tawheed Manzoor / Flickr · CC BY 2.0