三劫散仙

Elasticsearch 是基于 Lucene 的世界范围内最流行的全文检索框架，其文档相似度算法包含 TF/IDF 和 BM25，从 ES 5.0开始 BM25 算法已经成为 ES 默认的相似度评分模块。在实际工作中，搜索和推荐业务会比较依赖全文检索框架，很多情况下框架的默认的评分机制并不能很好的满足我们的需求，所以需要结合一些自定义评分策略来完善我们的 rank 效果。

ES 的主查询评分模式分为两种，是信息检索领域的重要算法： TF-IDF 算法 和 BM25 算法。Elasticsearch 从版本 5.0 开始引入了 BM25 算法作为默认的文档评分（relevance scoring）算法。在此之前，Elasticsearch 使用的是 TF-IDF 算法作为默认的文档评分算法。从版本 5.0 起，BM25 算法取代了 TF-IDF，成为了默认的算法，用于计算文档与查询之间的相关性得分。

Constant Score Query 也是属于 ES 复合查询中的一种，可以将一个 query 的结果的 score 评分给设定成一个常量值，并将结果集缓存起来，与 Boolean filter query 的区别，就在于 filter 的结果评分是 0，不支持设置，除此之外没有区别了，两者的性能是一样的。

Boolean Query在之前已经介绍过了，今天来看一下 Boosting Query 用法，其实也非常简单，总结起来就一句话，对不期待的查询关键词进行相关性降分。

通过前面的文章，我们已经知道在elasticsearch中每个shard每隔1秒都会refresh一次，每次refresh都会生成一个新的segment，按照这个速度过不了多久segment的数量就会爆炸，所以存在太多的segment是一个大问题，因为每一个segment都会占用文件句柄，内存资源，cpu资源，更加重要的是每一个搜索请求都必须访问每一个segment，这就意味着存在的segment...

本次搭建的是一个三节点的集群（一）es的安装（1）下载安装包https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-5.6.4.tar.gz（2）解压到指定目录（3）进入根目录，修改config/elasticsearch.yml文件，清空内容，添加如下配置cluster.na

在ElasticSearch里面备份策略已经比较成熟了目前在ES5.x中备份支持的存储方式有如下几种：fs //本地挂载的盘url //网络协议存储支持http,https,ftprepository-s3 //亚马逊repository-hdfs //HDFSrepository-azure //微软repository-gcs //googl...

使用java开发项目时，log日志一般都是应用程序必不可少的一部分，大部分情况下我们的log文件都是普通的文本信息，通过level来标记不同级别的日志。日志的目的，主要还是为了出现问题时有追踪的途径，方便从里面查出原因，在数据量小的时候通过linux上的各种shell命令如awk，grep就能快速查询或者做一些简单的统计，当数据量的时候，而且程序本身还是分布式的时候，这种方式就有点费劲。比

前面文章介绍了，在es里面的几种数据组织关系，包括array[object]，nested，以及今天要说的Parent-Child。Parent-Child与Nested非常类似，都可以用来处理一对多的关系，如果多对多的关系，那就拆分成一对多在处理。前面提到nested的缺点是对数据的更新需要reindex整个nested结构下的所有数据，所以注定了它的使用场景一定是查询多更新少的场景，如

在传统的数据库里面，对数据关系描述无外乎三种，一对一，一对多和多对多的关系，如果有关联关系的数据，通常我们在建表的时候会添加主外键来建立数据联系，然后在查询或者统计时候通过join来还原或者补全数据，最终得到我们需要的结果数据，那么转化到ElasticSearch里面，如何或者怎样来处理这些带有关系的数据。我们都知道ElasticSearch是一个NoSQL类型的数据库，本身是弱化了对关系

Elasticsearch作为一个成熟的开源框架，对主流的多种客户端语言都支持，比如Java，JavaScript ，PHP，.Net，Python，Ruby，CURL当然还有一些小众的语言，虽然es官网没支持，但是个人开发者也有一些开源的，具体的可在es官网clients地址查看：https://www.elastic.co/guide/en/elasticsearch/client/i

在es查询的时候我们可以控制Preference，来完成特定shard或节点上的数据查询，默认情况下查询是随机的。假如现在我们有一份索引5个shard和3个副本，当一个查询请求过来的时候，查询操作如何执行，在没有使用路由的情况下5个shard的数据肯定都要查询，然后查询5个shard时候到底查的是主shard还是replia都是随机的。通过偏好查询，我们可以有更多的选择定制，比如我

在ElaticSearch里面，路由功能算是一个高级用法，大多数时候我们用的都是系统默认的路由功能，我们知道一个es索引可以分多个shard和每个shard又可以有多个replia，那么现在思考一个问题，我们添加进去的数据，是如何分布在各个shard上面的，而查询时候它是又怎么找到特定的数据呢。默认情况下，索引数据的分片规则，是下面的公式：shard_num = hash(_routi

最近线上的es报了一个异常，核心信息如下：No mapping found for [k1.k2.time] in order to sort on我们的es索引是嵌套索引，上面的这个异常大致意思是说在某个shard里面嵌套结构里面 k1.k2.time这个字段不存在数据，所以排序失败。我们知道在ES里面可以分shard和索引，大多数时候我们es索引都是自动按某个规则创建的，比

我们都知道Elasticsearch是一个全文检索引擎，那么它是如何实现快速的检索呢？传统的数据库给每个字段都存储成一个单个值，对于全文检索而言，这样的存储是低效的。举个例子，我有一个大文本字段，存到数据库里面只能是一个值，如果想要检索这个大文本字段里面的任何一个词，数据库如何实现？ 只能通过like模糊查询来实现，先不说性能低，这对于一个搜索引擎是远远不够的。针对上面数据库的不足，所以才出现了L...

上一篇文章中介绍了Elasticsearch中是如何搜索文本的，同时也简述了在es里面索引数据结构的特点不可变性。索引不可变性的缺点限制了单个索引存储的最大数据量以及更新的频次，所以es面临的问题是如何解决倒排索引不可更新的特点而同时仍然保持不可变特性带来的好处。答案就是使用多个索引代替原来的每次重写整个索引，es里面采用方式是增加新的索引来反映最近的变化，然后查询的时候一次查询所有的倒排索引，从...

通过前面两篇文章的介绍，我们大概已经知道了 Elasticsearch处理数据的流程，其中在Elasticsearch和磁盘之间还有一层称为FileSystem Cache的系统缓存，正是由于这层cache的存在才使得es能够拥有更快搜索响应能力。我们都知道一个index是由若干个segment组成，随着每个segment的不断增长，我们索引一条数据后可能要经过分钟级别的延迟才能被搜索，为什么有种...

最近线上的es查询的某个微服务接口，报了一个异常，如下：nested: SearchParseException[No mapping found for [count] in order to sort on];Caused by: SearchParseException[failed to parse search source 直接从异常上看，可以得到是因为mapping里面...

es的api除了提供了基本的curd操作外，还有两个针对批量的操作分别是：1，批量的读取操作（mget）2，批量的写入操作（bulk）本篇文章先介绍mget的用法Multi Get api 简称（mget）它允许我们一次get大量的document，与get单条数据的api get方法类似，mget查询是基于index，type（可选），id三个条件进行的，比如我们可以一次mget 50条数据，这...

前面的文章提到过es默认的from+size的分页方式返回的结果数据集不能超过1万点，超过之后返回的数据越多性能就越低。这是因为es要计算相似度排名，需要排序整个整个结果集，假设我们有一个index它有5个shard，现在要读取1000到1010之间的这10条数据，es内部会在每个shard上读取1010条数据，然后返回给计算节点，这里有朋友可能问为啥不是10条数据而是1010条呢？这是因为某个s...

在elasticsearch里面给index起一个aliases（别名）能非常优雅的解决两个索引无缝切换的问题，这个功能在某些场景下非常使用。比如电商的核心商品索引库，除了实时增量数据外，每天都要重建一遍索引，避免index里面的数据和db里面的数据不一致，因为index分shard了，所以要一个一个的shard做全量替换，直到所有的shard替换完毕，才能宣布重建成功。整个过程其实还是风险挺大的...

我们都知道es是一个分布式的存储和检索系统，在存储的时候默认是根据每条记录的_id字段做路由分发的，这意味着es服务端是准确知道每个document分布在那个shard上的。相对比于CURD上操作，search一个比较复杂的执行模式，因为我们不知道那些document会被匹配到，任何一个shard上都有可能，所以一个search请求必须查询一个索引或多个索引里面的所有shard才能完整的查询到我们...

上篇文章介绍了在es里面批量读取数据的方法mget，本篇我们来看下关于批量写入的方法bulk。bulk api可以在单个请求中一次执行多个索引或者删除操作，使用这种方式可以极大的提升索引性能。bulk的语法格式是：action and meta_data \noptional source \naction and meta_data \noptional source \nactio...

（一）scroll的介绍有时候我们可能想要读取整个es索引的数据或者其中的大部分数据，来重建索引或者加工数据，相信大多数人都会说这很简单啊直接用from+size就能搞定，但实际情况是from+size的分页方法不适合用于这种全量数据的抽取，越到后面这种方法的性能就越低，这也是es里面为什么限制了单次查询结果的数据不能超过1万条数据的原因。es里面提供了scroll的方式来全量读取索引数据其与数据...

作为一个成熟的框架elasticsearch里面提供丰富的操作数据的api，本篇我们就来学习一下在es中更新数据的几种方式。（一）更新文档（1）部分更新：java api：` HashMap<String,Object> data=new HashMap<>(); data.put("name","woshigcs"); data...

上篇文章提到过，在elasticsearch和磁盘之间还有一层cache也就是filesystem cache，大部分新增或者修改，删除的数据都在这层cache中，如果没有flush操作，那么就不能100%保证系统的数据不会丢失，比如突然断电或者机器宕机了，但实际情况是es中默认是30分钟才flush一次磁盘，这么长的时间内，如果发生不可控的故障，那么是不是必定会丢失数据呢？很显然es的设计者早就...

上篇文章了，写了使用spark集成es框架，并向es写入数据，虽然能够成功，但从集成度上来讲肯定没有官网提供的ES-Hadoop框架来的优雅，今天我们就来认识一下ES-Hadoop这个框架。我们都知道Hadoop是标准的大数据生态代表，里面有非常多的组件来处理不同类型或者场景下的数据，Hadoop的基础组件是YARN,HDFS,MapReduce，我们都知道HDFS是可靠的分布式存储系统，

前面关于es的文章基本上都是添加，修改，更新操作，删除的例子仅仅有根据id删除单条数据的。但作为一个重度使用es的用户，我们肯定得了解所有相关删除操作的命令，才能更加方便的使用和维护es。通常情况下，删除操作是非常敏感的，这一点不论在关系型数据库，还是nosql数据库都是同样的道理。在es里面也是如此，虽然es大部分时候都是读多写少的系统。在es里面常用的删除需求，通常如下：

ElasticSearch里面的聚合机制非常灵活和强大，今天我们来看下如何在ElasticSearch里面实现分组后，根据sum值进行排序？类似的数据库SQL如下：select id,sum(c1) as c1 , sum(c2) as c2 from table1 group id order by c1 desc, c2 asc这是一个比较常见的统计需求，在es也能比较轻松的实现

最近收集的两个搜索的case，如下： 案例一： 使用 A关键词：“中国诚通控股公司”搜索，不能搜到 B结果“中国诚通控股集团有限公司” 从关键词字面上看，确实不应该出现这种问题，因为A的关键词完全被B包含，如果说搜索B，搜不到A到还可以接受，因为 在关键词越长的情况下，term之间是AND的关系，这样返回结果集就越少，这一点从Google或者其他电商的搜索都可以得到测试

当我们在处理搜索业务时候，需求往往是灵活多变的，有时候我们需要精确匹配，有时候我们又需要全文检索，而有时候，我们又想匹配度高而且还能全文检索，这似乎是精确匹配和模糊匹配一个妥协的策略，没错这就是搜索引擎出现的目的，以往的数据库是没法解决这种问题的，数据库只能回答有，没有，存在，不存在，并不能在有和没有之间做一个完美的妥协，比如说能把最匹配最相关的结果放在topN，仅靠like模糊查询是解决不了这种

前言： 在Lucene4.x之后，出现一个重大的特性，就是索引支持DocValues，这对于广大的solr和elasticsearch用户，无疑来说是一个福音，这玩意的出现通过牺牲一定的磁盘空间带来的好处主要有两个： （1）节省内存 （2）对排序，分组和一些聚合操作时能够大大提升性能 下面来详细介绍下DocValue的原理和使用场景 （一）什么是DocValues？ 

由于Solr和ElasticSearch都是基于Lucene构建的，所以他们之间有很大程度的相似性，故而他们的一些优化策略基本也是通用的，面对越来越多的海量数据，如何优化全量索引的写入性能呢？ 散仙简单总结了下面几个方向的优化策略，如有疑问，欢迎拍砖。 （一）硬件优化： （1）CPU加大，有利于并发写入 （2）内存提升，加大写入缓冲 （3）磁盘IO，使用SSD或者IO读写更

es支持大多数java里面的数据类型： （一）核心数据类型： （1）string： 默认会被分词，一个完整示例如下 Java代码  "status": {            "type":  "string", //字符串类型           "index": "analyzed"//分词，不分词是：not_analyzed ，设置成no

首先要明确一点，ElasticSearch是基于Lucene的，它的很多基础性组件，都是由Apache Lucene提供的，而es则提供了更高层次的封装以及分布式方面的增强与扩展。 所以要想熟练的掌握的关于es中分词方面的知识，一定得先从Lucene抓起，否则只会是丈二和尚摸不着头脑，当然我们大多数开发者只关注于怎么用，偏底层的东东，也没有太多时间去深究，这也有情可原，遇到问题再去探究，也

ELK是什么？ E=ElasticSearch ，一款基于的Lucene的分布式搜索引擎，我们熟悉的github，就是由ElastiSearch提供的搜索，据传已经有10TB+的数据量。 L=LogStash ， 一款分布式日志收集系统，支持多输入源，并内置一些过滤操作，支持多输入元 K=Kibana ， 一款配合ElasticSearch的web可视化界面，内置非常各种查询，聚合操作

以前经常有人问散仙，如何学好搜索？ 其实这个问题很具有代表性，你可以归纳为一类问题？ 其实，散仙在以前博客的中，也有总结过，大家可以点击这个链接再看一下。 本篇散仙要介绍的内容，是关于如何用Luke查看ElasticSearch的索引，那么为什么会写如此一篇文章呢？ 相信学过或了解过全文检索的朋友们，都知道，搜索的核心的就是倒排索引，之所以我们能够使用Google在互联网的海量的数

散仙在上篇文章中，介绍了关于ElasticSearch基本的增删改查的基本粒子，本篇呢，我们来学下稍微高级一点的知识： （1）如何在ElasticSearch中批量提交索引 ？ （2）如何使用高级查询（包括，检索，排序，过滤，分页） ？ （3）如何组合多个查询 ？ （4）如何使用翻页深度查询 ？ （5）如何使用基本的聚合查询 ？ （一）首先，我们思考下，

散仙，在上篇文章对ElasticSearch整体入门作了个介绍，那么本篇我们来看下，如何安装，部署es，以及如何安装es的几个比较常用的插件. es的安装和部署，是非常简单方便的，至少这一点散仙在es和solr之间，能够很明显的体现出来，solr的安装是需要依赖servlet容器，比如jetty，或者tomcat等，在下载完毕后，需要拷贝solr的安装部分到web容器里，然后稍作配置，即可

上篇文章散仙介绍了ElasticSearch的入门安装和使用，那么本篇我们来看下，如何使用java api来和ElasticSearch进行交互，简单点说，就是实现一个增删改查，来找找入门的感觉。 在这里散仙解释一下，为啥选择使用Java api来作为一个入门的例子，主要原因如下： （1）Java在大中小型企业级应用非常广泛，而且ES本身就是包装了使用java编写的Apache L