雷雨中的双桅船

inner_hits文档：http://www.elastic.co/guide/en/elasticsearch/reference/current/search-request-inner-hits.html#parent-child-inner-hits （ElasticSearch 1.50+ 可用）       在使用搜索“has-child”搜索父文档时，一般情况只

本文地址：在有搜索引擎之前，我们查文档常使用顺序匹配。比如要搜索 "我的祖国是花园"，需要在文档中顺序扫描，找到完全匹配的子句。在有了搜索引擎后，我们对查询语句做的处理就不一样了。我们通常会先分词，然后查找对应的词条索引，最后得到评分由高到低的文档列表。我一度以为没法实现完全匹配了，直到一个硬需求的出现。花了一天时间，把完全匹配用搜索引擎的思维整理出来。简要描述实现思路

1. 深入了解推荐引擎组件（基于Apache Mahout和Elasticsearch）http://www.youkuaiyun.com/article/2015-05-14/2824676ES+mahout机器学习做用户筛选、分类和推荐。

在高并发的情况下，我们可以采用nginx反向代理负载均衡到多台Elasticsearch 服务器上。架构图：那么使用nginx有什么好处呢？1. 记录每个API访问请求的日志。（ElasticSearch本身不支持这个功能，只有slowLog和服务日志）2. 支持大量的客户端连接。ES官方的blog中推荐使用keep-alives，在nginx和ES之间使用长连接。

1、升级前的准备工作从Elasticsearch 的官方网站 https://www.elastic.co/downloads/elasticsearch 下载最新版本的Elasticsearch，为了线上方便对数据包的管理，一版选择 .gz.tar 格式或者 .zip 格式文件。 解压缩最新版本文件压缩包到指定目录，备份 config 目录中的 elast

elasticsearch可以通过reroute api来手动进行索引分片的分配。不过要想完全手动，必须先把cluster.routing.allocation.disable_allocation参数设置为true，禁止es进行自动索引分片分配，否则你从一节点把分片移到另外一个节点，那么另外一个节点的一个分片又会移到那个节点。 一共有三种操作，分别为：移动（move），取消（canc

产生Data too large异常再尝试其他查询也是如此经排查原来是ES默认的缓存设置让缓存区只进不出引起的具体分析一下 ES缓存区概述FieldData1 监控FieldData2 Cache配置3 FieldData格式断路器总结1. 产生Data too large异常今早运行查询时，ES返回了如下报错：{ "error": "... CircuitBreakingE

Marvel几乎是所有Elasticsearch用户的标配。以前我常用bigdesk来做ES集群的监控，直到项目需要上线时，方感觉到marvel才是想要的：它可以把观测值和重要事件记录下来！当出问题时打开bigdesk已经迟了，因为我们往往想知道过去的两小时发生了什么造成现在的情况。marvel则不同，它时刻保留观测数据。Marvel保留观测数据的代价是，它默认每天会新建一个index

当我们使用中文分词器的时候，其实也希望它能够支持对于英文的分词。试想，任何一个存储文字的字段都有可能是中英文夹杂的。我们的项目中使用IKAnalyzer作为中文分词器，它在处理文档过程中遇到英文时，利用空格和标点将英文单词取出来，同时也会对其转全小写处理。其实这和真正的英文分词已经很接近了，只有一墙之隔：词干提取。一个真正的英文分词器除了

为ElasticSearch添加HTTP基本认证ES的HTTP连接没有提供任何的权限控制措施，一旦部署在公共网络就容易有数据泄露的风险，尤其是加上类似elasticsearch-head这样友好的前端界面，简直让你的数据瞬间裸奔在黑客的眼皮底下。项目上线前做十万伏特的防护当然不现实，但至少，我们不要裸奔，穿一套比基尼吧。而做一个简单的HTTP认证并不需要从头造轮子，elasticsearc

处理冲突当你使用索引API来更新一个文档时，我们先看到了原始文档，然后修改它，最后一次性地将整个新文档进行再次索引处理。Elasticsearch会根据请求发出的顺序来选择出最新的一个文档进行保存。但是，如果在你修改文档的同时其他人也发出了指令，那么他们的修改将会丢失。很长时间以来，这其实都不是什么大问题。或许我们的主要数据还是存储在一个关系数据库中，而我们只是将为了可以搜索，才将这些数据

一个物理节点上应该有多少个分片？ES官方给予的回答是：每个分片都是一个Lucene实例，它会消耗相应的CPU，IO，内存，文件描述符等等。所以我们应该让每台机器上的分片数尽量的少，如果你是一个RDBMS使用者，你也不希望在一台物理机上部署多个数据库，不是吗？从我的理解上看，分片数和横向拓展性是相关的，分片数多的话，比较便于横向拓展——有新服务器来的时候，我们有多余的

译自ES官方对于硬件设备的说明，原文见： [https://www.elastic.co/guide/en/elasticsearch/guide/current/hardware.html]当你准备把ElasticSearch部署到生产服务器上的时候，这里有一些建议可供你参考。没有什么硬性的规则，ElasticSearch可以在很广泛的应用场景中使用，也可以在各种机器上跑起来。但

译自ES官方对于JVM参数的建议，原文见： https://www.elastic.co/guide/en/elasticsearch/guide/current/heap-sizing.html目录1堆空间的配置方法2把内存留一半给Lucene3别超过32GB！4swap（交换区）是性能终结者

待更新。

遇到了和这位题主类似的问题：假如某文档中已经有三个附件（作为内部对象保存），我想增加第四个附件怎么办？ES本身并没有提供这个功能，需要我们编写script来完成。

一直对ElasticSearch集群的重启有疑惑，因为每个结点重启时，ElasticSearch集群的高可用和自平衡方案会自动在别的结点上复制该重启结点的分片，这定然导致了很大的IO和网络开支。重启一次集群相当于对所有的分片重新部署了一次，而且依次重启结点的时间也很长，需等待集群平衡好了，处于green的状态后才能重启下一个结点。还好ES本身已考虑了这个问题，官方文档中对于集群重启的解

目前文档存储和查询使用的是IKAnalyse分词，IK这种分词算法对于歧义的处理比较完善，比如：”光远大厦“，会分割成”光”，“远“，”远大“，”大厦“。也就是说，它几乎把可能的分词都提供了，这大大提高了用户搜到自己想要的文章的命中率。但今天发现一个问题，在使用queryString来查询这类歧义词的时候，经常会找不到："query_string": {