跳至主要内容

状态转换器FST是什么,如何实现es的term存储的


## 一、FST 是什么


**FST(有限状态转换器)** 是一种**带输出的有限状态自动机**(Finite State Automaton, FSA),它的主要作用是:


> **在保持词典查找功能的同时,压缩存储空间,并为每个 term 映射一个输出值(通常是倒排表的地址或 ID)。**


简单理解:


| 传统方式                        | FST               |

| --------------------------- | ----------------- |

| 一条条存 term → 对应 posting list | 构建紧凑状态机,共享前缀与后缀路径 |

| 查找时 O(logN) 树搜索             | 查找时 O(L)(term长度)  |

| 存储量大                        | 存储压缩(常减半以上)       |


---


## 二、FST 的作用(在 ES 中)


在 **Elasticsearch / Lucene** 的倒排索引中:


* 每个字段会构建一个 **Term Dictionary**(词典);

* 词典需要支持:


  * term → postings list offset 的查找;

  * term range 查询(前缀匹配、范围扫描);

  * 高效存储(因为 term 数可能是千万级)。


Lucene 使用 **FST** 来压缩这个词典:


* 将所有 term(有序)构造成一棵状态机;

* 每个节点表示一个字符状态;

* 每个路径(从根到叶)代表一个 term;

* 每条边上可以携带一个 **输出值(output)**,比如 term 对应的倒排文件偏移量。


举个例子(简化):


```

Terms:

  cat -> 1

  car -> 2

  dog -> 3

```


构建 FST:


```

(root)

 └─ c ─ a ─ ─┬─ t [1]

              └─ r [2]

 └─ d ─ o ─ g [3]

```


可以看到前缀 "ca" 被**合并共享**了。


---


## 三、为何 FST 压缩率高


因为自然语言词汇中前缀(或后缀)相似度很高(如 “compute”, “computer”, “computing”),

FST 通过**共享路径**避免重复存储,从而压缩数据。


此外,Lucene 的实现使用了:


* **最小化(minimized)有向无环图 DAG**;

* **字典序输入构建算法**(构建过程中状态可直接复用);

* **delta 编码**和**VarInt 编码**进一步节省空间。


---


## 四、FST 如何用于 term 查找


查找一个 term(例如 `"cat"`)时:


1. 从 root 开始,依次读取每个字符;

2. 按照边的字母匹配转移;

3. 到达终止状态时输出对应的倒排偏移;

4. 若中途无边可转移,则说明 term 不存在。


查找复杂度是 **O(L)**(term 的长度),与 term 总数无关,性能非常稳定。


---


## 五、ES/Lucene 实现简要说明


在 Lucene 源码中(`org.apache.lucene.util.fst`):


* 核心类:


  * `FST<T>`:通用的有输出有限状态机;

  * `Builder<T>`:用于从 term 列表构建最小化 FST;

  * `PositiveIntOutputs`、`ByteSequenceOutputs`:定义输出值类型;

  * `Util.get()`:用于 term 查找。


Lucene 的 FST 主要应用在:


* `Lucene50PostingsFormat` → Term dictionary;

* `Suggest` 模块 → 前缀自动补全;

* 某些内部索引结构(如 norms、doc values 的前缀压缩)。


---


## 六、一个简单的 Go 实现示例(演示思想)


虽然 Lucene 的 FST 很复杂,但可以在 Go 中模拟一个**最小自动机构建**思路:


```go

package main


import (

    "fmt"

)


type Node struct {

    edges map[rune]*Node

    output int

    isFinal bool

}


func NewNode() *Node {

    return &Node{edges: make(map[rune]*Node)}

}


// 简单构建前缀共享树(非最小化 FST)

func Insert(root *Node, term string, value int) {

    node := root

    for _, ch := range term {

        if node.edges[ch] == nil {

            node.edges[ch] = NewNode()

        }

        node = node.edges[ch]

    }

    node.isFinal = true

    node.output = value

}


func Search(root *Node, term string) (int, bool) {

    node := root

    for _, ch := range term {

        next := node.edges[ch]

        if next == nil {

            return 0, false

        }

        node = next

    }

    if node.isFinal {

        return node.output, true

    }

    return 0, false

}


func main() {

    root := NewNode()

    Insert(root, "cat", 1)

    Insert(root, "car", 2)

    Insert(root, "dog", 3)


    if v, ok := Search(root, "car"); ok {

        fmt.Println("Found:", v)

    }

}

```


这只是 FST 的雏形:


* 实际实现会做 **状态最小化**、**压缩序列化**,甚至存储在磁盘上(如 `.tim` 文件)。


---


## 七、总结


| 项目        | 说明                                               |

| --------- | ------------------------------------------------ |

| 名称        | FST(Finite State Transducer)有限状态转换器              |

| 主要用途      | 压缩 term dictionary(词典),映射 term → postings offset |

| 优点        | 高压缩率、快速查找、支持范围扫描                                 |

| 在 ES 中的位置 | Lucene 底层的 `.tim` 文件(Term Dictionary 部分)         |

| 查找复杂度     | O(term 长度)                                       |




此博客中的热门博文

Elasticsearch 读写原理指南

### 1. 什么是 segment,里面装了什么? 在 Lucene(也是 Elasticsearch)里,索引被切分成若干 **segment(段)**,每个 segment 是一个完整的、只读的倒排索引单元。一个 segment 包含: * **倒排词典** —— 用 **FST(Finite‑State Transducer)** 以高度压缩的形式保存每个字段出现的所有 term 以及 term→ord 的映射。对应的磁盘文件是 `*.tim`(新版)或 `*.tis/*.tii`(旧版)。 * **倒排列表(postings)** —— 保存每个 term 出现的文档 ID、频次、位置信息等,文件名通常是 `*.doc`、`*.pos`、`*.pay`。 * **存储字段**(_source、store:true 的字段)—— 以二进制块的形式写入 `*.fdt` / `*.fdx`。 * **doc‑values、norms、向量** 等辅助结构,分别保存在 `*.dv`、`*.norm`、`*.tv` 等文件里。 * **deleted‑docs bitmap**(`*.del`),标记哪些文档已被删除或被更新。 所有这些文件在 segment **写入磁盘后即成为只读**,后续的查询只能读取,永远不会在原文件上进行增删改。 --- ### 2. 原始文档和 FST 为什么都在 segment 里? * **原始文档**:Elasticsearch 默认把完整的 JSON(_source)以及任何 `store:true` 的字段写入 segment 的 `*.fdt/*.fdx` 文件。每个 segment 保存自己的那部分文档,旧的 segment 在合并前仍然保留,直到合并后被删除。 * **FST**:每个字段的词典在每个 segment 中单独维护,采用 FST 进行前缀共享和字节压缩。这样即使同一个 term 在多个 segment 中出现,也会在每个 segment 里拥有独立的映射,查询时只需要在对应 segment 的 FST 中定位即可。 --- ### 3. 查询时到底是怎么遍历 segment 的? 1. **请求入口**      客户端的搜索请求先到达 **协调节点**,协调节点把请求 ...

LLM缓存详解

 可以把“大模型缓存”理解成: 把已经算过的结果(或中间结果)存下来,下次尽量复用 。但这里面其实分几层,不只是简单的“问题→答案”缓存。 1️⃣ 常见的几种缓存类型 (1)KV Cache(推理内部缓存) Transformer 在生成时,会把前面 token 的 Key/Value 向量 缓存下来。 本质:避免重复计算 attention 作用: 同一请求内部加速 特点: 👉 只对“同一上下文继续生成”有效 👉 不跨用户、不跨请求 这类缓存是你体感“流式输出越来越快”的原因之一。 (2)Prompt Cache(提示词缓存) 缓存的是: 相同(或高度相似)的 prompt → 对应的中间表示 / 输出 典型场景: 系统提示词(system prompt)很长 多轮对话里前文基本不变 👉 这里能省掉 前缀计算成本(prefill) (3)Embedding / 语义缓存(Semantic Cache) 这个才是你问题的关键 👇 不是按“字符串完全一致”,而是: 把问题转成向量 → 找“语义相似”的历史问题 → 直接复用答案 2️⃣ 为什么命中缓存成本低很多? 因为大模型推理成本主要在两块: (1)Prefill(吃 prompt) 复杂度 ~ O(n²) 很贵(尤其长 prompt) (2)Decode(逐 token 生成) 每个 token 都要算一遍模型 而缓存命中后: KV cache:不用重复 attention Prompt cache:不用重新 encode 语义缓存: 直接跳过模型推理 👉 相当于从: 几十~几百毫秒 + GPU算力 变成: 一次向量检索(毫秒级)+ 直接返回 所以成本差一个数量级是正常的。 3️⃣ “每个人问法不同,怎么命中缓存?” 这是核心难点,也是工程重点👇 ❌ 不能靠字符串匹配 比如: “今天天气怎么样” “今天外面热不热” 字符串完全不同 → 必须 miss ✅ 用语义相似度(Embedding) 流程一般是: 把问题转 embedding(向量) 在向量数据库里找 TopK 相似问题 如果相似度 > 阈值(比如 0.9) 直接返回缓存答案 一个简单示意 Q1: 北京天气怎么样 → embedding A Q2: 北京今天热吗 → embedding B cosine(A, B) ≈ 0.95...

事务的ACID是什么

 事务的 ACID 是数据库事务必须满足的四个基本性质,用来保证在并发和故障情况下数据的正确性与可靠性: A(Atomicity,原子性) 一个事务中的操作要么 全部成功 ,要么 全部失败回滚 ,不存在“只做了一半”的中间状态。 C(Consistency,一致性) 事务执行前后,数据库都必须处于 一致的合法状态 ,满足约束(如主键、外键、唯一性、业务规则等)。 I(Isolation,隔离性) 并发执行的多个事务之间 相互隔离 ,一个事务未提交的中间结果对其他事务不可见(具体强弱由隔离级别决定)。 D(Durability,持久性) 一旦事务提交成功,其结果会被 永久保存 ,即使系统崩溃也不会丢失(通常依赖 WAL/redo log 等机制)。 一句话记忆: 要么全做完、前后不破坏规则、互不干扰、做完不丢。