SonnetDB 3.1.0：一套引擎管理八类工业数据模型

SonnetDB 3.1.0 正式发布，覆盖自 v3.0.1 以来、截至 2026 年 8 月 24 日合入的 200 多次提交。与单纯增加一种存储能力不同，这次升级把重心放在多模型管理、工业协议接入、关系 SQL、查询规划、文档易用性、语义内容、存储可靠性和可观测性上，继续推进“八种数据模型，一套引擎”的产品路线。

对工业系统开发者而言，这条路线的价值并不只是减少数据库数量。真正值得关注的是：时序、关系表、键值、JSON 文档、全文检索、向量检索、对象存储和消息队列，能否在统一的管理、查询和运维边界内协同工作。

八种模型对应的是八类工程问题

工业数据很少只有一种形态。一条生产线可能同时产生设备测点、告警事件、工单、说明书、图片、日志和实时消息。强行把这些内容塞进同一种结构，往往会让查询、索引和数据生命周期管理变得复杂。

SonnetDB 所覆盖的八种模型可以分别承担不同职责：

统一引擎的潜在收益是减少数据在不同系统之间复制和同步的次数。例如，设备告警可以进入消息队列，原始报文保存为 JSON 文档，关键指标写入时序模型，附件进入对象存储，维修说明再通过全文或向量检索被找到。

但“统一”不能自动消除模型差异。团队仍然需要确认跨模型查询是否具有明确的一致性语义、不同索引如何占用资源、备份能否覆盖所有模型，以及权限是否能细化到模型和数据集。3.1.0 对存储可靠性与可观测性的升级因此很关键，因为多模型平台的故障面通常比单一数据库更宽。

3.1.0 的重点不止是增加入口

本次发布完成了多模型管理工作台的系统升级。对于同时维护多类数据的团队，工作台是否能统一呈现数据集、容量、查询和运行状态，会直接影响排障效率。它应当被视为运维入口，而不只是功能展示页面。

工业协议接入则解决数据进入系统的问题。现场设备通常不会直接发送标准 SQL 或 JSON，请求可能来自 PLC、网关或工业采集程序。协议接入能力增强后，评估重点应放在断线重连、重复数据、乱序时间戳、设备身份映射和背压处理上，而不是只验证“能够收到一条数据”。

关系 SQL 与查询规划的升级也值得单独测试。SQL 能否执行只是基础，规划器能否选择合理索引、控制扫描范围并稳定处理多表查询，才决定它能否承担生产负载。升级后应重新采集关键查询的执行计划，避免沿用旧版本的性能结论。

Document 易用性与语义内容升级，说明 JSON 文档、全文检索和向量检索之间的工作流正在得到加强。这里适合承载设备说明书、故障案例、维修日志等非结构化数据，不过向量召回仍然需要关键词过滤、权限检查或人工确认，不能直接替代故障诊断规则。

可以这样设计一个多模型数据流

下面是一个可直接保存并检查的 YAML 示例，用来描述工业数据如何分配到八种模型。它是架构配置示例，并非 SonnetDB 3.1.0 官方配置格式；接入时需要按照实际驱动、协议和字段定义改造。

version: 1
site: factory-a

sources:
  - name: line-1-gateway
    protocol: industrial-protocol
    endpoint: tcp://192.0.2.10:9000
    reconnect_seconds: 5

routes:
  telemetry:
    model: time_series
    timestamp_field: collected_at
    tags: [site_id, line_id, device_id, metric]
    value_field: value

  device_registry:
    model: relational
    primary_key: device_id

  current_state:
    model: key_value
    key_template: "device:{device_id}:state"

  alarms:
    model: document
    id_field: alarm_id

  maintenance_logs:
    model: full_text
    fields: [title, description, resolution]

  manual_chunks:
    model: vector
    text_field: content
    metadata_fields: [device_type, manual_version]

  inspection_images:
    model: object
    key_template: "{site_id}/{device_id}/{captured_at}.jpg"

  alarm_events:
    model: queue
    topic: industrial.alarms

reliability:
  reject_missing_timestamp: true
  deduplication_key: event_id
  dead_letter_topic: industrial.dead-letter

observability:
  metrics_enabled: true
  slow_query_threshold_ms: 500
  trace_ingestion: true

保存为 industrial-data-flow.yaml 后，可以使用 Python 检查 YAML 是否能被正确解析。运行前安装 PyYAML：

python -m pip install pyyaml
python - <<'PY'
from pathlib import Path
import yaml

path = Path("industrial-data-flow.yaml")
config = yaml.safe_load(path.read_text(encoding="utf-8"))

models = {route["model"] for route in config["routes"].values()}
expected = {
    "time_series", "relational", "key_value", "document",
    "full_text", "vector", "object", "queue"
}

missing = expected - models
if missing:
    raise SystemExit(f"missing models: {sorted(missing)}")

print(f"site={config['site']}, routes={len(config['routes'])}")
print("models=" + ",".join(sorted(models)))
PY

这份配置把数据模型选择显式化，也为后续评审提供了具体问题：原始遥测是否需要同时归档为对象、告警文档与队列事件如何去重、向量内容如何关联手册版本、消息消费失败后是否进入死信主题。

升级前应做一轮跨模型验收

从 v3.0.1 或更早版本迁移到 3.1.0，不宜只执行启动检查。200 多次提交意味着行为变化的覆盖面较大，建议围绕真实业务链路建立验收清单：

1. 备份并验证恢复流程，确保八类模型中的实际数据都被覆盖。
2. 对核心关系 SQL 保存执行计划和延迟基线，升级后进行对比。
3. 回放包含重复、乱序、缺失时间戳和断线重连的工业协议数据。
4. 验证 JSON 文档字段兼容性，以及全文、向量索引的重建时间。
5. 检查对象上传失败、队列消费积压和磁盘空间不足时的告警。
6. 对多模型工作台执行最小权限测试，避免运维入口扩大数据可见范围。
7. 在影子流量或小规模设备组中观察一段时间，再逐步扩大写入量。

SonnetDB 3.1.0 的核心看点，是把工业数据常见的八类存储需求放进一套引擎和管理体系。它可以减少技术栈碎片，但不能免除数据建模、容量规划、一致性验证和故障演练。采用时应从一条可观测、可回滚的数据链路开始，用真实查询和现场异常验证统一平台的边界，再决定是否扩大承载范围。