1、lucene的底层是倒排索引
2、全文索引说什么
3、lucene
es的分布式基本原理是什么？
es的写数据和读数据的实现原理
答： 写过程：客户端访问协调节点，为master节点，每次写数据，都需要先进入协调节点，再根据hash计算后，路由到对应的primary节点，写入以后，primary节点会将数据同步到replica shard，如果primary和relica节点都已经写入，协调节点会将执行响应返回给客户端
内存buffer、translog文件、os cache 、segment file的关系
过程：
每次写数据，数据都会分别存到内存buffer和translog文件中，
buffer数据每隔1s执行一次fresh操作，将数据刷到os cache中，
translog每30分钟或者到达一定的量就执行commit操作（flush操作）。1、写commit point；2、将os cache数据强刷到磁盘 3、清空translog日志， 同时translog每5秒持久化一次
os cache数据到一定量也会持久化到磁盘 生成新的 segment file
merge：在segment file达到一定程度的时候，会执行merge，将segment file文件合并成大文件，将标记为。del的数据不合并，从而生成大文件segment file
数据写入到segment file 就会建立倒排索引
es的数据丢失问题：
es是准实时的，数据写入1s后，可能会丢失数据，因为有5秒的数据是在buffer，translog buffer，os cache，segmentfile os cache中，没有在磁盘里，机器宕机后，会数据丢失(也就是translog每5秒持久化一次的期间)
可以通过设置，每次写入buffer，都会将translog持久化到磁盘，但是es服务性能会降低
删除数据
是软删除，对数据标记，查询时查询不到
merge：在segment file达到一定程度的时候，会执行merge，将segment file文件合并成大文件，将标记为。del的数据不合并，从而生成大文件segment file
查询操作：
根据查询的条件：
被hash到对应的 分片，对分片使用负载均衡算法，找到对应的replica shrard或者primary shard，对查询的结果返回给协调节点，协调节点将数据返回给客户端
搜索操作：
协调节点会请求各个分片找出对应的document，返回给协调节点，筛查匹配，返回客户端
知道数据被refresh 到 os cache中，客户端就可以搜索到该数据
es数据量大的时候，es如何提高查询的性能
filesystem cache 操作系统的缓存,如果es的segment file远大于filesystem cache，es的性能会大大减低，只有保证大部分查询的数据都在 filesystem cache （操作系统内存），才能保证es的高性能
下面是保持高性能的措施：
架构： 为了保持高性能es的数据最好90%都可以存放在filesystem cache 中，索引es可以存放关键的查询字段，具体的明细可以存放在mysql获取hbase中，维持高性能。如果大量数据需要存在es，则增加集群的机器数，从而提高内存值
同样可以运用在redis中
数据预热：将热点数据先存到 filessytem cache
冷热分离 ，冷数据和热数据分到不同的机器，filesystem cache 实现了人数据的高性能读取
数据模型优化 es不要使用关联查询，如果需要关联，在插入数据的时候，就将关联的数据一并插入
es的生产部署架构，索引的量，分片数
但是如果你确实没干过，也别虚，我给你说一个基本的版本，你到时候就简单说一下就好了
（1）es生产集群我们部署了5台机器，每台机器是6核64G的，集群总内存是320G
（2）我们es集群的日增量数据大概是2000万条，每天日增量数据大概是500MB，每月增量数据大概是6亿，15G。目前系统已经运行了几个月，现在es集群里数据总量大概是100G左右。
（3）目前线上有5个索引（这个结合你们自己业务来，看看自己有哪些数据可以放es的），每个索引的数据量大概是20G，所以这个数据量之内，我们每个索引分配的是8个shard，比默认的5个shard多了3个shard。
1、数据会分布到不同的服务进程，每个服务进程都会分配一个primary sharp和replicashard
2、服务会有一个master，如果哪个服务宕机，会选举其他的服务作为master，如果是replica shard会改成primarily shard，宕机的shard启动后，变为relicate shard
kibana：ES的可视化界面
IK分词器：中文的分词能力较强
solor和ES的区别：
solor多变动的数据，查询效率低 集群的实现，需要依赖zookeeper
es是分布式的，可以自己完成集群，在变动数据的条件下，查询效率没有减低，支持大数据和云计算
es的镜像 daocloud.io/library/elasticsearch:6.5.4
Elasticsearch的结构：
ES服务分为：分词器(维护索引)和存放数据服务
ES的结构说明： 1、ES的服务中可以创建多个索引
2、每个索引分为5片存储，这样可以提高查询的效率
3、每个分片都会至少存放一份备份分片
4、备份分片默认不会帮助检索数据，当ES的检索压力增加时，备份分片会帮助检索数据。
5、备份的分片必须放在不同的服务器中
索引的结构说明：
在ES服务中会创建多个index索引，每个索引下可以创建多个type，每个type下可以创建多个document类似于sql中的表，document下的field类似与sql的字段
索引下有多个type（在7版本以后，取消了type）
restful风格的ES操作语法，主要是在kibana中使用
get请求（查询操作）
语法结构：
ES服务的地址ip：port/索引
ES服务的地址ip：port/索引/doc_id
例子：
post请求（可以实现查询和修改操作），查询的条件存放在请求体
put请求（创建索引）
delete请求
创建索引：设置分片数和备份数
查看索引信息：
删除索引：
ES的field指定类型
查询出的索引信息说明：
创建索引例子说明1：
创建索引例子说明2：
文档的操作
插入数据：
自动生成id插入数据（不推荐）
说明：book为type,novel为document
手动指定id：
修改： 覆盖式修改：
非覆盖式修改，在请求的后面增加_update,请求体中增加具体修改哪些内容
删除文档
语法：delete /index/type/id
java连接ES
创建索引结构
删除索引
插入数据流程：
插入数据：
修改文档
删除文档
批量删除和添加
ES查询：
term和terms：
resful风格查询 term完全匹配，不会对查询的条件进行分词
语法说明：from size 是分页的设置
java方法使用term查询
说明：
searchrequest（index） 创建request对象
searchsourcebuilder（） 设置查询的条件
terms查询，类似于in条件查询
restful风格的查询：
JAVA代码实现
request对象和查询条件的创建和term的实现相同：
matchall查询（查询所有的数据）
match查询的特点：
1、查询的是日期或者数值，会将传入的字符串类型转为相关的格式
2、如果查询的内容是不能被分词的内容（keyword），match查询不会对你的指定查询关键字进行分词
3、如果查询的内容时可以被分词的内容（text），match会将你指定的查询内容根据一定的方式分词，去分词库中匹配指定的内容
4、match的查询，实际底层的实现时term
match查询（根据提高的查询条件查询）
布尔match查询(SQL 的in条件)
mutimatch
id，ids查询（不需要创建查询条件对象searchsourcebuilder）
前缀查询（按前面的查询条件匹配）
fuzzy查询（模糊查询，对查询的条件进行分词，分别进行查询合并）
wildcard查询 类似于like 通过 通配符或者占位符查询实现
- 同配 ？占位 通配符的条件，只要前面的符合要求即可，占位符，要求后面的数据位置刚好和？的数量匹配
range范围查询 （数值的范围查询）
regex查询 （正则表达式查询）
深分页scoll
java实现
释放内存空间
delete-by-query(根据查询的条件删除文档)
java实现
bool查询
查询条件
java查询
restful boot查询
java实现
filter查询（不排序，不算分，有缓存，所有效率比query高）
java实现
聚合查询：
去重计数
range查询
时间范围统计：
ip统计
java实现
统计聚合查询extend
地图经纬度查询
经纬度的索引创建
添加数据
restful实现：
根据距查询
根据巨星查询
多边形查询的java实现
