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
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
