一. 知识储备

1.0 什么是ES

Elasticsearch 是一个高度可扩展的开源全文搜索和分析引擎。它可以近乎实时地快速存储、搜索和 分析大量数据。它通常用作支持具有复杂搜索功能和要求的应用程序的底层引擎/技术。

Elasticsearch是一个可实时的分布式存储、搜索、分析大量数据的引擎

• Index：Elasticsearch的Index相当于数据库的Table

• Type：这个在新的Elasticsearch版本已经废除（在以前的Elasticsearch版本，一个Index下支持多个Type--有点类似于消息队列一个topic下多个group的概念）

• Document：Document相当于数据库的一行记录

• Field：相当于数据库的Column的概念

• Mapping：相当于数据库的Schema的概念

• DSL：相当于数据库的SQL（给我们读取Elasticsearch数据的API）

1.1字段类型

1.字符串：text和keyword，text会被分词器解析, 生成倒排索引, 支持模糊、精确查询, 不用于排序, 很少用于聚合。keyword不进行分词，直接索引, 支持模糊、精确查询, 支持聚合。

2. 数值类型：byte, short, integer, long，浮点数：float, half_float, scaled_float, double

3. Object类型：Json嵌套json格式，ES索引的时候会扁平化

4. date类型

5. array类型

6. ip类型，range类型

7. nested类型，是一个数组，数组里面是对象

1.2 各类查询

1.2.1 match：模糊搜索，入参会被分词

1.2.2 term：精确查找，入参不会被分词

1.2.3 match_parse: .........

详情参考：https://www.jianshu.com/p/2156335257b6，讲得非常好

1.3 数据结构

image

倒排索引，存入ES的字段会被分词，然后构建倒排索引。

分词存在termDictionary，文档id存在posting中。由于Term Dictionary的词实在太多了，不可能把Term Dictionary所有的词都放在内存中，于是Elasticsearch还抽了一层叫做Term Index，这层只存储 部分 词的前缀，Term Index会存在内存中（检索会特别快），在内存中是以FST（Finite State Transducers）的形式保存的，其特点是非常节省内存。

具体参考：https://cdn.modb.pro/db/115165

1.4 数据写入

image

1.5.查询过程

• 客户端请求发送到集群的某个节点上。集群上的每个节点都是coordinate node （协调节点）

• 然后协调节点将搜索的请求转发到所有分片上（主分片和副本分片都行）

• 每个分片将自己搜索出的结果(doc id) 返回给协调节点，由协调节点进行数据的合并、排序、分页等操作，产出最终结果。

• 接着由协调节点根据 doc id 去各个节点上拉取实际的 document 数据，最终返回给客户端。

一个查询语句究竟具有什么样的行为和得到什么结果，主要取决于它到底是处Query还是Filter。两者有很大区别，我们来看下：

Query context 查询上下文这种语句在执行时既要计算文档是否匹配，还要计算文档相对于其他文档的匹配度有多高，匹配度越高，_score 分数就越高

Filter context 过滤上下文 过滤上下文中的语句在执行时只关心文档是否和查询匹配，不会计算匹配度，也就是得分。

1.6.倒排索引查询

1. 通过 Term Index 数据（.tip文件）中的 StartFP 获取指定字段的 FST

2. 通过 FST 找到指定 Term 在 Term Dictionary（.tim 文件）可能存在的 Block

3. 将对应 Block 加载内存，遍历 Block 中的 Entry，通过后缀（Suffix）判断是否存在指定 Term

4. 存在则通过 Entry 的 TermStat 数据中各个文件的 FP 获取 Posting 数据

5. 如果需要获取 Term 对应的所有 DocId 则直接遍历 TermFreqs，如果获取指定 DocId 数据则通过 SkipData 快速跳转

image

具体参考：https://zhuanlan.zhihu.com/p/395787179

1.7.监控指标

参考：https://blog.csdn.net/pangyemeng/article/details/77524332

二. 查询分析

查询条件：所有自选股票通过stock字段match，通过tags字段嵌套match，查询出来的结果取并集。这个并集用sortkey降序排列，且必需sortkey大于某个值，取前面20条数据。

image

1. 查询是否有缓存，比如{"match": {"stock": "601901"}} 结果会被缓存，然后重复使用吗

不会缓存（ Lucene页缓存除外），filter过滤会有缓存（用bitset缓存文档是否匹配）

2. 嵌套查询的原理是什么，有倒排索引吗

嵌套是ES的增强功能，lucene本身没有，原理是会拆分多个文档存储。性能较差，高性能场景不建议使用。

3. 查询传进来的自选股票数量最大多少，是否可以控制在一个范围

should条件过多，查询也会比较慢，需要控制要查询的自选股票数

4. range查询是否需要回表才能过滤

现在需要，可以把sortkey创建在索引里

5. 分页查询的话，每一个分片应该查询多少数据

每一页都会返回20条数据，汇总之后排序再取前20条

6. 排序是在哪执行的，每个分片还是调度者。

排序在每个分片上会执行，总体的时候还会执行一遍

数据是：stock，content都是text类型。tags是nested类型

image

三. 对外沟通

1. ES能够直接TO C吗，可以承接多大的流量（目前我们只能抗400QPS），ES集群需要什么样的配置（目前我们是3台物理机（16C 32G 1TB），每台物理机部署2个节点，总共6个节点，一个备份）（master，数据节点，协调节点，预处理节点）

ES可以直接对外提高服务，对于索引的创建和数据查询需要谨慎设计，美团地图搜索大约能够承载3WQPS的查询。

2. 目前的数据体量，千万级数据（新闻，投研，公告），单条数据最大10M，一般可能100KB。

3. ES查询运行的原理是什么，有类似mysql的 cache buffer吗，如果内存没有，磁盘搜索快吗。

lucene会有页缓存，如果使用filter会有bitset缓存。

4. ES query查询和filter查询的区别，为什么网上说filter查询可以用到缓存，这个缓存是如何更新的呢

query：是会计算doc对搜索条件的relevance score，还会根据这个score去排序

filter：只是简单过滤出想要的数据，不计算relevance score，也不排序。更新或者删除文档会更新缓存。

5. ES集群搭建有哪些常用优化手段（JVM，连接池，分片，备份，linux参数）

建议jvm内存设置成物理内存的一半，一台物理机只部署一个节点。连接池和linux参数采取默认值即可。

四. 总体优化建议

1. match操作修改为filter操作，因为没有相关性评分需求

2. 嵌套查询尽可能改成非嵌套模式

3. ES机器一台物理机只部署一个节点，jvm内存设置成物理内存的一半

4. sortkey包含在索引里

5. 控制需要查询的自选股数量

6. content字段比较大，而且不需要被索引，建议分开创建文档结构存储

7. 冷热数据分离，举例：一年前的数据从当前索引剥离

8. 建议使用id进行排序和分页，目前的must条件过滤不掉什么数据

一阶段todo：

@廖佳豪

1. 排序逻辑修改

2. termQuery是filter逻辑吗，到ES的语句是什么样的

@李文水

3.执行计划调查

添加"profile": "true", 可查看执行计划

4.嵌套查询是影响性能吗

嵌套查询与match查询，性能相差一倍。60个自选股用match匹配（80）和nested匹配（150ms）。建议stock字段和tags字段揉合加工到一个字段。

5.自选股分布情况，30个和300个差别多大

性能随着自选股数量增多而恶化，30个自选股耗时300ms，60个自选股耗时600ms。建议自选股数量限制在50个

五. 总体思考&实施建议

目标QPS：1.6W，目前ES可抗400QPS。

<colgroup><col width="128"><col width="133"><col width="244"><col width="287"><col width="154"></colgroup>
|

方向

|

子方向

|

现状

|

建议

|

备注

|
|

查询语句

|

根据标签查询资讯

|

query match匹配

|

Filter term匹配

|

标签匹配思考：

一个标签一定需要匹配一次，只能尽可能减少匹配次数和每一次匹配速度。

|
|

一个标签有2个stock match匹配，一个tags nested匹配

|

减少匹配数量，做到一个标签一次匹配

|
|

标签数量最多300个

|

300个标签过多，建议控制在50个

|
|

排序分页

|

sortkey小于XX，from size模式

|

search_after模式

| |
|

ES数据结构

|

搜索字段定义

|

1.Content（contentSegStr） text类型，默认分词器

2.Stock text类型，空格分词器

3.Tags nested类型，tagCode keyword类型，highlight integer类型。

4.sortkey keyword类型

|

1.Content（contentSegStr）不要分词

| |
|

嵌套结构

|

tags为嵌套结构

|

性能比非嵌套结构差一倍，建议换成扁平结构

|

C端尽量扁平，离线尽量多干活。

|
|

数据隔离

|

一个标签可能查询出来上万个文档，但是我们一般可能只需要前面1000个

|

冷热数据隔离，建立一个最近1年数据的别名

| |