我的博客

需求：比如有一个网站，记录下了每次请求的访问的耗时，需要统计tp50，tp90，tp99tp50：50%的请求的耗时最长在多长时间tp90：90%的请求的耗时最长在多长时间tp99：99%的请求的耗时最长在多长时间新增3个field latency耗时PUT /website{ "mappings": { "logs": { "properties": { "latency": {

cardinality=count(distinct)，5%的错误率，性能在100ms左右，如何对cardinality进行优化呢？1、precision_threshold优化准确率和内存开销GET /tvs/sales/_search{ "size" : 0, "aggs" : { "distinct_brand" : { "cardinality" : { "field" : "brand",

es去重使用cartinality metric，对每个bucket中的指定的field进行去重，取去重后的count，类似于count(distcint)date_histogram统计每个月的销售电视数量，并且对品牌进行去重GET /tvs/sales/_search{ "size" : 0, "aggs" : { "months" : { "date_histogram": { "field": "sold_date",

1、画图讲解易并行聚合算法：max有些聚合分析的算法，是很容易就可以并行的，比如说max有些聚合分析的算法，是不好并行的，比如说，count(distinct)，并不是说，在每个node上，直接计算出一些distinct value，就可以的，因为数据可能会很多，不同node上可能有重复的值对于不易并行的局和分析，es会采取近似聚合的方式，就是采用在每个node上进行近估计的方式，得到最终的结论，count(distinct)，100万，估计在105万/95万 --> 5%左右的错误率近

先以颜色分组，分组后再以品牌倒序分组，并计算分组后每个品牌的平均价格GET /tvs/sales/_search { "size": 0, "aggs": { "group_by_color": { "terms": { "field": "color" }, "aggs": { "group_by_brand": { "terms": { "field": "brand",

之前的排序，是按照每个bucket的doc_count降序来排的GET /tvs/sales/_search { "size": 0, "aggs": { "group_by_color": { "terms": { "field": "color" }, "aggs": { "avg_price": { "avg": { "field": "price"

在聚合中进行过滤查询品牌是长虹的电视，并且过滤售卖日期在150天内，然后统计平均价格，再过滤售卖日期在140天内，然后统计平均价格，再过滤售卖日期在130天内，然后统计平均价格.GET /tvs/sales/_search { "size": 0, "query": { "term": { "brand": { "value": "长虹" } } }, "aggs": { "recent_150d": { "f

过滤+聚合先过滤价格在1200以上的电视，然后再求平均价格GET /tvs/sales/_search { "size": 0, "query": { "constant_score": { "filter": { "range": { "price": { "gte": 1200 } } } } }, "aggs": { "avg_price

aggregation一个概念scope：一个聚合操作，必须在query的搜索结果范围内执行现在想有两个结果，一个结果，是基于query搜索结果来聚合的; 一个结果，是对所有数据执行聚合的GET /tvs/sales/_search { "size": 0, "query": { "term": { "brand": { "value": "长虹" } } }, "aggs": { "single_brand_avg_p

实际上来说，我们之前学习的搜索相关的知识，完全可以和聚合组合起来使用对于sql分组，既有搜索又有分组select count(*)from tvs.saleswhere brand like "%长%"group by pricees aggregation有一个概念scope：任何的聚合，都必须在搜索出来的结果数据中进行，搜索结果，就是聚合分析操作的scope搜索品牌是小米的电视，并根据颜色分组GET /tvs/sales/_search { "size": 0, "query

根据日期区间分组，quarter根据季度分组，统计每个季度的总金额，继续根据品牌分组，并统计每组的总金额GET /tvs/sales/_search { "size": 0, "aggs": { "group_by_sold_date": { "date_histogram": { "field": "sold_date", "interval": "quarter", "format": "yyyy-MM-dd",

date_histogram，按照我们指定的某个date类型的日期field，以及日期interval，按照一定的日期间隔，去划分bucketdate interval = 1m， 一个月2017-01-01~2017-01-31，就是一个bucket2017-02-01~2017-02-28，就是一个bucket然后会去扫描每个数据的date field，判断date落在哪个bucket中，就将其放入那个bucket2017-01-05，就将其放入2017-01-01~2017-01-31，

histogram：类似于terms，也是进行bucket分组操作，接收一个field，按照这个field的值的各个范围区间，进行bucket分组操作"histogram":{ "field": "price", "interval": 2000}interval：2000，划分范围，02000，20004000，40006000，60008000，8000~10000，buckets去根据price的值，比如2500落在哪个区间内，落到20004000，此时就会将这条数据放入20004

count：bucket，terms，自动就会有一个doc_count，就相当于是countavg：avg aggs，求平均值max：求一个bucket内，指定field值最大的那个数据min：求一个bucket内，指定field值最小的那个数据sum：求一个bucket内，指定field值的总和一般来说，90%的常见的数据分析的操作，metric，无非就是count，avg，max，min，sumsum求总和，就可以拿到一个颜色下的所有电视的销售总额GET /tvs/sales/_searc

从颜色到品牌进行下钻分析：每种颜色的平均价格，以及找到每种颜色每个品牌的平均价格我们可以进行多层次的下钻比如说，现在红色的电视有4台，同时这4台电视中，有3台是属于长虹的，1台是属于小米的红色电视中的3台长虹的平均价格是多少？红色电视中的1台小米的平均价格是多少？下钻的意思是，已经分了一个组了，比如说颜色的分组，然后还要继续对这个分组内的数据，再分组，比如一个颜色内，还可以分成多个不同的品牌的组，最后对每个最小粒度的分组执行聚合分析操作，这就叫做下钻分析es下钻分析，就要对bucket进行多层嵌

GET /tvs/sales/_search{ "size" : 0, "aggs": { "colors": { "terms": { "field": "color" }, "aggs": { "avg_price": { "avg": { "field": "price" }

1、家电卖场案例背景以一个家电卖场中的电视销售数据为背景，来对各种品牌，各种颜色的电视的销量和销售额，进行各种各样角度的分析创建索引并手动设置映射PUT /tvs{ "mappings": { "sales": { "properties": { "price": { "type": "long" }, "color": { "type": "keyword" }, "brand": { "type": "keywor

两个核心概念：bucket和metricbucket：一个数据分组city name北京 小李北京 小王上海 小张上海 小丽上海 小陈基于city划分buckets划分出来两个bucket，一个是北京bucket，一个是上海bucket北京bucket：包含了2个人，小李，小王上海bucket：包含了3个人，小张，小丽，小陈按照某个字段进行bucket划分，那个字段的值相同的那些数据，就会被划分到一个bucket中有一些mysql的sql知识的话，聚合，首先第一步就是分组，对每个组

热更新每次都是在es的扩展词典中，手动添加新词语，很坑（1）每次添加完，都要重启es才能生效，非常麻烦（2）es是分布式的，可能有数百个节点，你不能每次都一个一个节点上面去修改es不停机，直接我们在外部某个地方添加新的词语，es中立即热加载到这些新词语热更新的常用方案（1）修改ik分词器源码，然后手动支持从mysql中每隔一定时间，自动加载新的词库（2）基于ik分词器原生支持的热更新方案，部署一个web服务器，提供一个http接口，通过modified和tag两个http响应头，来提供词语的热

1、ik配置文件ik配置文件地址：es/plugins/ik/config目录IKAnalyzer.cfg.xml：用来配置自定义词库main.dic：ik原生内置的中文词库，总共有27万多条，只要是这些单词，都会被分在一起quantifier.dic：放了一些单位相关的词suffix.dic：放了一些后缀名surname.dic：中国的姓氏stopword.dic：英文停用词ik原生最重要的两个配置文件1.main.dic：包含了原生的中文词语，会按照这个里面的词语去分词2.stop

之前大家会发现，字段全部是用英文其实我们用来进行搜索的，绝大多数，都是中文应用，很少做英文的默认分词器standard：没有办法对中文进行合理分词的，只是将每个中文字符一个一个的切割开来，比如说中国人 --> 中 国 人在搜索引擎领域，比较成熟和流行的中文分词起，就是ik分词器中国人很喜欢吃油条standard：中 国 人 很 喜 欢 吃 油 条ik：中国人 很 喜欢 吃 油条1、在elasticsearch中安装ik中文分词器因为使用es的版本是5.6.0（1）git clone

搜索的时候，可能输入的搜索文本会出现误拼写的情况doc1: hello worlddoc2: hello java搜索：hallo worldfuzzy搜索技术 --> 自动将拼写错误的搜索文本，进行纠正，纠正以后去尝试匹配索引中的数据新增text字段POST /my_index/my_type/_bulk{ "index": { "_id": 1 }}{ "text": "Surprise me!"}{ "index": { "_id": 2 }}{ "text": "That

我们可以做到自定义一个function_score函数，自己将某个field的值，跟es内置算出来的分数进行运算，然后由自己指定的field来进行分数的增强给所有的帖子数据增加follower数量POST /forum/article/_bulk{ "update": { "_id": "1"} }{ "doc" : {"follower_num" : 5} }{ "update": { "_id": "2"} }{ "doc" : {"follower_num" : 10} }{ "upda

之前两节课，我觉得已经很了解整个es的相关度评分的算法了，算法思想，TF/IDF，vector model，boolean model; 实际的公式，query norm，query coordination，boost对相关度评分进行调节和优化的常见的4种方法1、query-time boost设置某个field的权重,GET /forum/article/_search{ "query": { "bool": { "should": [ {

深入讲解TF/IDF算法，在lucene底层，到底进行TF/IDF算法计算的一个完整的公式是什么？0、boolean modelquery: hello world"match": { "title": "hello world"}普通multivalue搜索，转换为bool搜索，boolean model"bool": { "should": [ { "match": { "title": "hello" } }, { "natch": {

1、boolean model类似and这种逻辑操作符，先过滤出包含指定term的docquery “hello world” --> 过滤 --> hello / world / hello & worldbool --> must/must not/should --> 过滤 --> 包含 / 不包含 / 可能包含doc --> 不打分数 --> 正或反 true or false --> 为了减少后续要计算的doc的数量，提升性能2、T

1、ngram和index-time搜索推荐原理edge_ngram和ngram是ElasticSearch自带的两个分词器，一般设置索引映射的时候都会用到，设置完步长之后，就可以直接给解析器analyzer的tokenizer赋值使用。什么是ngram在索引时准备数据意味着要选择合适的分析链，这里部分匹配使用的工具是 n-gram 。可以将 n-gram 看成一个在词语上 滑动窗口 ， n 代表这个 “窗口” 的长度。如果我们要 n-gram quick 这个词 —— 它的结果取决于 n 的选择长度

搜索推荐，search as you type，搜索提示，解释一下什么意思hello w --> 搜索hello worldhello wehello winhello windhello doghello cathello w -->hello worldhello wehello winhello wind这就是搜索推荐的功能比如百度搜elas -->elasticsearchelasticsearch权威指南重建索引my_indexPUT my

1、前缀搜索C3D0-KD345C3K5-DFG65C4I8-UI365C4I8-UC365搜索C3 --> 上面这两个都搜索出来 --> 根据字符串的前缀去搜索手动建的新索引PUT my_index{ "mappings": { "my_type": { "properties": { "title": { "type": "keyword" } } } }}填充数据PU

match和phrase match(proximity match)区别match --> 只要简单的匹配到了一个term，就可以理解将term对应的doc作为结果返回，扫描倒排索引，扫描到了就okphrase match --> 首先扫描到所有term的doc list; 找到包含所有term的doc list; 然后对每个doc都计算每个term的position，是否符合指定的范围; 根据给定的slop，需要进行复杂的运算，来判断能否通过slop移动，匹配一个docmatch qu

召回率比如你搜索一个java spark，总共有100个doc，能返回多少个doc作为结果，就是召回率，recall精准度比如你搜索一个java spark，能不能尽可能让包含java spark，或者是java和spark离的很近的doc，排在最前面，precision直接用match_phrase短语搜索，会导致必须所有term都在doc field中出现，而且距离在slop限定范围内，才能匹配上match phrase，proximity match，要求doc必须包含所有的term，才能作

slop的含义是什么？query string，搜索文本中的term，要经过几次移动才能与一个document匹配，这个移动的次数，就是slop实际举例，一个query string经过几次移动之后可以匹配到一个document，然后设置slophello world, java is very good, spark is also very good.搜索java spark，使用match phrase，时搜不到的如果我们指定了slop，那么就允许java spark进行移动，来尝试与doc

1、什么是近似匹配两个句子java is my favourite programming language, and I also think spark is a very good big data system.java spark are very related, because scala is spark's programming language and scala is also based on jvm like java.match query，搜索java spark.

第二个方法：使用原生multi_match+cross_fields解决跨多个字段搜索唯一标识GET /forum/article/_search{ "query": { "multi_match": { "query": "Peter Smith", "type": "cross_fields", "operator": "and", "fields": ["author_first_name", "author_last_name"]

用most_fields策略，去实现cross-fields搜索，有3大弊端，而且搜索结果也显示出了这3大弊端，如何解决这些弊端呢？第一个办法：用copy_to，将多个field组合成一个field问题其实就出在有多个field，有多个field以后，我们只要想办法将一个标识跨在多个field的情况，合并成一个field即可。比如说，一个人名，本来是first_name，last_name，现在合并成一个full_name。新增field映射new_author_first_name、new_auth

cross_fields类型采用了一种以词条为中心(Term-centric)的方法，这种方法和best_fields及most_fields采用的以字段为中心(Field-centric)的方法有很大的区别。它将所有的字段视为一个大的字段，然后在任一字段中搜索每个词条。cross-fields搜索，一个唯一标识，跨了多个field。比如一个人，标识，是姓名；一个建筑，它的标识是地址。姓名可以散落在多个field中，比如first_name和last_name中，地址可以散落在country，provi

从best-fields换成most-fields策略best-fields策略，主要是说将某一个field匹配尽可能多的关键词的doc优先返回回来most-fields策略，顾名思义，就是匹配词干的字段数越多，分数越高，优先返回，也可设置权重boost。下面是简易公式（详细评分算法请参考：http://m.blog.youkuaiyun.com/article/details?id=50623948）： 下面是简易公式（详细评分算法请参考：http://m.blog.youkuaiyun.com/article/deta

GET /forum/article/_search{ "query": { "multi_match": { "query": "java solution", "type": "best_fields", "fields": [ "title^2", "content" ], "tie_breaker": 0.3,

1、搜索title或content中包含java beginner的帖子GET /forum/article/_search{ "query": { "dis_max": { "queries": [ { "match": { "title": "java beginner" }}, { "match": { "content": "java beginner" }}

1、为帖子数据增加content字段POST /forum/article/_bulk{ "update": { "_id": "1"} }{ "doc" : {"content" : "i like to write best elasticsearch article"} }{ "update": { "_id": "2"} }{ "doc" : {"content" : "i think java is the best programming language"} }{ "update"