SonnetDB 3.0：把八类数据能力收进一套 SQL

预计阅读时间：10 分钟

SonnetDB 3.0.0 的核心信息很直接：IoTSharp 团队把时序、关系表、键值、JSON 文档、全文检索、向量检索、对象存储和消息队列放进同一个数据库引擎，并通过同一套 SQL 与 API 暴露出来。对开发团队来说，这不是“少装几个软件”这么简单，而是数据建模、查询路径、运维边界都会被重新摆放。

多模型数据库真正想解决什么

很多系统一开始只有关系表，后来接入设备数据，需要时序库；做配置和会话状态，引入键值存储；做用户画像或事件载荷，又塞进 JSON 文档；需要搜索，就接 Elasticsearch；做 RAG 或相似度推荐，再补一个向量库；文件落对象存储；异步任务进消息队列。

这些组件各自都合理，但组合起来会出现几个典型成本：

数据复制链路变长：同一份业务事实要同步到多个系统。
查询语义分裂：SQL、DSL、SDK、消息协议各写一套。
一致性边界模糊：用户改了文档，搜索索引和向量索引什么时候可见？
本地开发和测试变重：开发者要启动一排依赖才能跑完整流程。

SonnetDB 3.0 的方向，是把八类能力收进一个引擎和一套 SQL/API。这个定位尤其适合 IoT、工业数据平台、设备资产管理、日志检索、轻量知识库这类“数据形态很多，但团队不想维护一组专用系统”的场景。

八合一不是把表名换个皮

“一个数据库支持多模型”最关键的不是宣传清单，而是查询边界是否真的变短。以 IoT 场景为例，一个设备通常同时有这些数据：

关系表：设备、租户、固件版本、权限。
时序数据：温度、电压、转速、告警计数。
JSON 文档：设备上报的非固定结构属性。
全文检索：日志、告警描述、工单备注。
向量检索：故障描述 embedding、文档片段 embedding。
对象存储：图片、报表、固件包、原始采样文件。
消息队列：采集、清洗、通知、异步任务。
键值：会话、开关配置、临时状态。

如果这些都在一个引擎里，开发者可以把“设备详情页”从跨系统拼装，变成更接近一次数据库侧聚合的工作。摘要没有披露 SonnetDB 3.0 的完整 SQL 方言细节，因此下面的例子按“可以这样实践”的方式给出，用来展示多模型统一后应用层可以如何组织查询，不等同于官方语法承诺。

可以这样实践：为设备平台设计一个统一查询入口

下面是一个可复制改造的最小 SQL 草案。假设数据库支持关系表、JSON 字段、全文索引、向量字段、对象引用和队列语义；实际落地时，需要把数据类型和索引语法替换为 SonnetDB 3.0 文档中的正式写法。

-- 假设示例：多模型设备数据的统一建模草案
-- 运行前请按 SonnetDB 3.0 实际 SQL 方言调整 VECTOR、JSON、OBJECT_REF、QUEUE 等类型。

CREATE TABLE devices (
  device_id      TEXT PRIMARY KEY,
  tenant_id      TEXT NOT NULL,
  name           TEXT NOT NULL,
  model          TEXT NOT NULL,
  firmware       TEXT NOT NULL,
  tags           JSON,
  last_seen_at   TIMESTAMP
);

CREATE TABLE telemetry_ts (
  device_id      TEXT NOT NULL,
  ts             TIMESTAMP NOT NULL,
  temperature    DOUBLE,
  voltage        DOUBLE,
  rpm            DOUBLE,
  PRIMARY KEY (device_id, ts)
);

CREATE TABLE device_logs (
  log_id         TEXT PRIMARY KEY,
  device_id      TEXT NOT NULL,
  ts             TIMESTAMP NOT NULL,
  level          TEXT NOT NULL,
  message        TEXT NOT NULL
);

-- 假设：全文索引
CREATE FULLTEXT INDEX idx_device_logs_message
ON device_logs(message);

CREATE TABLE knowledge_chunks (
  chunk_id       TEXT PRIMARY KEY,
  title          TEXT NOT NULL,
  content        TEXT NOT NULL,
  embedding      VECTOR(768)
);

-- 假设：向量索引
CREATE VECTOR INDEX idx_knowledge_embedding
ON knowledge_chunks(embedding);

CREATE TABLE device_objects (
  object_id      TEXT PRIMARY KEY,
  device_id      TEXT NOT NULL,
  kind           TEXT NOT NULL,
  uri            OBJECT_REF NOT NULL,
  created_at     TIMESTAMP NOT NULL
);

-- 假设：向队列写入采集任务
INSERT INTO ingest_queue(topic, payload)
VALUES (
  'telemetry.raw',
  JSON_OBJECT(
    'device_id', 'dev-001',
    'temperature', 38.5,
    'voltage', 220.1,
    'ts', '2026-07-08T10:00:00Z'
  )
);

再看查询侧。如果一个告警排查页面需要同时展示设备信息、最近 15 分钟指标、相关日志和相似知识片段，在多系统架构下通常要查关系库、时序库、搜索引擎和向量库。统一引擎后，可以把应用代码压薄：

-- 假设示例：一个设备排障页的数据查询草案
-- :device_id、:query_text、:query_embedding 由应用层传入。

SELECT
  d.device_id,
  d.name,
  d.model,
  d.firmware,
  d.tags,
  AVG(t.temperature) AS avg_temperature_15m,
  MAX(t.voltage) AS max_voltage_15m
FROM devices d
LEFT JOIN telemetry_ts t
  ON t.device_id = d.device_id
 AND t.ts >= NOW() - INTERVAL '15 minutes'
WHERE d.device_id = :device_id
GROUP BY d.device_id, d.name, d.model, d.firmware, d.tags;

SELECT log_id, ts, level, message
FROM device_logs
WHERE device_id = :device_id
  AND FULLTEXT_MATCH(message, :query_text)
ORDER BY ts DESC
LIMIT 20;

SELECT chunk_id, title, content
FROM knowledge_chunks
ORDER BY VECTOR_DISTANCE(embedding, :query_embedding)
LIMIT 5;

这类写法的价值不在于“SQL 更酷”，而在于应用服务可以保持一个清晰边界：请求进来，构造查询，返回组合后的排障视图。服务不再负责协调四五个客户端、重试策略和中间状态。

应用层可以更简单，但数据库设计不能偷懒

统一引擎会降低系统数量，但不会自动消除建模问题。反而因为数据类型变多，团队更需要给边界定规矩。

一个实际项目里，可以把数据按访问模式分层：

# 可以这样实践：多模型数据归属约定
# 文件名示例：data-ownership.yaml

models:
  relational:
    use_for:
      - tenant
      - device
      - user_permission
      - billing_plan
    rule: "需要强约束、可 JOIN、长期稳定的实体放这里"

  timeseries:
    use_for:
      - telemetry
      - metrics
      - counters
    rule: "高频追加写入，按时间窗口聚合"

  json_document:
    use_for:
      - flexible_device_profile
      - event_payload
    rule: "字段变化快，但仍要限制顶层结构和版本"

  fulltext:
    use_for:
      - logs
      - tickets
      - alarm_descriptions
    rule: "面向人类文本检索，不替代结构化过滤"

  vector:
    use_for:
      - knowledge_base_chunks
      - semantic_alarm_search
    rule: "用于相似度召回，结果仍需业务过滤和权限校验"

  object:
    use_for:
      - firmware
      - reports
      - images
      - raw_files
    rule: "数据库保存对象引用和元数据，文件生命周期要单独治理"

  queue:
    use_for:
      - ingestion_jobs
      - async_notifications
    rule: "消息处理要设计幂等键和重试策略"

  key_value:
    use_for:
      - feature_flags
      - runtime_cache
    rule: "适合短路径读取，不承载复杂查询"

这个 YAML 不是 SonnetDB 的官方配置，而是团队协作时很有用的“数据归属合同”。多模型数据库最怕被用成万能抽屉：什么都能放，最后什么都难查。

采用时先问四个问题

SonnetDB 3.0 这种八合一架构，对中小团队、边缘部署、IoT 平台和快速迭代产品有明显吸引力。少维护几个系统，意味着部署、监控、备份、权限和开发环境都会轻一些。

但落地前建议做一次小规模验证，而不是直接替换现有基础设施：

你的核心查询是否真的跨越多种数据模型？如果只是关系表，没必要为“可能会用到”引入复杂度。
写入峰值是否集中在时序或队列路径？需要压测追加写、批量写、过期清理和索引更新。
全文与向量结果是否满足业务质量？搜索相关性和向量召回要用真实数据评估。
运维能力是否覆盖备份、恢复、扩容、权限、审计和监控？一个引擎承载更多职责，故障影响面也会更大。

一个稳妥路线是从新模块开始：例如设备日志检索、轻量知识库、IoT 数据沙箱或内部排障平台。先让一条业务链路吃到“一套 SQL 查询多种数据”的收益，再决定是否把更核心的数据迁进去。