当前位置: 首页 > news >正文

Elasticsearch (ES)相关

在ES中,已经有Term Index,那还会走倒排索引吗

你这个问题问得很到位 👍。我们分清楚 Term Index倒排索引 在 Elasticsearch (ES) 里的关系:


1. 倒排索引(Inverted Index)

  • 是 Lucene/ES 检索的核心。
  • 文档 → 词项 → Posting List(包含出现在哪些 doc、位置等)。
  • 当你搜索一个 term 时,最终还是要从倒排索引里取出匹配文档 ID。

2. Term Dictionary / Term Index

  • Term Dictionary 就是所有 term 的字典表,按字典序组织。

  • 如果直接存,可能会很大(几百万甚至上亿个 term)。

  • 为了加速查找,Lucene 会给 Term Dictionary 建立 Term Index(类似于一个 FST 前缀树)。

    • 作用是:快速定位某个 term 在 Term Dictionary 中的位置
    • 比如你要查 “apple”,Term Index 能快速告诉你 “apple” 在字典大概哪一段,而不用顺序扫描。

3. 查询流程(简化版)

  1. 用户查询 "apple"
  2. 先查 Term Index:快速定位 “apple” 在 Term Dictionary 的范围。
  3. 从 Term Dictionary 找到准确的 term
  4. 拿到这个 term 的倒排表(Posting List)
  5. 根据 Posting List 找出对应的文档 ID。

4. 回答你的问题

👉 有 Term Index,不代表不走倒排索引

  • Term Index 只是用来 加速找到 term 的入口,本质上还是要回到 倒排索引(Posting List) 去取文档。

  • 所以两者关系是:

    • Term Index → 帮你定位 term
    • 倒排索引 → 真正返回文档

一句话总结
ES 中,Term Index 是 倒排索引的入口加速结构,最终查文档时一定会走倒排索引。

就是说Term Index不会完全匹配到,只会返回有共同前缀的第一个Term Dictionary?之后在利用倒排索引进行二分查找?

👌 你理解的方向对,但我帮你捋清楚细节:


1. Term Index 的本质

  • Term Index 在 Lucene 里一般是 FST(Finite State Transducer)有穷状态机
  • 它不是存所有 term,而是存 稀疏采样的前缀 → Term Dictionary 的跳转位置
  • 所以 Term Index 的作用是:快速定位到 Term Dictionary 中的某个位置,而不是直接给出完整匹配。

2. 查询过程(举例)

假设 Term Dictionary 里有这些 term:

apple
applet
application
banana
band

当你查 "application"

  1. Term Index 先根据前缀找到 "app" 开头的一个锚点(比如指向 "apple" 这一段)。
  2. 然后在 Term Dictionary 里做精确比较/二分查找,直到找到 "application"
  3. 一旦找到 term,就能取出它对应的 Posting List(倒排表)

3. 回答你的问题

✔ 你说的“只会返回有共同前缀的第一个 Term Dictionary”是对的,但有个补充:

  • Term Index 会定位到 最接近的一个锚点
  • 然后 Lucene 在 Term Dictionary 中继续查找(可能是二分查找,也可能是顺序扫描,取决于实现)。
  • 找到确切的 term 后,才会去读 倒排索引(Posting List)

4. 类比理解

  • Term Index:像书的目录,告诉你某个字母开头的词在哪一页。
  • Term Dictionary:具体的词表,按字典序排好。
  • 倒排索引:每个词对应的“在哪些文章里出现”。

所以 Term Index 永远只是入口,最终要靠 Term Dictionary 精确匹配,拿到 Posting List 才能查文档。

我想的是,按照你给的例子中appli这个前缀似乎是独一无二的,总能找到,就算是applet,apple他们也是有区分度的。那么,唯一的可能就是,Term Index不会无限细分下去,比如到app,就不再往下分了,这样只能搜索到apple

你抓住关键点了 👍,正是这样。

Lucene 里的 Term Index(通常是 FST),不会把所有 term 的路径都完整存进去,否则就和 Term Dictionary 本身没区别了,浪费空间。


1. Term Index 不会无限细分

  • 它是 稀疏索引,只存一部分前缀作为“跳点”。

  • 比如词表里有:

    apple
    applet
    application
    
  • Term Index 可能只存到 “app”,指向这段 term。

  • 并不会继续区分到 "appl" / "appli" 这种更细的层级。


2. 查找过程

  1. 你查 "application" → 先用 FST 找 "app" 的锚点。
  2. 跳到 Term Dictionary 对应区间(可能是 "apple" 开头的地方)。
  3. 然后在这片字典里做二分 / 顺序查找,直到找到 "application"

3. 为什么这样设计?

  • 节省内存:如果所有前缀都存,就和存一整个 Trie 差不多,太大。
  • 查找效率:稀疏索引 + Term Dictionary 二分查找,综合性能更高。
  • 平衡:只要能快速定位到“足够小的一段”就够了,没必要直接精确定位到某个 term。

所以你理解对了

  • Term Index 不会无限细分,它只保证能定位到某个“最近的前缀区间”;
  • 真正的精确匹配还是要靠 Term Dictionary(而不是 Term Index 本身)。

那一般会细分都几个字符

好问题 👍,你已经完全抓到 Lucene Term Index 的实现细节了。


1. Term Index(FST)的细分程度

在 Lucene/ES 里,这个“细分到几个字符”不是写死的,而是通过 采样策略决定的。

  • Lucene 在构建索引时,不会给每个 term 都建一个索引节点,而是按间隔采样
  • 这个采样的粒度由参数控制,主要是:

termIndexInterval

  • 含义:在 Term Dictionary 中,每隔多少个 term,往 FST 里加一个跳点。
  • 默认值(Lucene 9.x):32
  • 也就是说:Term Index 大约每隔 32 个 term 才存一个 entry

2. 影响

  • 如果 term 很多,比如 320,000 个 term,Term Index 里大概只有 10,000 个跳点。
  • 这样就不会无限细分到 applappli 这种级别,而是存一些“代表性前缀”。
  • 查找时,先通过 FST 定位到最接近的跳点,然后再在 Term Dictionary 里做二分/顺序查找。

3. 举个例子

假设 Term Dictionary 里有这些词(简化):

apple
applet
application
apply
banana
band
...
  • 如果 termIndexInterval = 2,那么 Term Index 可能只存:

    • "apple"
    • "application"
    • "banana"
  • 你要查 "applet" 的时候,FST 会定位到 "apple" 这一段,然后在 Term Dictionary 里再顺序/二分找到 "applet"


4. 回答你的问题

👉 一般不会细分到具体几个字符,而是按 term 间隔采样

  • 默认:32 个 term 采样一次
  • 所以“细分程度”取决于字典里 term 的分布,而不是固定的字符长度。

一句话总结
Term Index 不是按字符数来细分,而是 每隔一定数量的 term(默认 32)建立一个跳点。最终的精确匹配仍然要依赖 Term Dictionary。


文章转载自:

http://iMpE5iiQ.gqfbL.cn
http://BDztUKGg.gqfbL.cn
http://ddJ2inaZ.gqfbL.cn
http://lfyuERtX.gqfbL.cn
http://8bzt9T0Y.gqfbL.cn
http://gElBN2rM.gqfbL.cn
http://kaqeSpAS.gqfbL.cn
http://iCdYtsiG.gqfbL.cn
http://daYgtGK0.gqfbL.cn
http://UF1G7hu2.gqfbL.cn
http://K4M5U46c.gqfbL.cn
http://x74bjIO5.gqfbL.cn
http://hIn0z4qa.gqfbL.cn
http://QB1u1TnC.gqfbL.cn
http://dC3NHe23.gqfbL.cn
http://Ag3VnZaO.gqfbL.cn
http://S21KaSAw.gqfbL.cn
http://i2xs3usD.gqfbL.cn
http://T62BCi5s.gqfbL.cn
http://cYBvFbci.gqfbL.cn
http://sFEEkGt9.gqfbL.cn
http://bpD5SdS1.gqfbL.cn
http://oX7z9JcW.gqfbL.cn
http://pAU4bhgP.gqfbL.cn
http://7JIKFSiR.gqfbL.cn
http://Uui9zMlH.gqfbL.cn
http://BBCGhzBX.gqfbL.cn
http://kx5d6A8u.gqfbL.cn
http://jGPmQfPe.gqfbL.cn
http://FjMuQnMB.gqfbL.cn
http://www.dtcms.com/a/381708.html

相关文章:

  • SQL语句优化的步骤详解
  • VSCode 的百度 AI编程插件
  • 【OpenAPI】OpenAPI 3.0x 格式解析技术指南
  • leetcode 14 最长的公共前缀
  • B. Bobritto Bandito
  • 体会bootstrap
  • ConcurrentHashMap 的底层原理及是如何实现线程安全的?
  • linux中查找包含xxx内容的文件
  • 【Linux】添加sudo权限/设置默认权限/配置别名/配置新用户的密码策略
  • 32.网络基础概念(二)
  • Linux网络:应用层协议http
  • 【GitHub】【Windows】Permission denied (publickey) 错误
  • 解决Rocky Linux 9.6下Beyond Compare私钥连接失败问题
  • ubuntu git push每次都要输入密码怎么解决只输入一次密码
  • OpenCV 教程——从像素到智能:图像预处理关键技巧与零售货架缺货检测实战
  • 面试鸭Java八股之Kafka
  • 【学习K230-例程23】GT6700-音频FFT柱状图
  • 【Chrome】chrome 调试工具的network选项卡,如何同时过滤出doc js css
  • python--MediaPipe-opencv眨眼检测
  • 2.2.蓝桥杯-数位递增的数
  • leetcode 3541. 找到频率最高的元音和辅音 简单
  • Spring Boot 与微服务网关集成问题:Zuul、Spring Cloud Gateway 与鉴权策略
  • algorithm | Big O notation
  • 开发指南:使用 MQTTNet 库构建 .Net 物联网 MQTT 应用程序
  • 【代码随想录day 25】 力扣 47.全排列 II
  • 驱动开发系列73 - clEnqueueNDRangeKernel实现
  • Unity 性能优化 之 静态资源优化 (音频 | 模型 | 纹理 | 动画)
  • 服装贸易管理系统推荐及软件选型指南
  • 音视频的下一站:协议编排、低时延工程与国标移动化接入的系统实践
  • Python核心技术开发指南(064)——with语句