广州网站设计公司兴田德润在那里哪些网站可以赚钱
👉 点击关注不迷路
 👉 点击关注不迷路
 👉 点击关注不迷路
文章大纲
- 1.2.2倒排索引原理与分词器(`Analyzer`)
 - 1. `倒排索引:搜索引擎的基石`
 - 1.1 正排索引 vs 倒排索引
 - 示例数据对比:
 
- 1.2 倒排索引核心结构
 - 压缩效果对比(`1亿文档场景`):
 
- 1.3 性能优化策略
 
- 2. 分词器(`Analyzer`)工作机制
 - 2.1 分词器三层处理流程
 - 2.2 内置分词器对比
 - 分词性能测试(处理10万条商品标题):
 
- 2.3 中文分词深度解决方案
 
- 3. 联合应用实战案例
 - 3.1 电商搜索优化
 - 3.2 日志多语言处理
 - 3.3 敏感词过滤系统
 
- 4. 性能对比与最佳实践
 - 4.1 `倒排索引配置建议`
 - 4.2 分词器选择指南
 - 4.3 联合优化最佳实践
 
1.2.2倒排索引原理与分词器(Analyzer)
 
1. 倒排索引:搜索引擎的基石
 
1.1 正排索引 vs 倒排索引
| 索引类型 | 数据结构 | 典型查询场景 | 时间复杂度 | 
|---|---|---|---|
| 正排索引 | 文档ID → 字段内容 | 已知ID查内容(SELECT *) | O(1) | 
| 倒排索引 | 词项 → [文档ID列表] | 关键词搜索(WHERE text LIKE) | O(log n) + O(m) | 
示例数据对比:
- 文档集合
 
| 文档ID | 标题 | 
|---|---|
| 1 | Elasticsearch实战 | 
| 2 | 搜索引擎核心技术 | 
-  
正排索引

 -  
倒排索引

 
1.2 倒排索引核心结构
- 倒排索引 = 词项字典(
Term Dictionary) + 倒排列表(Posting List)

 
压缩效果对比(1亿文档场景):
 
| 存储方式 | 原始大小 | 压缩后大小 | 查询速度 | 
|---|---|---|---|
| 未压缩文档ID列表 | 400MB | - | 120ms | 
Roaring Bitmaps | 400MB | 15MB | 45ms | 
Roaring Bitmaps:是一种用于高效存储和操作稀疏位图(bitmap)的数据结构,通过将一个大的位图分割成多个16位的桶(bucket),每个桶对应一个16位的键值。- 优势 
- 节省空间:对于稀疏位图,
Roaring Bitmaps比传统的位图存储方式节省大量的内存空间。 - 高效操作:支持快速的并集、交集、差集等操作,操作速度快。
 - 易于扩展:可以方便地处理大规模的位图数据。
 
 - 节省空间:对于稀疏位图,
 - 存储方式 
- 数组存储:当桶中元素较少时,使用一个短整型数组来存储这些元素。
 - 位图存储:当桶中元素较多时,使用传统的位图(
bitmap)来存储。

 
 
- 优势 
 
1.3 性能优化策略
-  
- 索引分片(
Sharding) 
- 将大索引切分为多个分片并行处理
 - 示例:
10亿文档索引分为20个分片,查询性能提升8倍 
 - 索引分片(
 -  
- 段合并(
Segment Merge) 
- 后台自动合并小段为更大段
 - 减少打开文件数,提升IO效率
 - 典型合并策略:
Tiered Merge PolicyTiered Merge Policy(分层合并策略)是Elasticsearch等搜索引擎中用于管理索引段(Segment)合并的一种策略。- 在搜索引擎中,新的数据写入时会生成新的索引段,
随着时间推移,索引段数量会增多,这会影响查询性能,因此需要对这些索引段进行合并。 Tiered Merge Policy采用分层的方式来管理和合并这些索引段,以平衡合并成本和查询性能。
 - 工作原理 
- 分层存储:
将索引段按照大小划分为不同的层,每一层中的索引段大小相近。较小的索引段位于较低的层,较大的索引段位于较高的层。 - 合并规则:当
某一层的索引段数量超过一定阈值时,会触发合并操作,将该层的多个索引段合并成一个或多个较大的索引段,并将其提升到上一层。

 
 - 分层存储:
 
 - 段合并(
 -  
- 禁用不需要的特性
 
PUT /logs {"mappings": {"_doc": {"properties": {"message": {"type": "text","norms": false, // 禁用评分因子存储"index_options": "freqs" // 不存储位置信息}}}} } 
2. 分词器(Analyzer)工作机制
 
2.1 分词器三层处理流程

示例:处理"Elasticsearch's 中文分词"
-  
- 字符过滤器:去除HTML标签、替换缩写(如将
’s替换为空)
→ “Elasticsearch中文分词” 
 - 字符过滤器:去除HTML标签、替换缩写(如将
 -  
- 分词器:按空格/标点切分
→ [“Elasticsearch”, “中文”, “分词”] 
 - 分词器:按空格/标点切分
 -  
- Token过滤器:转小写、移除停用词
→ [“elasticsearch”, “中文”, “分词”] 
 - Token过滤器:转小写、移除停用词
 
2.2 内置分词器对比
| 分词器类型 | 处理逻辑 | 中文支持 | 示例输入 → 输出 | 
|---|---|---|---|
| Standard | 按Unicode文本分割,转小写 | 差 | “Elasticsearch实战” → [“elasticsearch”, “实战”] | 
| Simple | 非字母字符切分,保留大写 | 无 | “Hello-World” → [“Hello”, “World”] | 
| Whitespace | 按空格切分,保留原始大小写 | 无 | “Hello World” → [“Hello”, “World”] | 
IK(中文增强) | 智能语义切分 | 优秀 | “搜索引擎” → [“搜索”, “引擎”, “搜索引擎”] | 
分词性能测试(处理10万条商品标题):
| 分词器 | 耗时(秒) | 内存占用(GB) | 准确率(F1值) | 
|---|---|---|---|
| Standard | 4.2 | 1.8 | 0.62 | 
| IK | 6.7 | 2.5 | 0.89 | 
Jieba | 5.9 | 2.1 | 0.91 | 
2.3 中文分词深度解决方案
-  
痛点分析:
歧义切分(如"南京市长江大桥" → 南京/市长/江大桥 或 南京市/长江/大桥)- 新词识别(如网络用语"奥利给")
 
 -  
IK分词器实战配置:
 
PUT /news
{"settings": {"analysis": {"analyzer": {"ik_smart_custom": {"type": "custom","tokenizer": "ik_smart","filter": ["lowercase", "stopwords_filter"]}},"filter": {"stopwords_filter": {"type": "stop","stopwords": ["的", "是", "了"]}}}}
}
 
3. 联合应用实战案例
3.1 电商搜索优化
- 需求:提升"女士冬季羽绒服"搜索准确率
 - 解决方案: 
-  
- 使用IK分词器配置同义词
 
 
"filter": {"synonym_filter": {"type": "synonym","synonyms": ["羽绒服 => 羽绒衣, 羽绒外套"]} }-  
- 倒排索引存储词项位置信息
 
 
"mappings": {"properties": {"title": {"type": "text","index_options": "offsets" // 存储位置信息用于短语匹配}} } -  
 - 效果:
 - 搜索召回率提升37%
 - 相关商品点击率(
CTR)从22%提升至41% 
3.2 日志多语言处理
- 场景:国际业务日志含中/英/日文本
 - 配置方案:
 
PUT /logs
{"settings": {"analysis": {"analyzer": {"multi_lang": {"type": "custom","char_filter": ["html_strip"],"tokenizer": "standard","filter": ["lowercase","cjk_width"  // 全角转半角(处理日语)]}}}}
}
 
- 处理效果: 
- 日文文本 “エラーメッセージ” → [“エラーメッセージ”]
 - 中文文本 “错误信息” → [“错”, “误”, “信”, “息”]
 
 
3.3 敏感词过滤系统
- 实现方案: 
-  
- 自定义字符过滤器
 
 
"char_filter": {"sensitive_filter": {"type": "mapping","mappings": ["傻X => **", "垃圾 => **"]} }-  
- 在
分词器链中应用 
 - 在
 
"analyzer": {"safe_analyzer": {"char_filter": ["sensitive_filter"],"tokenizer": "ik_smart"} } -  
 - 测试结果:
 - 原始文本:“这个产品简直是垃圾!”
 - 处理后词项:[“这个”, “产品”, “简直”, “是”, “**”]
 
4. 性能对比与最佳实践
4.1 倒排索引配置建议
 
| 场景 | 推荐配置 | 预期收益 | 
|---|---|---|
| 高频短语查询 | 启用index_options: positions | 短语查询速度提升3倍 | 
| 大文本存储 | 禁用_source字段 + 开启best_compression | 存储空间减少40% | 
| 实时性要求高 | 设置refresh_interval: 30s | 写入吞吐量提升120% | 
4.2 分词器选择指南
| 场景 | 推荐分词器 | 关键特性 | 
|---|---|---|
| 中文搜索 | IK分词器 | 细粒度切分 + 新词识别 | 
| 多语言混合 | 标准分词器 + 小写过滤 | 基础分词 + 统一规范化 | 
代码/日志分析 | 白名单分词器 | 保留特殊符号(如HTTP_200) | 
4.3 联合优化最佳实践
-  
- 冷热数据分层
 
- 热数据:
SSD存储 + 高副本数(保障查询性能) - 冷数据:HDD存储 + 禁用副本(降低成本)

 
 -  
- 混合索引策略
 
PUT /products {"settings": {"index": {"number_of_shards": 6,"number_of_replicas": 1,"analysis": { ... }}},"mappings": {"dynamic_templates": [{"strings_as_keywords": {"match_mapping_type": "string","mapping": { "type": "keyword" }}}]} } -  
- 监控与调优
 
- 使用
_analyzeAPI测试分词效果GET /_analyze {"analyzer": "ik_smart","text": "自然语言处理技术" } - 通过
indices.stats接口监控索引性能 
 
