开源搜索引擎排名第一，Elasticsearch是如何作到的？

1、引言

 

随着移动互联网、物联网、云计算等信息技术蓬勃发展，数据量呈爆炸式增加。现在咱们能够轻易得从海量数据里找到想要的信息，离不开搜索引擎技术的帮助。

​

做为开源搜索引擎领域排名第一的 Elasticsearch，可以让咱们无需深刻了解背后复杂的信息检索原理，就可实现基本的全文检索功能，在数据量达到十亿，百亿规模仍然能够秒级返回检索结果。

 

对于系统容灾、数据安全性、可扩展性、可维护性等用户关注的实际问题，在Elasticsearch 上也能获得有效解决。

 

2、Elasticsearch 介绍

 

Elasticsearch（ES）是一个基于 Lucene 构建的开源分布式搜索分析引擎，能够近实时的索引、检索数据。具有高可靠、易使用、社区活跃等特色，在全文检索、日志分析、监控分析等场景具备普遍应用。

 

因为高可扩展性，集群可扩展至百节点规模，处理PB级数据。经过简单的 RESTful API 便可实现写入、查询、集群管理等操做。

 

除了检索，还提供丰富的统计分析功能。以及官方功能扩展包 XPack 知足其余需求，如数据加密、告警、机器学习等。

 

另外，可经过自定义插件，如 COS 备份、QQ 分词等知足特定功能需求。

 

1. Elasticsearch 架构与原理

 

 

基本概念 ：

 

• Cluster「集群」：由部署在多个机器的ES节点组成，以处理较大数据集和实现高可用；

• Node「节点」：机器上的ES进程，可配置不一样类型的节点；

• Master Node「主节点」：用于集群选主。由其中一个节点担任主节点，负责集群元数据管理，如索引建立，节点离开加入集群等；

• Data Node「数据节点」：负责索引数据存储；

• Index「索引」：索引数据的逻辑集合，可类比关系型数据的DataBase；

• Shard「分片」：索引数据子集，经过将分片分配至集群不一样节点，实现数据横向扩展。以解决单个节点CPU、内存、磁盘处理能力不足的状况；

• Primary Shard「主分片」：数据分片采用主从模式，由分片接收索引操做；

• Replica Shard「副本分片」：主分片的拷贝，以提升查询吞吐量和实现数据高可靠。主分片异常时，其中一个副本分片会自动提高为新的主分片。

 

为了便于你们理解ES里的数据模型，将它与关系型数据库 MySQL 作类比：

 

 

从上面架构图能够看出，ES 架构很是简洁。内置自动发现实现 Zen discovery，当一个节点启动后，经过联系集群成员列表便可加入集群。

 

由其中一个节点担任主节点，用于集群元数据管理，维护分片在节点间的分配关系。当新节点加入集群后，Master 节点会自动迁移部分分片至新节点，均衡集群负载。

 

 

分布式集群不免有节点故障。主节点会按期探测集群其余节点存活状态，当节点故障后，会将节点移出集群，并自动在其余节点上恢复故障节点上的分片。

 

主分片故障时会提高其中一个副本分片为主分片。其余节点也会探活主节点，当主节点故障后，会触发内置的类 Raft 协议选主，并经过设置最少候选主节点数，避免集群脑裂。

 

 

除了集群管理，索引数据读写也是咱们关心的重要部分。ES 采用 peer-to-peer 架构，每一个节点保存全量分片路由信息，也就是每一个节点都可以接收用户读写。

 

如发送写入请求至节点 1，写入请求默认经过文档 ID 的 Hash 值肯定写入到哪一个主分片，这里假设写入到分片 0。

 

写完主分片 P0，并行转发写入请求至副本分片 R0 所在节点，当副本分片所在节点确认写入成功后返回客户端报告写入成功，保障数据安全性。而且写入前，会确保 quorum 数量的副本数，避免网络分区致使写入数据不一致。

 

 

查询采用分布式搜索，如请求发给节点3后，请求会转发至索引的主分片或副本分片所在节点。

 

固然若是写入、查询均带有路由字段信息。请求只会发送给部分分片，避免全量分片扫描。这些节点完成查询后将结果返回给请求节点，由请求节点汇聚各个节点的结果返回给客户端。

 

 

2. Lucene原理

   

介绍完 ES 集群基本原理，下面简单介绍下ES的底层存储引擎 Lucene。

 

首先 Lucene 是一款高性能的信息检索库，提供索引和检索基本功能。ES 在此基础上解决可靠性、分布式集群管理等问题最终造成产品化的全文检索系统。

Lucene 解决的核心问题即是全文检索。与传统的检索方式不一样，全文检索避免在查询时进行所有内容扫描。

 

好比数据写入后，首先会对写入的文档字段内容分词，造成词典表和与它关联的倒排表。查询时由关键词分词结果直接匹配词典表内容，并获取关联的文档列表，快速获取结果集。并经过排序规则，优先展现匹配度高的文档。

 

 

Lucene 为了加快索引速度，采用了 LSM Tree 结构，先把索引数据缓存在内存。当内存空间占用较高或到达必定时间后，内存中的数据会写入磁盘造成一个数据段文件（segment）。段文件内包含词典、倒排表、字段数据等等多个文件。

 

 

为了兼容写入性能和数据安全性，如避免内存缓冲区里的数据由于机器故障丢失。ES 在写内存的同时也会写事物日志 Translog。内存里的数据会按期生成新的段文件，写入开销更低的文件系统缓存便可打开和读取实现近实时搜索。

 

 

3、Elasticsearch 应用场景

 

ES的典型使用场景有日志分析、时序分析、全文检索等。

 

1. 日志实时分析场景

 

日志是互联网行业基础普遍的数据形式。典型日志有用来定位业务问题的运营日志，如慢日志、异常日志；用来分析用户行为的业务日志，如用户的点击、访问日志；以及安全行为分析的审计日志等。

 

Elastic 生态提供了完整的日志解决方案。经过简单部署，便可搭建一个完整的日志实时分析服务。ES 生态完美的解决了日志实时分析场景需求，这也是近几年 ES 快速发展的一个重要缘由。

 

日志从产生到可访问通常在 10s 级，相比于传统大数据解决方案的几十分钟、小时级时效性很是高。

 

ES底层支持倒排索引、列存储等数据结构，使得在日志场景能够利用ES很是灵活的搜索分析能力。经过ES交互式分析能力，即便在万亿级日志的状况下，日志搜索响应时间也是秒级。

 

日志处理的基本流程包含：日志采集 -> 数据清洗 -> 存储 -> 可视化分析。Elastic Stack经过完整的日志解决方案，帮助用户完成对日志处理全链路管理。

 

 

其中：

 

• 日志采集：经过轻量级日志采集组件FileBeat实时读取业务日志文件，发送数据至下游组件如 Logstash。

• 文本解析：利用正则解析等机制，将日志文本数据转换成结构化数据。可以使用独立的Logstash 服务或 Elasticsearch 内置的轻量级数据处理模块 Ingest Pipeline，完成数据清洗和转换。

• 数据存储：经过 Elasticsearch 搜索分析平台进行数据持久存储，提供全文搜索和分析能力。

• 可视化分析：经过功能丰富的图形界面，便可对日志数据进行搜索分析，如可视化组件 Kibana。

 

 

2. 时序分析场景

 

时序数据是按时间顺序记录设备、系统状态变化的数据。典型的时序数据有传统的服务器监控指标数据、应用系统性能监控数据、智能硬件、工业物联网传感器数据等。

 

早在2017年咱们也基于ES进行了时序分析场景的探索。时序分析场景具备高并发写入、低查询时延、多维分析的特色。

 

因为ES具备集群扩展、批量写入、读写带路由、数据分片等能力，目前已实现线上单集群最大规模达到 600+节点、1000w/s 的写入吞吐、单条曲线或单个时间线的查询延时可控制在 10ms。

 

ES提供灵活、多维度的统计分析能力，实现查看监控按照地域、业务模块等灵活的进行统计分析。另外，ES支持列存储、高压缩比、副本数按需调整等能力，可实现较低存储成本。最后时序数据也可经过Kibana组件轻松实现可视化。

 

 

3. 搜索服务场景

 

搜索服务典型场景有像京东、拼多多、蘑菇街中的商品搜索；应用商店中的应用APP搜索；论坛、在线文档等站内搜索。

 

这类场景用户关注高性能、低延迟、高可靠、搜索质量等。如单个服务最大需达到 10w+ QPS，请求平均响应时间在 20ms之内，查询毛刺低于 100ms，高可用如搜索场景一般要求 4 个 9 的可用性，支持单机房故障容灾等。

 

目前云上 Elasticsearch 服务已支持多可用区容灾，故障分钟级恢复能力。经过 ES 高效倒排索引，以及自定义打分、排序能力与丰富的分词插件，实现全文检索需求。在开源全文检索领域，ES 在 DB-Engines 搜索引擎类别持续多年排名第一。

 

 

4、腾讯 Elasticserch 服务

   

腾讯内外部均有大量的日志实时分析、时序数据分析、全文检索需求场景。

 

目前咱们已联合 Elastic 公司在腾讯云上提供了内核加强版 ES 云服务，简称CES，其中内核加强包括 Xpack 商业套件和内核优化。

 

在服务公司内部以及公有云客户过程当中，也遇到了较多问题和挑战，好比超大规模集群，千万级数据写入，以及云上用户丰富的使用场景等。

 

下文将介绍咱们在内核层面，从可用性，性能，成本等方面进行的优化措施。

 

1. 可用性优化

 

   

可用性 问题表如今三个方面：

 

（1）ES 内核系统健壮性不足 

 

这也是分布式系统共性难题。例如异常查询、压力过载集群容易出现雪崩。集群可扩展性不足，好比集群分片数超10w会出现明显的元数据管理瓶颈。以及集群扩容、节点异常后加回集群，存在节点、多硬盘之间数据不均问题。

 

（2）容灾方案欠缺

 

需保障机房网络故障时可快速恢复服务，天然灾害下防止数据丢失，误操做后快速恢复数据等可靠性、数据安全性问题。

 

（3）系统缺陷

 

另外也包括在运营过程当中发现的一些 ES 系统缺陷 ，好比说 Master 节点堵塞、分布式死锁、滚动重启缓慢等。

 

 

针对上面的问题，在系统健壮性方面，咱们经过服务限流，容忍机器网络故障、异常查询等致使的服务不稳定问题。

 

经过优化集群元数据管理逻辑，提高集群扩展能力一个数量级，支持千级节点集群、百万级分片数。集群均衡方面，经过优化节点、多硬盘间的分片均衡，保证大规模集群的压力均衡。

 

容灾方案 方面，咱们经过扩展 ES 的插件机制实现数据备份和回档，可把 ES 的数据备份到 COS，保障数据安全性；经过管控系统建设支持跨可用区容灾，用户能够按需部署多个可用区，以容忍单机房故障。采用垃圾桶机制，保证用户在欠费、误操做等场景下，集群数据可快速恢复。

 

系统缺陷方面，咱们修复了滚动重启、Master 阻塞、分布式死锁等一系列 Bug。其中滚动重启优化，可加速节点重启速度 5+倍。Master 堵塞问题，咱们在 ES 6.x 版本和官方一块儿作了优化。

 

2. 性能优化

 

性能问题，好比以日志、监控为表明的时序场景，对写入性能要求很是高，写入并发可达 1000w/s。然而咱们发如今带主键写入时，ES 性能会衰减 1+倍。

 

压测场景下发现CPU 存在没法充分利用的状况。一般搜索服务对查询性要求很是高，通常要求 20w QPS, 平均响应时间小于 20ms，而且需尽可能避免 GC、以及执行计划不优等形成的查询毛刺问题。

 

  

为了解决这些问题。写入方面，针对主键去重场景，咱们经过利用段文件上记录的最大最小值进行查询裁剪，加速主键去重的过程，写入性能提高 45%，具体可参考 Lucene-8980[1]。

 

对于压测场景下 CPU 不能充分利用的问题，经过优化 ES 刷新 Translog 时锁粒度，避免资源抢占，提高性能提高 20%，具体可参考ES-45765 /47790[2]。咱们也正在尝试经过向量化执行优化写入性能，经过减小分支跳转、指令 Miss，预期写入性能可提高 1 倍。

 

查询方面，咱们经过优化段文件合并策略，对于非活跃段文件会自动触发合并，收敛段文件数以下降资源开销，提高查询性能。

 

根据每一个段文件上记录的最大最小值进行查询剪枝，提高查询性能 40%。经过 CBO 策略，避免缓存较大开销的 Cache 操做致使产生 10+倍的查询毛刺，具体可参考Lucene-9002[3]。

 

另外还包括优化 Composite 聚合中的性能问题，实现真正的翻页操做，以及优化带排序场景的聚合使得性能提高3-7倍。此外，咱们也在尝试经过一些新硬件来优化性能，好比说英特尔的 AEP、Optane、QAT 等。

 

3. 成本优化

 

 

成本方面主要体如今以日志、监控为表明的时序场景对机器资源的消耗。结合线上典型的日志、时序业务统计数据发现，硬盘、内存、计算资源的成本比例接近 8:4:1。

 

能够得出硬盘、内存是主要矛盾，其次是计算成本。而这类时序类场景有很明显的访问特性，也就是数据具备冷热特性。

 

时序数据访问具备近多远少的特色，好比近 7 天数据的访问量占比可达到 95%以上，而历史数据访问较少，而且一般都是访问统计类信息。

 

 

硬盘成本方面，因为数据具备明显的冷热特性，咱们采用冷热分离架构，使用混合存储的方案来平衡成本和性能。

 

因为历史数据一般只是访问统计信息，咱们采用预计算 Rollup 换取存储和查询性能，相似物化视图。对于彻底不使用历史数据，也能够备份到更廉价的存储系统如 COS。其余一些优化方式包括多盘策略兼容数据吞吐与数据容灾，以及经过生命周期管理等按期删除过时数据等。

 

内存成本 方面，咱们发现特别是大存储机型，存储资源才用了 20% 内存已不足。为了解决内存不足问题，咱们采用 Off-Heap 技术，来提高堆内内存利用率，下降 GC 开销，而且提高单个节点管理磁盘的能力。

 

将内存占比较大的 FST 移到堆外管理，经过堆内存放堆外对象地址，避免堆内外数据拷贝。经过 Java 弱引用机制实现堆外对象内存回收，进一步提高内存使用率。

 

实现 32GB 堆内内存可管理 50 TB 左右磁盘空间，较原生版本有 10 倍提高，而且性能持平，而 GC 优点提高明显。

除了内核层面的优化，在平台层经过管控平台，支持云上服务资源管理、实例实例管理等实现服务托管。方便快捷进行实例建立和规格调整。

 

经过运维支撑平台中的监控系统、运维工具等保障服务质量。并经过正在建设的智能诊断平台发现服务潜在问题，实现了对内外部提供稳定可靠的 ES 服务。

 

 

腾讯内部，咱们主导了 ES 产品开源协同，发现潜在问题，共同优化完善 ES，避免不一样的团队重复踩坑。

 

同时咱们也将优秀的方案积极贡献给社区，和官方及社区的 ES 爱好者们共同推进 ES 的发展。以腾讯 ES 内核研发为表明的团队，截至目前咱们共提交了 60 多个 PR，其中有 70% 被合并，公司内 ES 开源协同 PMC 成员共有 6 位 ES/Lucene 社区 contributor。

 

5、结语

 

 

Elasticsearch 在腾讯内外部普遍应用于日志实时分析、时序数据分析、全文检索等场景。

 

目前单集群规模达到千级节点、万亿级吞吐。经过内核加强版 ES 为你们提供高可靠，低成本，高性能的搜索分析服务。后续咱们仍需在可用性，性能和成本等方面持续优化 ES。

 

好比集群可扩展性不足问题，经过优化集群扩展性支持百万级分片秒级建立 index。ES 的存储成本问题，目前正在研发存储与计算分离方案，进一步缩减成本，提高性能。以及存在使用和维护成本高的问题，后续经过多级分区、智能诊断等提高ES的自动化和故障自愈能力，下降用户使用和维护成本。

 

将来，也会近一步探索 ES 在多维分析领域的其余可能性。持续在大数据领域提供更有价值的搜索分析服务。

 

参考资料：

[1] Lucene-8980：

https://github.com/apache/lucene-solr/pull/884

[2] ES-45765 /47790:

https://github.com/elastic/elasticsearch/pull/45765

[3] Lucene-9002:

https://github.com/apache/lucene-solr/pull/940

看腾讯技术，学云计算知识，就来云+社区