Forma 工程系列导读：面向 AI 的“可变结构”数据存储怎么做？AI 应用的数据结构变化速度，往往比传统数据库的建表/改表流程快得多：今天模型输出 12 个字段，明天变 30 个，下周又多出几个新字段——一旦数据库 schema 跟不上，轻则延迟飙升，重则直接线上事故

Sun, 01 Feb 2026 07:36:12 GMT

Forma 工程系列导读：面向 AI 的“可变结构”数据存储怎么做？

AI 应用的数据结构变化速度，往往比传统数据库的建表/改表流程快得多：今天模型输出 12 个字段，明天变 30 个，下周又多出几个新字段——一旦数据库 schema 跟不上，轻则延迟飙升，重则直接线上事故。

这篇导读介绍了 Forma 的核心思路：只存“实际存在”的字段，让 schema 随 AI 输出演进。作者用“小票”做类比：

• 传统 SQL 表像一张列出所有可能商品的固定格式小票，没买的也要打印 0；新增商品就得重印格式（=改表）。
• EAV（Entity-Attribute-Value）更像只列出你真正买了什么：薯片、可乐；新增字段就直接加一行（=无需 DDL）。

当然，EAV 一直被认为是“反模式”，因为查询性能和可维护性都很差。Forma 的目标是：在保留灵活性的同时，把性能与一致性补回来。

Forma 是什么：三件事组合起来

Forma 面向 AI 时代的存储引擎，核心组合是：

• EAV 模式：新增字段不需要 ALTER TABLE，天然适配快速迭代
• JSON Schema：把“AI 输出”变成可验证的数据契约（写入时校验），提升类型安全与可控性
• PostgreSQL + DuckDB：OLTP/OLAP 分工 + 热冷分层，在成本与性能之间取得平衡

系列要解决的三个典型问题

1. AI 数据结构迭代太快

传统 DDL 流程（提工单→审批→维护窗口→改表）跟不上。系列第 1 篇会讲：JSON Schema + EAV + Hot Table 如何实现“零 DDL、写入即生效、仍然类型安全”。

2. EAV 的 N+1 查询噩梦

EAV 读数据常见的问题是：查 100 条记录可能触发 101 次往返，延迟轻松破 1s。系列第 2 篇会讲用 PostgreSQL 的 CTE + JSON_AGG 把 101 次查询压到 1 次，把延迟从 ~1000ms 降到 ~25ms。

3. 海量历史数据下的一致性与“脏读”担忧

数据到十亿级后，热冷分层几乎不可避免，但工程上最怕的是：联邦查询时读到未提交/不一致的数据。系列第 3 篇会讲通过 Anti-Join + Dirty Set 机制，做到联邦查询“零脏读”。

按你的场景选择阅读顺序

• 做 AI 应用，需要灵活存储：从 Post 1 开始
• 被 N+1 性能拖垮，想快速降延迟：直接看 Post 2
• 数据增长、准备上热冷分层 / Lakehouse：看 Post 3
• 想系统理解整体架构：按 1→2→3 顺序读

原文链接：https://blog.ltbase.dev/posts/forma/00-introduction-en

#EAV #JSONSchema #PostgreSQL #DuckDB #Lakehouse

blog.ltbase.dev

Forma Engineering Blog Series: From EAV to Zero-Dirty-Read Lakehouse | Lychee Technology Engineering Blog

Three posts that explain a flexible data storage engine designed for the AI era

Lakehouse | 面条的草稿箱