1.Scroll源码解析
2.ElasticSearch源码：数据类型

Scroll源码解析

       1. Scroll查询在指定_doc排序时相较于不指定排序或指定某个字段排序能明显更快，这是由于Scroll查询的机制及底层实现所致。

        首先查看Elasticsearch的Collector，其主要功能是收集文档并按照特定规则排序。其中，TopDocsCollector类在收集文档后会返回一个有序的网页源码对比TopDocs对象，该对象是搜索结果的返回值。TopDocsCollector有三个子类：SimpleFieldCollector、PagingFieldCollector、SimpleTopScoreDocCollector 和PagingTopScoreDocCollector。这些子类根据排序规则（如字段排序、简单排序等）进行文档排序。

       2. 对于TopScoreDocCollector，其排序规则是先执行打分，分数相同的文档按文档号排序。TopFieldCollector则是windowswifi热点源码先按照指定字段排序，值相同的文档再按文档号排序。

       3. TopScoreDocsCollector的两个子类（SimpleTopScoreDocCollector和PagingTopScoreDocCollector）在功能上区别在于PagingTopScoreDocCollector针对翻页请求，代码上增加了对after的判断。对于使用TopScoreDocsCollector无论是否为翻页请求，每次请求都会扫描全部命中文档并计算分值。使用SimpleTopScoreDocCollector还是PagingTopScoreDocCollector取决于after是否为null。

       4. 对于scroll请求，after参数等于scrollContext.lastEmittedDoc，即上次翻页最大的ScoreDoc。TopFieldCollector同样有两个子类（SimpleFieldCollector和PagingFieldCollector），其判断逻辑与TopScoreDocsCollector类似，也是根据searchContext.sort()是否为null来决定使用哪类Collector。

       5. 在lucene6.4.1版本中，无论是SimpleFieldCollector和PagingFieldCollector都无法提前终止收集过程。然而，展览模板源码从更高版本的lucene开始，具备了提前结束收集的功能，判断依据是search sort=index sort一致时，通过抛出CollectionTerminatedException异常提前结束收集。Elasticsearch从6.x版本开始也支持了自定义写入顺序，可以不是_doc而是某个字段值。

       6. 通过Elasticsearch的代码分析，我们确认scroll请求在指定_doc排序并从第二页开始时，只会收集指定数量的doc，性能表现更优。对于scroll请求，包装了一层MinDocQuery，用于过滤掉已经翻页过的数据，大大减少文档命中数，避免收集无用的glibc 2.33 源码doc，这对于深度翻页性能提升明显。

       7. 对于scroll请求，由于不支持向前翻页，每次查询对于已查过的数据无需收集。Elasticsearch通过MinDocQuery实现跳跃功能，将doc跳到segmentMinDoc（lastEmittedDoc+1），在合并倒排表之后，实际上就不会再命中上一页的内容。触发提前终止后，后续倒排表合并也不再必要，性能提升显著。

       8. Scroll与search_after查询实际上走的是相同的逻辑，都是通过一个after变量进行翻页。scroll的after参数为scrollContext.lastEmittedDoc（ScoreDoc），search_after的lsan源码实现after参数为包含sort字段信息的FieldDoc，都是ScoreDoc。最终都会收集全部命中文档才能得到排序结果，但scroll对于_doc排序做了优化，性能表现更佳。

       9. 对于search_after查询，即使指定_doc排序，仍然需要收集全部命中文档，因为search_after是动态的，MinDocQuery跳跃功能不适用。然而，search_after在lucene后续版本中支持了提前终止功能，当查询时指定sort为index sort，可以触发提前终止，不再收集全部命中文档。

       . Scroll请求保存的上下文信息主要是maxScore和lastEmittedDoc用于翻页，但实际保存的不仅仅是ScrollContext，而是SearchContext，其中包含了更多关键信息，如searcher和IndexReader，后者对于后续索引更新是感知不到的，除非重新打开reader或使用DirectoryReader.openIfChanged(oldreader)。这是Scroll查询无法感知索引更新的原因。

       . 经过测试，即使在scroll过程中触发了merge，被merge的segment文件也不会立即被删除，新的segment文件也不会被发现。这表明Scroll查询无法感知数据更新，其本质是快照了LeafReaderContext，并非检索命中的结果。

       总结而言，Scroll查询在指定_doc排序时，通过优化收集过程和使用MinDocQuery实现跳跃功能，能显著提升性能，尤其是在翻页操作中。同时，Scroll请求的机制及底层实现使得其在查询处理上与search_after查询存在显著差异，但在Elasticsearch6.x版本中引入了索引预排序和提前终止功能，进一步优化了查询性能。

ElasticSearch源码：数据类型

       ElasticSearch源码版本 7.5.2，其底层基于Lucene，Lucene好比汽车的发动机，提供了基础的存储和查询功能，而ES则在此基础上增加了分布式特性。本文将简要探讨ES中的数据类型。

       Lucene的FieldType是描述字段属性的核心，包含个属性，如倒排索引和DocValuesType，后者支持聚合排序。官方定义的类型如TextField，仅索引、分词但不存储，而用户可以根据需求自定义数据类型，尽管在ES中，所有数据类型都是自定义的。

       Lucene文件格式类型各异，如Norms和Pre-Document Values，根据FieldType设置的不同属性，文件类型和存储结构会相应变化。Lucene通过不同的压缩类型和数据结构存储数据，但详细实现较为复杂。

       在ES中，数据类型分为Meta-fields和Fields or properties。Meta-fields包括元数据字段如_index、_type和_id，它们存储在特定位置，但处理方式各异。Fields或properties则是开发的核心，包括String（text和keyword）、数字类型、Range类型、时间类型、Boolean和Binary等。

       复杂数据类型如Object和Nested用于处理嵌套结构，而Geo-point和Geo-shape用于地理信息。特殊数据类型如IP、completion和Join则在特定场景下使用。Array要求数组内字段类型一致，Multi-fields则支持多种处理方式的字符串字段。

       总体来说，ES的字段类型丰富且友好，但并非所有场景都适用。开发者在实际应用中应参考官方文档和代码来选择和使用。

       参考资源：org.apache.lucene.codecs.lucene (Lucene 9.0.0核心API)、Elasticsearch Guide [7.5]、elastic.co/guide/en/ela...