优化后，ES-做到了几十亿数据检索-3-秒返回！，2024年最新程序员去大公司面试问题

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Web前端全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上前端开发知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip1024c （备注前端）

正文

http://lucene.apache.org/core/721/core/org/apache/lucene/codecs/lucene70/package-summary.html#package.description_

Lucene 随机三次磁盘读取比较耗时。其中.fdt文件保存数据值损耗空间大，.tim和.doc则需要SSD存储提高随机读写性能。

另外一个比较消耗性能的是打分流程，不需要则可屏蔽。

关于DocValues：

倒排索引解决从词快速检索到相应文档ID, 但如果需要对结果进行排序、分组、聚合等操作的时候则需要根据文档ID快速找到对应的值。

通过倒排索引代价却很高：需迭代索引里的每个词项并收集文档的列里面 token。这很慢而且难以扩展：随着词项和文档的数量增加，执行时间也会增加。

Solr docs对此的解释如下：

For other features that we now commonly associate with search, such as sorting, faceting, and highlighting, this approach is not very efficient. The faceting engine, for example, must look up each term that appears in each document that will make up the result set and pull the document IDs in order to build the facet list. In Solr, this is maintained in memory, and can be slow to load (depending on the number of documents, terms, etc.)

在lucene 4.0版本前通过FieldCache，原理是通过按列逆转倒排表将（field value ->doc）映射变成（doc -> field value）映射，问题为逐步构建时间长并且消耗大量内存，容易造成OOM。

DocValues是一种列存储结构，能快速通过文档ID找到相关需要排序的字段。

在ES中，默认开启所有(除了标记需analyzed的字符串字段)字段的doc values，如果不需要对此字段做任何排序等工作，则可关闭以减少资源消耗。

3.3 关于ES索引与检索分片

ES中一个索引由一个或多个lucene索引构成，一个lucene索引由一个或多个segment构成，其中segment是最小的检索域。

数据具体被存储到哪个分片上：shard = hash(routing) % numberofprimary_shards

默认情况下 routing参数是文档ID (murmurhash3),可通过 URL中的 _routing 参数指定数据分布在同一个分片中，index和search的时候都需要一致才能找到数据。

如果能明确根据_routing进行数据分区，则可减少分片的检索工作，以提高性能。

四、优化案例

在我们的案例中，查询字段都是固定的，不提供全文检索功能，这也是几十亿数据能秒级返回的一个大前提：

**1、**ES仅提供字段的检索，仅存储HBase的Rowkey不存储实际数据。

**2、**实际数据存储在HBase中，通过Rowkey查询，如下图。

**3、**提高索引与检索的性能建议，可参考官方文档（如https://www.elastic.co/guide/en/elasticsearch/reference/current/tune-for-indexing-speed.html）

一些细节优化项官方与其他的一些文章都有描述，在此文章中仅提出一些本案例的重点优化项。

4.1 优化索引性能

**1、**批量写入，看每条数据量的大小，一般都是几百到几千。

**2、**多线程写入，写入线程数一般和机器数相当，可以配多种情况，在测试环境通过Kibana观察性能曲线。

**3、**增加segments的刷新时间，通过上面的原理知道，segment作为一个最小的检索单元，比如segment有50个，目的需要查10条数据，但需要从50个segment

分别查询10条，共500条记录，再进行排序或者分数比较后，截取最前面的10条，丢弃490条。在我们的案例中将此 “refresh_interval”: “-1” ，程序批量写入完成后

进行手工刷新(调用相应的API即可)。

**4、**内存分配方面，很多文章已经提到，给系统50%的内存给Lucene做文件缓存，它任务很繁重，所以ES节点的内存需要比较多(比如每个节点能配置64G以上最好）。

**5、**磁盘方面配置SSD，机械盘做阵列RAID5 RAID10虽然看上去很快，但是随机IO还是SSD好。

**6、**使用自动生成的ID，在我们的案例中使用自定义的KEY，也就是与HBase的ROW KEY，是为了能根据rowkey删除和更新数据，性能下降不是很明显。

**7、**关于段合并，合并在后台定期执行，比较大的segment需要很长时间才能完成，为了减少对其他操作的影响(如检索)，elasticsearch进行阈值限制，默认是20MB/s，

可配置的参数：“indices.store.throttle.maxbytesper_sec” : “200mb” （根据磁盘性能调整）

合并线程数默认是：Math.max(1, Math.min(4, Runtime.getRuntime().availableProcessors() / 2))，如果是机械磁盘，可以考虑设置为1：index.merge.scheduler.maxthreadcount: 1，

在我们的案例中使用SSD，配置了6个合并线程。

4.2 优化检索性能

**1、**关闭不需要字段的doc values。

**2、**尽量使用keyword替代一些long或者int之类，term查询总比range查询好 (参考lucene说明 http://lucene.apache.org/core/740/core/org/apache/lucene/index/PointValues.html)。

**3、**关闭不需要查询字段的_source功能，不将此存储仅ES中，以节省磁盘空间。

**4、**评分消耗资源，如果不需要可使用filter过滤来达到关闭评分功能，score则为0，如果使用constantScoreQuery则score为1。

5、关于分页：

(1) from + size:

每分片检索结果数最大为 from + size，假设from = 20, size = 20，则每个分片需要获取20 * 20 = 400条数据，多个分片的结果在协调节点合并(假设请求的分配数为5，则结果数最大为 400*5 = 2000条) 再在内存中排序后然后20条给用户。

这种机制导致越往后分页获取的代价越高，达到50000条将面临沉重的代价，默认from + size默认如下：

index.maxresultwindow ：10000

(2) searchafter: 使用前一个分页记录的最后一条来检索下一个分页记录，在我们的案例中，首先使用from+size，检索出结果后再使用search****after，在页面上我们限制了用户只能跳5页，不能跳到最后一页。

(3) scroll 用于大结果集查询，缺陷是需要维护scroll_id

**6、**关于排序：我们增加一个long字段，它用于存储时间和ID的组合(通过移位即可)，正排与倒排性能相差不明显。

**7、**关于CPU消耗，检索时如果需要做排序则需要字段对比，消耗CPU比较大，如果有可能尽量分配16cores以上的CPU，具体看业务压力。

8、关于合并被标记删除的记录，我们设置为0表示在合并的时候一定删除被标记的记录，默认应该是大于10%才删除：“merge.policy.expungedeletesallowed”: “0”。

{
“mappings”: {
“data”: {
“dynamic”: “false”,
“_source”: {
“includes”: [“XXX”] – 仅将查询结果所需的数据存储仅_source中},
“properties”: {
“state”: {
“type”: “keyword”, – 虽然state为int值，但如果不需要做范围查询，尽量使用keyword，因为int需要比keyword增加额外的消耗。
“doc_values”: false-- 关闭不需要字段的doc values功能，仅对需要排序，汇聚功能的字段开启。},
“b”: {"
type": “long”
– 使用了范围查询字段，则需要用long或者int之类 （构建类似KD-trees结构）
}
}
}
},
“settings”: {…}
}

五、性能测试

优化效果评估基于基准测试，如果没有基准测试无法了解是否有性能提升，在这所有的变动前做一次测试会比较好。在我们的案例中：

**1、**单节点5千万到一亿的数据量测试，检查单点承受能力。

后话

---

对于面试，说几句个人观点。

面试，说到底是一种考试。正如我们一直批判应试教育脱离教育的本质，为了面试学习技术也脱离了技术的初心。但考试对于人才选拔的有效性是毋庸置疑的，几千年来一直如此。除非你有实力向公司证明你足够优秀，否则，还是得乖乖准备面试。这也并不妨碍你在通过面试之后按自己的方式学习。
其实在面试准备阶段，个人的收获是很大的，我也认为这是一种不错的学习方式。首先，面试问题大部分基础而且深入，这些是平时工作的基础。就好像我们之前一直不明白学习语文的意义，但它的意义就在每天的谈话间。

所谓面试造火箭，工作拧螺丝。面试往往有更高的要求，也迫使我们更专心更深入地去学习一些知识，也何尝不是一种好事。

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip1024c （备注前端）

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
可以添加V获取：vip1024c （备注前端）**
[外链图片转存中…(img-kuIrKiH5-1713230349742)]

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！