自己的 javai.tech 站，最近半年没更新。偶然打开 View Source 一看，差点没晕过去——
og:title 是 “Hexo”，author 是 “John Doe”，连个 description 都没有。
搜索引擎大概也懵了：这是谁的站？ 本文复盘整个改造过程。
事情是这样的：
最近一直在做 AI 相关项目，朋友圈里也开始有人搜「javai」「Sherwin Wei Java」想找到我。结果我跟朋友开玩笑说「你搜 javai.tech 看看」，他搜了，说：
「搜出来一堆东西，但都是 Hexo 主题相关的内容，不像你的站啊？」
我打开浏览器，登录百度站长、Google Search Console，再 curl https://javai.tech，看返回的 HTML。
然后愣住了。
下面这段，是我跑 curl https://javai.tech | grep -E 'og:|description|author' 抓出来的真实数据：
1 | <meta name="keywords" content="Hexo Theme Redefine"> |
看见没？六个 meta，全错。
keywords 是主题名字「Hexo Theme Redefine」author 是 Hexo 默认占位的 「John Doe」og:title 直接就是「Hexo」两个字og:locale 是 en_US，但内容全是中文canonical 还是 http://，没用 https更离谱的是 404 页面。我访问 /xxx（不存在的路径），打开 View Source，作者也是 John Doe。也就是说，搜索引擎每抓到一个不存在的链接，都以为这是某个叫 John Doe 的英文博客。
我把这些分了三档：
| 问题 | 现状 | 修复 |
|---|---|---|
og:title | “Hexo” | “javai - java与ai” |
og:site_name | “Hexo” | “javai” |
meta author | “John Doe” | “Sherwin.Wei” |
meta keywords | “Hexo Theme Redefine” | 真实关键词 |
meta description | 缺失 | 站点描述 |
og:image | 缺失 | 分享卡片图 |
canonical | http | https |
<html lang> | “en” | “zh-CN” |
sitemap.xml，搜索引擎不知道你有多少页面robots.txt，抓取规则没有声明Ctrl+K 啥也没反应_config.yml这是所有问题的根源。打开一看，全是默认占位：
1 | title: Hexo |
这一段不改，其他都白搭。改成：
1 | title: javai - java与ai |
⚠️ 关键点：
url一定要写对。Hexo 的 canonical、sitemap、feed、og:url 全靠这个字段。一字之差，搜索引擎就不认你。
默认装的只有 archive、category、tag、index 这几个 generator，没装 sitemap、feed、search。
1 | npm install hexo-generator-sitemap hexo-generator-feed hexo-generator-search --save |
装完在 _config.yml 加：
1 | sitemap: |
og:image 是分享到微信/微博/LinkedIn/Twitter 时的封面图。没有它，分享卡片就是个白板。
我用 Python + Pillow 临时画了一张（1200×600）：
1 | from PIL import Image, ImageDraw, ImageFont |
5 分钟搞定。专业设计师看不上，但比自己强太多。
Redefine 主题用的是 inject.head 机制（不是 source/_data/head.json，那个我没试成功）。在 _config.redefine.yml 加：
1 | inject: |
这个机制的好处是改配置不改主题，主题升级不会被覆盖。
放在 source/robots.txt：
1 | User-agent: * |
注意：Sitemap 一定要写完整 URL，不要写相对路径。
在 _config.redefine.yml 的 navbar 加 search：
1 | navbar: |
部署前先本地 hexo clean && hexo generate，看会不会报错。没问题了再 hexo deploy。
部署完等 2-5 分钟，跑几个 curl 验证：
1 | # 检查 meta 修复 |
我自己跑下来，生成 705 个文件、sitemap 包含 473 个 URL，全部 https。
Hexo 的模板里 title: Hexo、author: John Doe、url: http://example.com，新手很容易被「主题配了就行」骗过去。主题配置 ≠ 站点配置。主题只是换了外观，HTML head 里的 og/author/canonical 这些是 Hexo 自己吐的，看的是站点 _config.yml。
每次部署完，第一件事应该是 curl https://yoursite.com | head -50，而不是打开浏览器看页面。
我这次能发现问题，就是 curl 救了我。
hexo-generator-sitemap 默认用 site.url 生成，但如果 site.url 写错了（比如写成 http），整个 sitemap 就是 http 版本。
所以在配置里额外写一遍 sitemap.url 是值得的。
Redefine 主题的文档看着很全，但默认配置下：
默认 + 不改 = 啥也没有。这点不如早期的 Next 主题，至少 Next 默认开 search 和 RSS。
<html lang="en"> 看起来「无害」，但百度会直接降低权重。
中文内容必须 lang="zh-CN"。
搜索引擎在搜索结果里展示的两行摘要，就是 description。没填的话，搜索引擎会从正文里截一段，经常截得莫名其妙（特别是代码块）。
我这次给的 description：
Sherwin.Wei（魏远标）个人技术站，分享 Java/AI 实战、系统设计面试、前后端架构、国学智慧与现代技术融合。13 年经验，曾就职于美的、亿迅、华为。
覆盖了品牌（Sherwin.Wei）+ 关键词（Java、AI、系统设计）+ 差异化（国学）+ 信任锚（13 年经验、大厂）。
我自己测过，分享 javai.tech 之前，微信/微博卡片就一个标题加一行小字。
之后，1200×630 大图、标题、描述、域名全有。
同样的内容，传播效率至少差 3 倍。
SEO 修完了，但站还得「活」起来。我给自己定了三条线：
如果一个月后流量没起来，再来写下一篇复盘：《SEO 修完了，为什么流量还是没起色？》
部署后跑一遍，5 分钟搞定：
1 | curl -s https://yoursite.com | grep -E 'og:title|og:image|description|author|canonical' | sort -u |
如果第三步还有任何输出，说明还没改干净。
]]>给自己的话：
一个写代码的人，连自己的站都懒得维护好，是说不过去的。
这次改造花了半天，但下次别人搜到我时，第一眼看到的不再是「Hexo 默认主题」，
而是一个有名字、有故事、有内容的站。这就够了。
Elasticsearch 中的 Explore API，主要功能是帮助开发者和用户对数据进行探索性分析。它允许执行复杂的查询和聚合操作，从而提供关于数据的高层次洞察。Explore API 为用户提供了一种灵活且高效的方法来检索和处理存储在 Elasticsearch 中的大规模数据。
Explore API 是 Elasticsearch 的核心组成部分，它提供了多种功能和应用场景，使其在大数据分析和搜索引擎优化中非常重要。以下是一些具体的扩展知识点：
1）基础查询
Explore API 可以执行简单到复杂的搜索查询，例如匹配查询、布尔查询、范围查询等。这些查询允许用户根据特定的条件过滤数据，获取所需的信息。
2）聚合操作
聚合功能使用户能够执行统计分析，例如计算平均值、最大值、最小值、总和以及分组统计等。这对于数据分析和报告生成非常有用。例如，电子商务网站可以使用聚合操作来统计销售数据，从而优化库存和营销策略。
3）全文搜索
Explore API 拥有强大的全文搜索能力，这使得它在实现搜索功能时非常高效。通过分词、打分、相关度排序等技术，用户可以精准地获取搜索结果。这在内容管理系统（CMS）和博客等应用中非常常见。
4）数据过滤和排序
用户可以使用 Explore API 对数据进行细粒度的过滤和排序，满足特定的业务需求。例如，在日志分析场景中，可以根据时间、级别等不同维度来筛选和排序日志数据。
5）地理空间查询
对于包含地理位置信息的数据，Explore API 还支持地理搜索和聚合操作。可以进行地理范围查询、地理距离排序等。这在地图服务、位置推荐等应用场景中非常有用。
6）多语言支持
由于 Elasticsearch 支持多种语言的分词器和分析器，Explore API 也能够处理不同语言的数据搜索和分析，这使得其在国际化应用中具有很大优势。
7）扩展性和实时性
Elasticsearch 和它的 Explore API 天然支持扩展性和高吞吐量，可以处理海量数据。而且其近实时（Near Real-Time, NRT）特性使得它能够迅速响应数据写入和更新操作。
Elasticsearch 是一个开源的搜索和分析引擎，具备高效、分布式和实时的特点。当前稳定版本的 Elasticsearch 具备以下核心特性和改进：
1）索引和搜索：Elasticsearch 提供了强大的全文搜索能力，支持各种类型的数据索引，从结构化数据到非结构化数据。
2）分布式架构：支持分布式计算，可以轻松扩展至数百个节点并处理 PB 级的数据。
3）高可用性：通过分片和副本机制，实现数据的高可用性和容错性。
4）聚合功能：支持复杂的数据分析和聚合操作，满足各种大数据分析需求。
5）近实时搜索：数据在写入后几乎可以立刻进行搜索，这是由于其高效的刷新机制。
6）安全性：内置了丰富的安全特性，包括 X-Pack 插件，提供加密通讯、用户认证和授权等安全控制。
7）机器学习：内置的机器学习功能，使用户能够进行异常检测、数据预测等高级数据分析。
8）Kibana 集成：与 Kibana 无缝集成，提供数据可视化、监控和管理工具。
Elasticsearch 的核心特性和最新改进让它在许多领域有广泛应用。
1）索引和搜索：
2）分布式架构：
3）高可用性：
4）聚合功能：
5）近实时搜索：
6）安全性：
7）机器学习：
8）Kibana 集成：
Elasticsearch 和 Solr 都是常用的搜索引擎解决方案，但是它们在架构、数据存储、可扩展性、社区支持和使用体验等多个方面存在显著差异。
1）架构方面：Elasticsearch 使用的是分布式架构，天然支持分片和副本，适合处理大规模的数据；Solr 是基于 Apache Lucene 的，尽管也支持分布式，但实现起来更复杂一些。
2）数据存储：Elasticsearch 默认使用 JSON 格式存储数据，这使得它与现代 RESTful API 自然契合；Solr 通常使用 XML 格式存储数据，显得比较传统。
3）可扩展性：Elasticsearch 具有自动分片和副本管理功能，非常适合分布式环境；Solr 则需要手动配置 Zookeeper 来管理集群，略显麻烦。
4）社区和支持：Elasticsearch 有着一个非常活跃的社区并且有企业级支持；Solr 也有一个庞大的用户群体，但在社区活跃度上略输一筹。
5）使用体验：Elasticsearch 的 RESTful API 和 Kibana 的可视化工具非常方便开发者进行数据操作和监控；Solr 则在配置方面需要更多的手工操作，学习曲线稍陡。
除了以上几点，还有一些细节差异值得一提：
1）全文搜索方面：由于两者都基于 Lucene，所以它们在全文搜索的核心功能上大致相同。然而，Elasticsearch 包含了许多内置的相关功能，例如自动补全、拼写纠错等，这些在 Solr 中可能需要额外的插件或自定义。
2）索引重建：在需要重新索引大量数据时，Elasticsearch 的滚动更新和零停机时间重建机制显得更加成熟；而 Solr 虽然也支持索引重建，但升级和维护过程中需要更多的计划和测试工作。
3）数据聚合：Elasticsearch 提供了一个非常强大的聚合框架，支持多级聚合和复杂的嵌套聚合；Solr 虽然也支持数据聚合，但在复杂性和灵活性上不如 Elasticsearch 强大。
4）安装和配置：Elasticsearch 相对更容易安装和配置，其“开箱即用”的特性能让新手更快上手；Solr 的配置稍复杂，尤其是在分布式集群管理方面，这需要开发者更多的经验和理解。
]]>Elasticsearch 是以文档为基础的分布式搜索和分析引擎，而关系型数据库（RDBMS）是一种以表为基础的传统数据库管理系统。它们在数据存储和查询等方面有显著的区别：
1）数据存储方式：
2）查询方式：
3）扩展性：
4）事务处理：
Elasticsearch 和关系型数据库在内部架构、使用场景和性能上都有各自的特定优势和应用场景。
1）使用场景:
2）性能:
3）集成和生态环境:
要让 Elasticsearch 和数据库（比如 MySQL）的数据保持同步，可以采用以下几种常见方式：
1）定时同步： 定期执行同步任务，将数据库中的最新数据更新到 Elasticsearch 中。可以使用调度任务工具（如 cron、Quartz）来实现。
2）实时同步： 当数据库中的数据发生变化时，立即更新 Elasticsearch。具体实现方式多种多样，例如通过数据库触发器、消息队列（如 Kafka、RabbitMQ）实现。
3）增量同步： 使用变更数据捕获（CDC，Change Data Capture）技术来捕获数据库中的变化，并将这些变化应用到 Elasticsearch。工具如 Debezium 就是一个常用的 CDC 解决方案。
1）定时同步：
2）实时同步：
3）增量同步：
另外，还有一些细节值得考虑：
Term、Match 和 Keyword 是 Elasticsearch 中非常常用的检索类型，这三者的区别主要在于它们处理查询和数据的方式。
1）Term 查询：Term 查询不会解析查询字符串，而是直接将查询值用于查询。因此，它适用于精确匹配。例如，搜索状态码为 “200” 的文档。
2）Match 查询：Match 查询会将查询字符串进行分词和分析，然后查找与分词后的每个词匹配的文档。因此，它适用于全文搜索。例如，搜索标题包含 “quick brown fox” 的文档。
3）Keyword：Keyword 是一种数据类型，而不是查询类型。它用于存储不会被分词的文本字段，适用于精确匹配和聚合分析。
1）Term 查询：
示例代码：
1 | { |
2）Match 查询：
示例代码：
1 | { |
3）Keyword 数据类型：
示例模板：
1 | { |
通过 Elasticsearch 实现复杂的查询过滤条件，通常需要使用其强大的搜索查询 DSL（Domain Specific Language）。具体来说，可以借助 Bool Query 来结合多个查询条件（must、should、must_not、filter）实现复杂的逻辑筛选。下面是一个实际例子，通过 Bool Query 实现复杂的查询：
1 | { |
这里的查询条件实现了这样一种逻辑：必须满足 status 为 active 和 age 大于等于 30，同时性别是 male，优先推荐 subscription 为 premium，不包括 country 为 USA 的记录。
1）查询子句解读：
2）评分和优化：
在实际应用中，经常会遇到需要评分（scoring）和排序的情况。Elasticsearch 的 scoring 会根据查询条件的权重（boost）以及文档的相关性评分返回查询结果。对于时间敏感和性能敏感的查询，可以使用 filter 子句，因为它不会计算相关性评分，从而提升查询性能。
3）嵌套查询和子查询：
对于更为复杂的条件，可以使用 nested query 来处理嵌套对象，使用子查询可以更灵活地组合多个查询逻辑。例如，使用 nested 子句处理带有嵌套结构的 JSON 数据：
1 | { |
这个例子用于查询 comments 里 user 为 kimchy 且 date 大于等于 2022-01-01 的记录。
4）使用脚本进行高级查询：
Elasticsearch 允许使用脚本进行更高级的查询，尽管这可能会耗费更多资源。在 _score 子句里可以用脚本来控制评分逻辑。例如，用一个简单的 Painless 脚本来进行自定义评分：
1 | { |
这个例子中，评分由文档的 views 值乘以匹配查询的默认评分值。
Elasticsearch 的 RestHighLevelClient 与 RestClient 的主要区别在于它们的抽象层次和使用的复杂度。
1）RestHighLevelClient 是基于 RestClient 之上的更高级的客户端，它封装了 Elasticsearch 的许多 API 调用，使得操作更加简单和直观。
2）RestClient 是更底层的客户端，操作更灵活，但同时需要开发者自己处理更多的细节，比如解析响应、错误处理等。
选择使用哪个客户端取决于以下因素：
1）如果你希望更快速地进行开发并且不想处理太多复杂的底层细节，推荐使用 RestHighLevelClient。
2）但如果你需要更细粒度的控制和更灵活的处理方式，则可以使用 RestClient。
1）RestHighLevelClient 的优点和使用场景：
2）RestClient 的优点和使用场景：
3）选择的策略：
4）版本兼容性：
我们可以通过 Spring Data Elasticsearch 简化与 Elasticsearch 的集成。这是因为 Spring Data Elasticsearch 提供了一套高级别的 API，能够帮助我们更加方便地操作 Elasticsearch。具体步骤如下：
1）我们首先需要在项目中引入 Spring Data Elasticsearch 的依赖。
2）然后，需要在 Spring Boot 应用程序中配置 Elasticsearch 相关的信息，比如集群的地址和端口。
3）接下来，我们可以定义一个实体类来对应 Elasticsearch 的索引。
4）通过扩展 ElasticSearchRepository（或者 ReactiveElasticSearchRepository），我们可以创建自己的仓库接口，这个接口将提供出一些基本的 CRUD 操作方法，还可以自定义查询方法。
5）最后，我们可以通过自动注入这些仓库接口，来实现我们的业务逻辑。
这样通过以上的步骤，我们就能够非常轻松地实现与 Elasticsearch 的集成，大幅度减少我们直接处理 Elasticsearch 具体 API 的复杂性。
Spring Data Elasticsearch不仅提供了简洁的 CRUD 操作接口，还支持自定义查询和复杂查询。我们可以通过命名查询方法或使用 @Query 注解来自定义查询逻辑。比如，可以像这样编写一个自定义查询接口：
1 | public interface ProductRepository extends ElasticsearchRepository<Product, String> { |
除了 CRUD 和简单查询外，Spring Data Elasticsearch 还支持以下功能：
1）全文检索 - 可以使用 Annotation 来标识哪个字段是索引字段，那么在查询时可以像全文检索那样进行搜索。
2）分页和排序 - 使用 Pageable 和 Sort 进行分页和排序。
3）自定义实体映射 - 如果默认映射不符合需求，你可以自定义实体与 Elasticsearch 文档之间的映射。
4）聚合操作 - 支持 Elasticsearch 的聚合查询。
扩展阅读材料：
]]>Elasticsearch 中分词功能的实现，是通过它的分析器（Analyzer）组件完成的。分析器包含三个部分：字符过滤器（Character Filters）、分词器（Tokenizer）和标记过滤器（Token Filters）。分词的主要过程是将文本字符串处理成一系列有意义的词汇单元（Tokens），便于索引和搜索。
1）字符过滤器：首先，字符过滤器会预处理输入文本，请注意这一步往往是可选的。常见的操作包括去除或替换特殊字符、HTML 解码等。
2）分词器：其次，核心分词器（Tokenizer）会将输入文本根据一定的规则拆分成一个个的词汇单元（Tokens）。比如标准的分词器会根据空格和标点符号来拆分文本。
3）标记过滤器：最后，标记过滤器（Token Filters）会对这些词汇单元进行处理，如转小写、去除停用词（比如”the”、”and”）等，让分词结果更加符合搜索意图。
总之，分词功能的实现原理由上述三个阶段组成，它们协作地将文本转换成适合存储和搜索的词汇单元。
1）字符过滤器的作用：字符过滤器在文本进入分词器之前进行预处理。比如 HTML Strip 字符过滤器会去除 HTML 标签，而 Mapping 字符过滤器可以用来将特定字符映射为其他字符。
2）分词器的多样性：Elasticsearch 提供了多种内置的分词器，例如：
3）标记过滤器的丰富性：标记过滤器用于词汇单元的进一步处理。例如：
4）自定义分析器：用户可以根据需求自定义自己的分析器，包括选择和配置字符过滤器、分词器和标记过滤器。这让 Elasticsearch 的分词功能非常灵活。
]]>Elasticsearch 的倒排索引和 MySQL 的正排索引在数据存储和查询优化方面的实现策略和应用场景上有明显区别：
1）倒排索引（Elasticsearch）：倒排索引是一种为了快速全文检索而设计的数据结构。它将文档中的每一个唯一的词汇（Term）映射到包含这个词汇的文档列表，这样在搜索时，可以快速定位包含特定词汇的文档。
2）正排索引（MySQL）：正排索引主要用于传统关系型数据库，它将每行的数据按照主键或某个字段的顺序排列并建立索引。当进行查询时，它通过索引快速定位到满足查询条件的行，然后读取数据。
为了更全面地理解两者的区别和使用场景，以下是两者的详细对比：
1）数据结构：
2）应用场景：
3）查询速度：
4）更新操作：
在Elasticsearch中，搜索是基于倒排索引进行的。当你根据给定的词汇（term）查找对应的倒排索引时，主要会经历以下步骤：
这些步骤看似简单，但每个步骤都有很多细节和优化。以下是一些关键的附加知识：
分词器和标准化：
倒排索引的结构：
多字段搜索：
缓存与优化：
相关性评分与排序：
在Elasticsearch中，倒排索引（Inverted Index）是其核心的数据结构，用于高效地进行全文搜索。倒排索引的基本结构如下：
1）术语字典（Term Dictionary）：存储所有文本文档中出现的唯一术语（也叫词项），并按字典序进行排序。
2）术语列表（Term List）：每个唯一术语都会关联一个包含它的文档列表，项目中仍然是以文档ID为索引分布的。
3）倒排文件索引（Inverted File Index）：对于每个术语，记录了包含该术语的所有文档的列表，通常可以包括位置信息、频率信息等，用于在文档中查找定位。
举个例子，假设有以下三个文档：
倒排索引会从这些文档提取术语并建立如下结构：
术语：{ “An”, “Elasticsearch”, “a”, “engine”, “engines”, “in”, “index”, “inverted”, “is”, “search”, “used”, “uses” }
倒排文件索引：
1）术语位置和频率：倒排索引不仅仅只记录术语对应的文档ID，还记录了术语在每个文档中出现的位置和频率。这些信息在排序、聚合和高效的快速查询中都非常重要。例如，Elasticsearch能够快速高效地计算出某个术语在特定段落或者文档中的出现次数及其相对位置。
2）分片和副本：Elasticsearch依赖倒排索引来快速检索分片中的数据。集群中的每个索引会分成多个主分片（Primary Shards）和副本分片（Replica Shards），分片中的每一个都会维护自己的倒排索引。
3）压缩技术：由于倒排索引可能会消耗大量存储空间，Elasticsearch应用了多种压缩技术来减少索引数据的存储需求，如字典编码、前缀压缩和格里布编码。这些技术可以极大地压缩索引文件的体积，提高检索速度和效率。
4）Lucene库：在Elasticsearch的底层实现中，实际上是使用了Apache Lucene库。Lucene提供了创建和管理倒排索引的所有基础设施，因此它是Elasticsearch高效搜索能力的根基。
]]>Elasticsearch 底层是通过一种叫做 “近实时搜索（NRT - Near Real-Time Search）” 的方式来处理文档的更新和删除操作的。具体来说：
1）更新操作实际上是先删除旧文档，然后插入新文档。
2）删除操作并不会立即将文档从磁盘中移除，而是标记为“已删除”。
1）客户端发起更新请求。
2）Elasticsearch 接收到更新请求，将请求转发到负责该文档的主分片。
3）主分片进行版本控制，确保数据的一致性。
4）Elasticsearch 先将旧文档标记为删除，然后创建一个新版本的文档。
5）主分片将更改记录到事务日志（Translog）中，确保数据在故障恢复时不丢失。
6）最后，将更新同步到副本分片，确保高可用性。
1）客户端发起删除请求。
2）Elasticsearch 将该请求转给相应的主分片。
3）主分片检查文档的版本信息，确保没有并发冲突。
4）不是立即删除文档，而是将其标记为“已删除”状态。
5）将删除操作记录到事务日志（Translog）中。
6）在适当的时间，经过段合并（Segment Merge）操作，彻底从磁盘上移除标记为删除的文档。
1）文档版本控制
2）事务日志（Translog）
3）段合并（Segment Merge）
4）近实时搜索（NRT）
5）副本分片同步
Elasticsearch 底层的数据存储主要依赖于 Apache Lucene，它通过将数据存储在倒排索引的结构中来实现快速的全文搜索。简言之，Elasticsearch 会将插入的数据文档拆分成一个个的“倒排索引”（Inverted Index），然后存储在分片（Shard）中。每个索引由多个分片组成，每个分片又进一步拆分为多个段（Segment）。这些段是 Lucene 管理数据存储和检索的基本单元。
1） 倒排索引：倒排索引是一种高效的文本检索数据结构。它主要包括两个部分：词典（dictionary）和倒排列表（postings list）。词典包含了文档中出现的所有单词，而倒排列表为每个单词储存对应的文档和位置信息。倒排索引使得 Elasticsearch 能够迅速的找到包含特定关键词的文档。
2） 分片和副本：为了实现数据的分布式存储和高可用性，Elasticsearch 将索引拆分为分片（primary shard），并为每个分片复制多个副本（replica shard）。这样做不仅可以提升读取性能，还能在某些分片失效时保证数据不丢失。默认情况下，一个索引有5个主分片和1个分片副本。
3） 段（Segment）管理：Lucene 将每个分片进一步拆分为多个段。段是不可变的文件，存储最终的数据。每个索引操作（比如新增或更新文档）都会生成新的段，这些段会定期进行合并操作（Merge），以减少文件数量并优化查询性能。
4） 文档写入流程：
5） 数据管理：
6） 数据查询：倒排索引的结构使得查询效率非常高。当用户发起查询请求时，Elasticsearch 会用查询关键词在倒排索引中迅速找到对应的文档列表，从而实现快速的全文检索功能。
]]>在 Lucene 中实现倒排索引是它的核心功能之一。倒排索引是一种高效存储和检索文本数据的结构，能够快速找到包含某个特定词的文档。为此，我们可以使用 Lucene 的 API 来创建、添加文档到索引和进行查询。以下是实现倒排索引的基本步骤：
1）创建一个 IndexWriter 实例 —— 这个类负责将文档写入索引。
2）定义一个文档（Document）并添加域（Field）—— 文档是索引的基本单位，每个文档由若干个域组成。
3）向索引中添加文档。
4）关闭 IndexWriter。
5）创建 IndexReader 和 IndexSearcher 实例以进行查询。
这里给出一个简单的示例来说明这些步骤：
1 | import org.apache.lucene.analysis.standard.StandardAnalyzer; |
这个代码创建了一个简单的内存索引，并搜索包含“Lucene”这个词的文档。对于生产环境，通常将索引存储在磁盘上，而不是内存中。
1）倒排索引的原理：倒排索引的核心是它通过持有倒排列表（即每个术语对应的文档列表）能够迅速定位包含该术语的所有文档，相比于扫描全部文档来说这是非常高效的。
2）Lucene 的分析器：Lucene 的分析器（Analyzer）用于对文本进行分词，建立词项（Term），分析器有多种类型，可以根据需求选择或自定义合适的分析器。
3）Lucene 索引结构：Lucene 的索引结构包括多个层次，索引（Index）包含多个段（Segment），每个段是一个独立的倒排索引文件，搜索时会合并这些段的结果，大规模索引还涉及到索引合并（Merge）操作。
4）TokenStream 和分词：TokenStream 是分析器内部的一部分，它负责将输入的文本流转换为标记流，实际的分词操作在这个过程中完成。
5）Query 类的不同实现：Lucene 提供了多种查询方式，如 TermQuery、PhraseQuery、BooleanQuery 等，通过这些查询方式可以构建非常复杂的搜索条件。
]]>Elasticsearch 的 Posting List，也叫倒排列表，是一种数据结构，用于快速查找包含某个单词或词条（term）的文档集合。在搜索引擎中，它是用来解决查询效率问题的核心组件。当我们进行搜索时，Elasticsearch 会通过倒排列表迅速确定所有包含查询词条的文档，从而大大提高搜索速度。
1）倒排列表的构成：
倒排列表包含两个主要部分：
举例来说，如果有三个文档：
- Doc1: “Elasticsearch is powerful”
- Doc2: “Elastic is flexible”
- Doc3: “Elasticsearch is powerful and flexible”
倒排列表会被构造成如下：
- Term: “Elasticsearch” -> Posting List: [Doc1, Doc3]
- Term: “is” -> Posting List: [Doc1, Doc2, Doc3]
- Term: “powerful” -> Posting List: [Doc1, Doc3]
- Term: “and” -> Posting List: [Doc3]
- Term: “flexible” -> Posting List: [Doc2, Doc3]
2）倒排列表的建立：
当文档被索引的时候，Elasticsearch 会分析文档内容，将其分解为多个词条，并建立倒排列表。这个过程包括以下步骤：
3）查询优化：
Elasticsearch 的倒排列表不仅能快速找到包含某个词条的文档，还可以进行进一步的优化：
Elasticsearch中的相关性得分（Relevance Score）是一个衡量文档与查询匹配程度的数值。简而言之，它表示搜索结果中每个文档的匹配程度，得分越高，表示文档与查询的相关性越强。这个得分主要由Lucene使用TF-IDF算法和BM25算法计算得出。
影响相关性得分的主要因素包括：
1）查询的类型及结构：例如，match 查询和 term 查询计算相关性得分的方式不同。
2）词频（TF，Term Frequency）：一个词在文档中出现的频率越高，该文档被认为和查询匹配的程度越高。
3）逆文档频率（IDF，Inverse Document Frequency）：一个词在整个索引中出现的频率越低，该词的区分度越高，得分贡献也就越大。
4）文档长度（Norms）：一般来说，短文档中的匹配关键词比长文档中的匹配关键词更有代表性。
5）字段的权重：可以通过boost参数给某些字段更高的权重，从而影响最终的得分。
1）查询类型及权重调整：
match查询会对相关性进行计算，而term查询则主要用于精确匹配。boost参数，可以增加或减少某个字段在计算相关性得分时的权重。2）TF-IDF与BM25：
3）脚本打分：
4）多功能查询：
function_score查询，可以灵活地调整和组合各种得分计算方式，例如常数查询、函数衰减（如距离衰减）、字段值因子加权以及随机权重。5）调试相关性得分：
explain参数可以详细解释Elasticsearch如何计算每个文档的相关性得分。这是调试和优化搜索功能的一个有力工具。Elasticsearch 的评分算法主要基于 BM25（Best Matching 25）算法，这是一种改进的 TF-IDF 算法。它通过计算每个文档和查询之间的相关性得分来排序结果。相关性得分基于以下几个主要因素：
1）TF（Term Frequency）：词频，某个词在文档中出现的次数。出现次数越多，该词对该文档的重要性越大。
2）IDF（Inverse Document Frequency）：逆文档频率，用于衡量一个词在所有文档中有多重要。出现频率越低，IDF 越高，反之亦然。
3）Field Length Norm（规范化字段长度）：字段的长度。一般来说，较短的字段如果包含查询词，那么该字段的相关性得分会更高。
4）Document Norms（文档规范化）：这是对文档多个字段进行规范化处理的一个综合得分。
总得来说，Elasticsearch 的评分算法即是通过这些因素来计算每个文档的相关性得分，并将得分高的文档返回给用户。
1）理解 BM25：
BM25 是 BM 系列的其中一个成员，它有效地调整了传统的 TF-IDF 算法。例如，它包含参数 b 和 k1，用来调整词频和文档长度带来的影响。b 参数用于调节字段长度对评分的影响，k1 参数则用于调节 TF 的饱和水平。
2）Elasticsearch 的更多打分机制：
除了 BM25，Elasticsearch 还支持多种评分算法，比如标量场评分（Painless scripting）、无评分或固定评分等。根据需求的不同，您可以覆盖默认的 BM25 机制，使用自定义的脚本来计算相关性评分。
3）Boosting：
为了获取更精确的搜索结果，Elasticsearch 支持 boosting 功能，即为特定字段或查询添加权重。例如，可以增加标题字段的权重，使得在标题中出现的查询词比在正文中出现的关联性更高。
4）Explain API：
Elasticsearch 还提供了一个强大的 Explain API，它可以详细解释某个文档为何匹配某个查询，并且每个部分的相关性分数是如何计算的。这对于调试和优化查询非常有用。