关于elasticsearch的一些问题总结

1.什么是elasticsearch？

    ElasticSearch是一个基于Lucene的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎，基于RESTful web接口。Elasticsearch是用Java开发的，并作为Apache许可条款下的开放源码发布，是当前流行的企业级搜索引擎。设计用于云计算中，能够达到实时搜索，稳定，可靠，快速，安装使用方便。-----百度百科

2.为什么会用到elasticsearch？

    涉及到like的大数据量模糊查询，如果是直接对数据库进行查询的话，由于like模糊查询无法对数据列应用索引，所以需要一条条字符串进行比对查询，效率非常低下。所以在Java中，解决大数据量的模糊查询，就会用到建立索引库，全文检索的查询技术。

3.Elasticsearch中的几个核心概念

   全文检索：检索文本中每个词，与搜索项进行比对

    全文索引：采用分词器，对文本每个词进行切分，建立词条，方便进行查找

    接近实时（NRT）：Elasticsearch是一个接近实时的搜索平台。这意味着，从索引一个文档直到这个文档能够被搜索到有一个轻微的延迟（通常是1秒）。

    索引（index）：一个索引就是一个拥有几分相似特征的文档的集合。比如说，你可以有一个客户数据的索引，另一个产品目录的索引，还有一个订单数据的索引。一个索引由一个名字来标识（必须全部是小写字母的），并且当我们要对对应于这个索引中的文档进行索引、搜索、更新和删除的时候，都要使用到这个名字。在一个集群中，如果你想，可以定义任意多的索引。

    倒排索引：也常被称为反向索引、置入档案或反向档案，是一种索引方法，被用来存储在全文搜索下某个单词在一个文档或者一组文档中的存储位置的映射。它是文档检索系统中最常用的数据结构。通过倒排索引，可以根据单词快速获取包含这个单词的文档列表。倒排索引主要由两个部分组成：“单词词典”和“倒排文件”。源于实际应用中需要根据属性的值来查找记录。这种索引表中的每一项都包括一个属性值和具有该属性值的各记录的地址。由于不是由记录来确定属性值，而是由属性值来确定记录的位置，因而称为倒排索引(inverted index)。带有倒排索引的文件我们称为倒排索引文件，简称倒排文件(inverted file)。

    类型（type）在一个索引中，你可以定义一种或多种类型。一个类型是你的索引的一个逻辑上的分类/分区，其语义完全由你来定。通常，会为具有一组共同字段的文档定义一个类型。比如说，我们假设你运营一个博客平台并且将你所有的数据存储到一个索引中。在这个索引中，你可以为用户数据定义一个类型，为博客数据定义另一个类型，当然，也可以为评论数据定义另一个类型。    

     文档（document）：一个文档是一个可被索引的基础信息单元。比如，你可以拥有某一个客户的文档，某一个产品的一个文档，当然，也可以拥有某个订单的一个文档。文档以JSON（Javascript Object Notation）格式来表示，而JSON是一个到处存在的互联网数据交互格式。在一个index/type里面，只要你想，你可以存储任意多的文档。注意，尽管一个文档，物理上存在于一个索引之中，文档必须被索引/赋予一个索引的type。

    分片和复制（shards & replicas）：一个索引可以存储超出单个结点硬件限制的大量数据。比如，一个具有10亿文档的索引占据1TB的磁盘空间，而任一节点都没有这样大的磁盘空间；或者单个节点处理搜索请求，响应太慢。为了解决这个问题，Elasticsearch提供了将索引划分成多份的能力，这些份就叫做分片。当你创建一个索引的时候，你可以指定你想要的分片的数量。每个分片本身也是一个功能完善并且独立的“索引”，这个“索引”可以被放置到集群中的任何节点上。
    分片之所以重要，主要有两方面的原因：
- 允许你水平分割/扩展你的内容容量
- 允许你在分片（潜在地，位于多个节点上）之上进行分布式的、并行的操作，进而提高性能/吞吐量
    至于一个分片怎样分布，它的文档怎样聚合回搜索请求，是完全由Elasticsearch管理的，对于作为用户的你来说，这些都是透明的。在一个网络/云的环境里，失败随时都可能发生，在某个分片/节点不知怎么的就处于离线状态，或者由于任何原因消失了，这种情况下，有一个故障转移机制是非常有用并且是强烈推荐的。为此目的，Elasticsearch允许你创建分片的一份或多份拷贝，这些拷贝叫做复制分片，或者直接叫复制。
    复制之所以重要，有两个主要原因：
- 在分片/节点失败的情况下，提供了高可用性。因为这个原因，注意到复制分片从不与原/主要（original/primary）分片置于同一节点上是非常重要的。
- 扩展你的搜索量/吞吐量，因为搜索可以在所有的复制上并行运行

    总之，每个索引可以被分成多个分片。一个索引也可以被复制0次（意思是没有复制）或多次。一旦复制了，每个索引就有了主分片（作为复制源的原来的分片）和复制分片（主分片的拷贝）之别。分片和复制的数量可以在索引创建的时候指定。在索引创建之后，你可以在任何时候动态地改变复制的数量，但是你事后不能改变分片的数量。默认情况下，Elasticsearch中的每个索引被分片5个主分片和1个复制，这意味着，如果你的集群中至少有两个节点，你的索引将会有5个主分片和另外5个复制分片（1个完全拷贝），这样的话每个索引总共就有10个分片。

    集群（cluster）：一个集群就是由一个或多个节点组织在一起，它们共同持有你整个的数据，并一起提供索引和搜索功能。一个集群由一个唯一的名字标识，这个名字默认就是“elasticsearch”。这个名字是重要的，因为一个节点只能通过指定某个集群的名字，来加入这个集群。在产品环境中显式地设定这个名字是一个好习惯，但是使用默认值来进行测试/开发也是不错的。  

     节点（node）：一个节点是你集群中的一个服务器，作为集群的一部分，它存储你的数据，参与集群的索引和搜索功能。和集群类似，一个节点也是由一个名字来标识的，默认情况下，这个名字是一个随机的漫威漫画角色的名字，这个名字会在启动的时候赋予节点。这个名字对于管理工作来说挺重要的，因为在这个管理过程中，你会去确定网络中的哪些服务器对应于Elasticsearch集群中的哪些节点。
     一个节点可以通过配置集群名称的方式来加入一个指定的集群。默认情况下，每个节点都会被安排加入到一个叫做“elasticsearch”的集群中，这意味着，如果你在你的网络中启动了若干个节点，并假定它们能够相互发现彼此，它们将会自动地形成并加入到一个叫做“elasticsearch”的集群中。
    在一个集群里，只要你想，可以拥有任意多个节点。而且，如果当前你的网络中没有运行任何Elasticsearch节点，这时启动一个节点，会默认创建并加入一个叫做“elasticsearch”的集群。

4.elasticsearch与solr的比较：   

solr优点
1、Solr有一个更大、更成熟的用户、开发和贡献者社区。
2、支持添加多种格式的索引，如：HTML、PDF、微软 Office 系列软件格式以及 JSON、XML、CSV 等纯文本格式。
3、Solr比较成熟、稳定。
4、不考虑建索引的同时进行搜索，速度更快。
缺点
建立索引时，搜索效率下降，实时索引搜索效率不高。
Elasticsearch优点
1、Elasticsearch是分布式的。不需要其他组件，分发是实时的，被叫做”Push replication”。
2、Elasticsearch 完全支持 Apache Lucene 的接近实时的搜索。
3、处理多租户（multitenancy）不需要特殊配置，而Solr则需要更多的高级设置。
4、Elasticsearch 采用 Gateway 的概念，使得完备份更加简单。
5、各节点组成对等的网络结构，某些节点出现故障时会自动分配其他节点代替其进行工作。
缺点
还不够自动，不适合当前新的Index Warmup API (参考：http://zhaoyanblog.com/archives/764.html)
总结：
1、当单纯的对已有数据进行搜索时，Solr更快。
2、当实时建立索引时, Solr会产生io阻塞，查询性能较差, Elasticsearch具有明显的优势。
3、随着数据量的增加，Solr的搜索效率会变得更低，而Elasticsearch却没有明显的变化。
4、Solr的架构不适合实时搜索的应用。
5、Solr 支持更多格式的数据，而 Elasticsearch 仅支持json文件格式
6、Solr 在传统的搜索应用中表现好于 Elasticsearch，但在处理实时搜索应用时效率明显低于 Elasticsearch

7、Solr 是传统搜索应用的有力解决方案，但 Elasticsearch 更适用于新兴的实时搜索应用

5.elasticsearch与solr在用法上的区别

--- 环境搭建的区别

elastic search: 

1.要使用必须配置Java_HOME的环境变量

2.ik分词器等高级功能由插件完成

3.自启动

Solr是用Java编写、运行在Servlet容器（如 Apache Tomcat 或Jetty）的一个独立的全文搜索服务器。

1.拷贝solr war包至tomcat

2.拷贝日志jar包

3.配置solrHome和solrCore\

4.在war包中web.xml中配置solrhome的位置

5.启动tomcat

---客户端API的区别（如何进行文档的增删改查）

elastic search: 

1.正常的编程顺序：创建索引--添加映射---储存数据（建立文档json数据），但是也可以直接创建文档，会自动创建索引，映射

2.单独使用要先创建搜索服务器client链接上服务器 （QueryBuileders.queryStringQuery(搜索内容) 匹配所有字段）

Client client = TransportClient.builder().build().addTransportAddress(new InetSocketTransportAddress(InetAddress.getByName("127.0.0.1"),9300));

3.索引的创建与删除

//创建索引
client.admin().indices().prepareCreate("blog2").get();
//删除索引
client.admin().indices().prepareDelete("blog2").get();

4.映射

//添加映射
PutMappingRequest mapping = Requests.putMappingRequest("blog2").type("article").source(builder);//（builder是映射json数据）
client.admin().indices().putMapping(mapping).get();

5.文档

//创建文档,基于xContentBuilder的json数据
client.prepareIndex("blog2", "article", "1").setSource(builder).get();
//创建文档,基于实体类
client.prepareIndex("blog2", "article",article.getId().toString() ).setSource(mapper.writeValueAsString(article)).get();
//修改文档,也可以直接 client.update(new updateRequest())
client.prepareUpdate("blog2", "article", article.getId().toString()).setDoc(mapper.writeValueAsString(article)).get();
//删 client.delete(new DeleteRequest)
client.prepareDelete("blog2", "article", article.getId().toString()).get();
//查
client.prepareIndex("blog2", "article",article.getId().toString()).setSource(mapper.writeValueAsString(article)).get();

Spring Data ElasticSearch:

  1. 编写 DAO 自动操作 elasticsearch 继承 ElasticsearchRepository 接口  

  2.通过 ElasticsearchTemplate 创建索引和添加映射  elasticsearchTemplate.createIndex(Article.class);

  3.通过service层调用save delete findAll 、findOne 操作索引库,也可以分页查询 

solr:

 1.indexWriter.addDocument(document);

2.indexWriter.deleteDocuments(new Term("fileName", "文档"));

3.indexWriter.updateDocument(new Term("fileName","问题"), document);先删后加

4. TopDocs topDocs = indexSearcher.search(query, 10); indexReader,传入不同的query

QueryParser queryParser = new QueryParser("content", new IKAnalyzer());

---数据导入的区别

elasticsearch:

    1.从数据库查找出来,wayBillIndexRepository.save()方法自动同步

    2.@Document(indexName="blog3",type="article")

        @Id

        @Field(index=FieldIndex.not_analyzed,store=true,type=FieldType.Integer)

solr:

    1.在web管理工具上操作,必须保证每一个域field对象都已经在schema.xml配置

    2.批量:1.导入dataimport jar包 数据库驱动jar包

    3.配置solrconfig.mxl文件，添加一个requestHandler。

    4.创建一个data-config.xml，保存到collection1\conf\目录下 里面配置数据库信息,查询语句,以及数据库字段对应域对象

    5.重启tomcat ,执行excute

--- elastic search里面，每个document可以指定一个type：

    @Document(indexName="bos", type="waybill")

  type是什么概念

  文档类型:一个索引对象可以储存多个不同用途的document对象;例如一个博客可以有文章和评论,文章和评论就是不同的文档类型,方便区分搜索;

--- web管理工具的区别

elasticsearch: EShead插件访问http://localhost:9200/_plugin/head/

solr: 基于tomcat   http://localhost:8080/solr/

--- 性能、使用场景上的区别、优缺点（自己查资料总结）

1. solr查询快，但更新索引时慢（即插入删除慢），用于电商等查询多的应用；

2.ES建立索引快（即查询慢），即实时性查询快，用于facebook新浪等搜索。

6.elasticsearch的一些其他问题

Elasticsearch是如何实现Master选举的？

    Elasticsearch的选举是ZenDiscovery模块负责的，主要包含Ping（节点之间通过这个RPC来发现彼此）和Unicast（单播模块包含一个主机列表以控制哪些节点需要ping通）这两部分；

    对所有可以成为master的节点（node.master: true）根据nodeId字典排序，每次选举每个节点都把自己所知道节点排一次序，然后选出第一个（第0位）节点，暂且认为它是master节点。

    如果对某个节点的投票数达到一定的值（可以成为master节点数n/2+1）并且该节点自己也选举自己，那这个节点就是master。否则重新选举一直到满足上述条件。

    补充：master节点的职责主要包括集群、节点和索引的管理，不负责文档级别的管理；data节点可以关闭http功能。

Elasticsearch中的节点（比如共20个），其中的10个选了一个master，另外10个选了另一个master，怎么办？

    当集群master候选数量不小于3个时，可以通过设置最少投票通过数量（discovery.zen.minimum_master_nodes）超过所有候选节点一半以上来解决脑裂问题；

    当候选数量为两个时，只能修改为唯一的一个master候选，其他作为data节点，避免脑裂问题。

客户端在和集群连接时，如何选择特定的节点执行请求的？

    TransportClient利用transport模块远程连接一个elasticsearch集群。它并不加入到集群中，只是简单的获得一个或者多个初始化的transport地址，并以 轮询 的方式与这些地址进行通信。

详细描述一下Elasticsearch索引文档的过程。

    协调节点默认使用文档ID参与计算（也支持通过routing），以便为路由提供合适的分片。shard = hash(document_id) % (num_of_primary_shards)

    当分片所在的节点接收到来自协调节点的请求后，会将请求写入到Memory Buffer，然后定时（默认是每隔1秒）写入到Filesystem Cache，这个从Momery Buffer到Filesystem Cache的过程就叫做refresh；

    当然在某些情况下，存在Momery Buffer和Filesystem Cache的数据可能会丢失，ES是通过translog的机制来保证数据的可靠性的。其实现机制是接收到请求后，同时也会写入到translog中，当Filesystem cache中的数据写入到磁盘中时，才会清除掉，这个过程叫做flush；

    在flush过程中，内存中的缓冲将被清除，内容被写入一个新段，段的fsync将创建一个新的提交点，并将内容刷新到磁盘，旧的translog将被删除并开始一个新的translog。

    flush触发的时机是定时触发（默认30分钟）或者translog变得太大（默认为512M）时；

详细描述一下Elasticsearch更新和删除文档的过程。

    删除和更新也都是写操作，但是Elasticsearch中的文档是不可变的，因此不能被删除或者改动以展示其变更；

    磁盘上的每个段都有一个相应的.del文件。当删除请求发送后，文档并没有真的被删除，而是在.del文件中被标记为删除。该文档依然能匹配查询，但是会在结果中被过滤掉。当段合并时，在.del文件中被标记为删除的文档将不会被写入新段。

    在新的文档被创建时，Elasticsearch会为该文档指定一个版本号，当执行更新时，旧版本的文档在.del文件中被标记为删除，新版本的文档被索引到一个新段。旧版本的文档依然能匹配查询，但是会在结果中被过滤掉。

详细描述一下Elasticsearch搜索的过程。

    搜索被执行成一个两阶段过程，我们称之为 Query Then Fetch；

    在初始查询阶段时，查询会广播到索引中每一个分片拷贝（主分片或者副本分片）。 每个分片在本地执行搜索并构建一个匹配文档的大小为 from + size 的优先队列。PS：在搜索的时候是会查询Filesystem Cache的，但是有部分数据还在Memory Buffer，所以搜索是近实时的。

    每个分片返回各自优先队列中 所有文档的 ID 和排序值 给协调节点，它合并这些值到自己的优先队列中来产生一个全局排序后的结果列表。

    接下来就是 取回阶段，协调节点辨别出哪些文档需要被取回并向相关的分片提交多个 GET 请求。每个分片加载并 丰富 文档，如果有需要的话，接着返回文档给协调节点。一旦所有的文档都被取回了，协调节点返回结果给客户端。

补充：Query Then Fetch的搜索类型在文档相关性打分的时候参考的是本分片的数据，这样在文档数量较少的时候可能不够准确，DFS Query Then Fetch增加了一个预查询的处理，询问Term和Document frequency，这个评分更准确，但是性能会变差。

对于GC方面，在使用Elasticsearch时要注意什么？

    倒排词典的索引需要常驻内存，无法GC，需要监控data node上segment memory增长趋势。

    各类缓存，field cache, filter cache, indexing cache, bulk queue等等，要设置合理的大小，并且要应该根据最坏的情况来看heap是否够用，也就是各类缓存全部占满的时候，还有heap空间可以分配给其他任务吗？避免采用clear cache等“自欺欺人”的方式来释放内存。

    避免返回大量结果集的搜索与聚合。确实需要大量拉取数据的场景，可以采用scan & scroll api来实现。

    cluster stats驻留内存并无法水平扩展，超大规模集群可以考虑分拆成多个集群通过tribe node连接。

    想知道heap够不够，必须结合实际应用场景，并对集群的heap使用情况做持续的监控。

Elasticsearch对于大数据量（上亿量级）的聚合如何实现？

    Elasticsearch 提供的首个近似聚合是cardinality 度量。它提供一个字段的基数，即该字段的distinct或者unique值的数目。它是基于HLL算法的。HLL 会先对我们的输入作哈希运算，然后根据哈希运算的结果中的 bits 做概率估算从而得到基数。其特点是：可配置的精度，用来控制内存的使用（更精确 ＝ 更多内存）；小的数据集精度是非常高的；我们可以通过配置参数，来设置去重需要的固定内存使用量。无论数千还是数十亿的唯一值，内存使用量只与你配置的精确度相关。

在并发情况下，Elasticsearch如果保证读写一致？

    可以通过版本号使用乐观并发控制，以确保新版本不会被旧版本覆盖，由应用层来处理具体的冲突；

    另外对于写操作，一致性级别支持quorum/one/all，默认为quorum，即只有当大多数分片可用时才允许写操作。但即使大多数可用，也可能存在因为网络等原因导致写入副本失败，这样该副本被认为故障，分片将会在一个不同的节点上重建。

    对于读操作，可以设置replication为sync(默认)，这使得操作在主分片和副本分片都完成后才会返回；如果设置replication为async时，也可以通过设置搜索请求参数_preference为primary来查询主分片，确保文档是最新版本。

如何监控Elasticsearch集群状态？

    Marvel 让你可以很简单的通过 Kibana 监控 Elasticsearch。你可以实时查看你的集群健康状态和性能，也可以分析过去的集群、索引和节点指标。

介绍一下你们的个性化搜索方案？

SEE 基于word2vec和Elasticsearch实现个性化搜索

是否了解字典树？

    常用字典数据结构如下所示：

    Trie的核心思想是空间换时间，利用字符串的公共前缀来降低查询时间的开销以达到提高效率的目的。它有3个基本性质：

根节点不包含字符，除根节点外每一个节点都只包含一个字符。

从根节点到某一节点，路径上经过的字符连接起来，为该节点对应的字符串。

每个节点的所有子节点包含的字符都不相同。

    可以看到，trie树每一层的节点数是26^i级别的。所以为了节省空间，我们还可以用动态链表，或者用数组来模拟动态。而空间的花费，不会超过单词数×单词长度。

    实现：对每个结点开一个字母集大小的数组，每个结点挂一个链表，使用左儿子右兄弟表示法记录这棵树；

    对于中文的字典树，每个节点的子节点用一个哈希表存储，这样就不用浪费太大的空间，而且查询速度上可以保留哈希的复杂度O(1)。

拼写纠错是如何实现的？

    拼写纠错是基于编辑距离来实现；编辑距离是一种标准的方法，它用来表示经过插入、删除和替换操作从一个字符串转换到另外一个字符串的最小操作步数；

    编辑距离的计算过程：比如要计算batyu和beauty的编辑距离，先创建一个7×8的表（batyu长度为5，coffee长度为6，各加2），接着，在如下位置填入黑色数字。其他格的计算过程是取以下三个值的最小值：

如果最上方的字符等于最左方的字符，则为左上方的数字。否则为左上方的数字+1。（对于3,3来说为0）左方数字+1（对于3,3格来说为2）上方数字+1（对于3,3格来说为2）最终取右下角的值即为编辑距离的值3。

    对于拼写纠错，我们考虑构造一个度量空间（Metric Space），该空间内任何关系满足以下三条基本条件：

d(x,y) = 0 -- 假如x与y的距离为0，则x=y

d(x,y) = d(y,x)  -- x到y的距离等同于y到x的距离

d(x,y) + d(y,z) >= d(x,z) -- 三角不等式

    根据三角不等式，则满足与query距离在n范围内的另一个字符转B，其与A的距离最大为d+n，最小为d-n。

    BK树的构造就过程如下：每个节点有任意个子节点，每条边有个值表示编辑距离。所有子节点到父节点的边上标注n表示编辑距离恰好为n。比如，我们有棵树父节点是”book”和两个子节点”cake”和”books”，”book”到”books”的边标号1，”book”到”cake”的边上标号4。从字典里构造好树后，无论何时你想插入新单词时，计算该单词与根节点的编辑距离，并且查找数值为d(neweord, root)的边。递归得与各子节点进行比较，直到没有子节点，你就可以创建新的子节点并将新单词保存在那。比如，插入”boo”到刚才上述例子的树中，我们先检查根节点，查找d(“book”, “boo”) = 1的边，然后检查标号为1的边的子节点，得到单词”books”。我们再计算距离d(“books”, “boo”)=2，则将新单词插在”books”之后，边标号为2。

    查询相似词如下：计算单词与根节点的编辑距离d，然后递归查找每个子节点标号为d-n到d+n（包含）的边。假如被检查的节点与搜索单词的距离d小于n，则返回该节点并继续查询。比如输入cape且最大容忍距离为1，则先计算和根的编辑距离d(“book”, “cape”)=4，然后接着找和根节点之间编辑距离为3到5的，这个就找到了cake这个节点，计算d(“cake”, “cape”)=1，满足条件所以返回cake，然后再找和cake节点编辑距离是0到2的，分别找到cape和cart节点，这样就得到cape这个满足条件的结果。

7.elasticsearch的使用案例

（1）维基百科，类似百度百科，牙膏，牙膏的维基百科，全文检索，高亮，搜索推荐

（2）The Guardian（国外新闻网站），类似搜狐新闻，用户行为日志（点击，浏览，收藏，评论）+社交网络

数据（对某某新闻的相关看法），数据分析，给到每篇新闻文章的作者，让他知道他的文章的公众反馈（好，

坏，热门，垃圾，鄙视，崇拜）

（3）Stack Overflow（国外的程序异常讨论论坛），IT问题，程序的报错，提交上去，有人会跟你讨论和回答，全文检索，搜索相关问题和答案，程序报错了，就会将报错信息粘贴到里面去，搜索有没有对应的答案

（4）GitHub（开源代码管理），搜索上千亿行代码

（5）电商网站，检索商品

（6）日志数据分析，logstash采集日志，ES进行复杂的数据分析（ELK技术，elasticsearch+logstash+kibana）

（7）商品价格监控网站，用户设定某商品的价格阈值，当低于该阈值的时候，发送通知消息给用户，比如说订阅牙膏的监控，如果高露洁牙膏的家庭套装低于50块钱，就通知我，我就去买

（8）BI系统，商业智能，Business Intelligence。比如说有个大型商场集团，BI，分析一下某某区域最近3年的用户消费金额的趋势以及用户群体的组成构成，产出相关的数张报表，**区，最近3年，每年消费金额呈现100%的增长，而且用户群体85%是高级白领，开一个新商场。ES执行数据分析和挖掘，Kibana进行数据可视化

（9）国内：站内搜索（电商，招聘，门户，等等），IT系统搜索（OA，CRM，ERP，等等），数据分析（ES热门
的一个使用场景）