Elaticsearch环境搭建与基本使用

https://www.elastic.co/guide/en/elasticsearch/client/java-api/6.2/java-search.html

ElasticSearch API 官网

https://blog.csdn.net/yx1214442120/article/details/55102298

环境搭建&＃xff1a; es的安装 &＃43; head可视化操作 &＃43; node.js

https://blog.csdn.net/wzygis/article/details/52055844

es系列学习文章深入浅出&＃xff1a;&＃xff08;es基本操作 &＃43; head使用 &＃43; logstash&＃xff09;

http://www.cnblogs.com/xing901022/p/4993189.html

Elaticsearch REST API常用技巧

https://blog.csdn.net/u012516166/article/details/76643882

面试小结之Elasticsearch篇

https://www.cnblogs.com/wenbronk/p/6432990.html

QueryBuilders中的丰富查询

https://blog.csdn.net/thomas0yang/article/category/6361353

elasticsearch系列文章&＃xff1a;

【基本知识点】&＃xff1a;

https://www.cnblogs.com/duanxz/p/6528161.html

1、如何理解Aggregations需要理解两个概念&＃xff1a;

• 桶(Buckets)&＃xff1a;符合条件的文档的集合&＃xff0c;相当于SQL中的group by。比如&＃xff0c;在users表中&＃xff0c;按“地区”聚合&＃xff0c;一个人将被分到北京桶或上海桶或其他桶里&＃xff1b;按“性别”聚合&＃xff0c;一个人将被分到男桶或女桶

• 指标(Metrics)&＃xff1a;基于Buckets的基础上进行统计分析&＃xff0c;相当于SQL中的count,avg,sum等。比如&＃xff0c;按“地区”聚合&＃xff0c;计算每个地区的人数&＃xff0c;平均年龄等

2、matchQuery 与 termQuery 区别实例&＃xff1a;

matchQuery 检查field是否分词&＃xff0c;分词则分词查询、未分词则直接匹配查询。

termQuery 不分词查询字符串&＃xff0c;再查询&＃xff08;针对keyword类型是&＃xff09; 不分词直接去匹配查询。

3、index、type、id区别&＃xff1f;

index&＃xff0c;有限度的添加index

Index 存储在多个分片中&＃xff0c;其中每一个分片都是一个独立的 Lucene Index。这就应该能提醒你&＃xff0c;添加新 index 应该有个限度&＃xff1a;每个 Lucene Index 都需要消耗一些磁盘&＃xff0c;内存和文件描述符。因此&＃xff0c;一个大的 index 比多个小 index 效率更高&＃xff1a;Lucene Index 的固定开销被摊分到更多文档上了。

在搜索时&＃xff0c;每个分片都需要搜索一次&＃xff0c; 然后 ES 会合并来自所有分片的结果。例如&＃xff0c;你要搜索 10 个 index&＃xff0c;每个 index 有 5 个分片&＃xff0c;那么协调这次搜索的节点就需要合并 5x10&＃61;50 个分片的结果。这也是一个你需要注意的地方&＃xff1a;如果有太多分片的结果需要合并&＃xff0c;或者你发起了一个结果巨大的搜索请求&＃xff0c;合并任务会需要大量 CPU 和内存资源。这是第二个让 index 少一些的理由。

type&＃xff0c;是允许在一个index中存储的多种数据类型&＃xff1b;

type 允许我们在一个 index 里存储多种类型的数据&＃xff0c;这样就可以减少 index 的数量了。在使用时&＃xff0c;向每个文档加入 _type 字段&＃xff0c;在指定 type 搜索时就会被用于过滤。使用 type 的一个好处是&＃xff0c;搜索一个 index 下的多个 type&＃xff0c;和只搜索一个 type 相比没有额外的开销 —— 需要合并结果的分片数量是一样的。

只在某个 type 里存在的字段&＃xff0c;在其他没有该字段的 type 中也会消耗资源。这是 Lucene Index 带来的常见问题&＃xff1a;它不喜欢稀疏。由于连续文档之间的差异太大&＃xff0c;稀疏的 posting list 的压缩效率不高。

得分是由 index 内的统计数据来决定的。也就是说&＃xff0c;一个 type 中的文档会影响另一个 type 中的文档的得分。 

这意味着&＃xff0c;只有同一个 index 的中的 type 都有类似的映射 (mapping) 时&＃xff0c;才应该使用 type。否则&＃xff0c;使用多个 type 可能比使用多个 index 消耗的资源更多。

id&＃xff1a; 类似主键&＃xff0c; 不手动添加&＃xff0c;es会自动为文档生成一个id&＃xff1b; 建议指定有规律的id&＃xff0c;以提升检索效率&＃xff1b;