一. 知识储备
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 数据结构
倒排索引，存入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 数据写入
1.5.查询过程
客户端请求发送到集群的某个节点上。集群上的每个节点都是
coordinate node（协调节点）然后协调节点将搜索的请求转发到所有分片上（主分片和副本分片都行）
每个分片将自己搜索出的结果
(doc id)返回给协调节点，由协调节点进行数据的合并、排序、分页等操作，产出最终结果。接着由协调节点根据
doc id去各个节点上拉取实际的document数据，最终返回给客户端。
一个查询语句究竟具有什么样的行为和得到什么结果，主要取决于它到底是处Query还是Filter。两者有很大区别，我们来看下：
Query context 查询上下文这种语句在执行时既要计算文档是否匹配，还要计算文档相对于其他文档的匹配度有多高，匹配度越高，_score 分数就越高
Filter context 过滤上下文 过滤上下文中的语句在执行时只关心文档是否和查询匹配，不会计算匹配度，也就是得分。
1.6.倒排索引查询
通过 Term Index 数据（.tip文件）中的 StartFP 获取指定字段的 FST
通过 FST 找到指定 Term 在 Term Dictionary（.tim 文件）可能存在的 Block
将对应 Block 加载内存，遍历 Block 中的 Entry，通过后缀（Suffix）判断是否存在指定 Term
存在则通过 Entry 的 TermStat 数据中各个文件的 FP 获取 Posting 数据
如果需要获取 Term 对应的所有 DocId 则直接遍历 TermFreqs，如果获取指定 DocId 数据则通过 SkipData 快速跳转
具体参考：https://zhuanlan.zhihu.com/p/395787179
1.7.监控指标
参考：https://blog.csdn.net/pangyemeng/article/details/77524332
二. 查询分析
查询条件：所有自选股票通过stock字段match，通过tags字段嵌套match，查询出来的结果取并集。这个并集用sortkey降序排列，且必需sortkey大于某个值，取前面20条数据。
- 查询是否有缓存，比如{"match": {"stock": "601901"}} 结果会被缓存，然后重复使用吗
不会缓存（ Lucene页缓存除外），filter过滤会有缓存（用bitset缓存文档是否匹配）
- 嵌套查询的原理是什么，有倒排索引吗
嵌套是ES的增强功能，lucene本身没有，原理是会拆分多个文档存储。性能较差，高性能场景不建议使用。
- 查询传进来的自选股票数量最大多少，是否可以控制在一个范围
should条件过多，查询也会比较慢，需要控制要查询的自选股票数
- range查询是否需要回表才能过滤
现在需要，可以把sortkey创建在索引里
- 分页查询的话，每一个分片应该查询多少数据
每一页都会返回20条数据，汇总之后排序再取前20条
- 排序是在哪执行的，每个分片还是调度者。
排序在每个分片上会执行，总体的时候还会执行一遍
数据是：stock，content都是text类型。tags是nested类型
三. 对外沟通
- ES能够直接TO C吗，可以承接多大的流量（目前我们只能抗400QPS），ES集群需要什么样的配置（目前我们是3台物理机（16C 32G 1TB），每台物理机部署2个节点，总共6个节点，一个备份）（master，数据节点，协调节点，预处理节点）
ES可以直接对外提高服务，对于索引的创建和数据查询需要谨慎设计，美团地图搜索大约能够承载3WQPS的查询。
目前的数据体量，千万级数据（新闻，投研，公告），单条数据最大10M，一般可能100KB。
ES查询运行的原理是什么，有类似mysql的 cache buffer吗，如果内存没有，磁盘搜索快吗。
lucene会有页缓存，如果使用filter会有bitset缓存。
- ES query查询和filter查询的区别，为什么网上说filter查询可以用到缓存，这个缓存是如何更新的呢
query：是会计算doc对搜索条件的relevance score，还会根据这个score去排序
filter：只是简单过滤出想要的数据，不计算relevance score，也不排序。更新或者删除文档会更新缓存。
- ES集群搭建有哪些常用优化手段（JVM，连接池，分片，备份，linux参数）
建议jvm内存设置成物理内存的一半，一台物理机只部署一个节点。连接池和linux参数采取默认值即可。
四. 总体优化建议
match操作修改为filter操作，因为没有相关性评分需求
嵌套查询尽可能改成非嵌套模式
ES机器一台物理机只部署一个节点，jvm内存设置成物理内存的一半
sortkey包含在索引里
控制需要查询的自选股数量
content字段比较大，而且不需要被索引，建议分开创建文档结构存储
冷热数据分离，举例：一年前的数据从当前索引剥离
建议使用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年数据的别名
| |
