elasticsearch搜索引擎（Elasticsearch）

本文目录

• Elasticsearch
• 全文本搜索插件有哪些
• elasticsearch索引主要实现方式
• 为什么mongodb不能替代elasticsearch区别
• Elasticsearch 中的搜索类型
• 分布式搜索引擎elasticsearch的架构原理
• 全文搜索之MySQL与ElasticSearch搜索引擎
• ElasticSearch海量数据使用简述

Elasticsearch

***隐藏网址***

Elasticsearch是位于ElasticStack核心的分布式搜索和分析引擎。Logstash和Beats有助于收集、聚合和丰富您的数据并将其存储在Elasticsearch中。

ElasticSearch是一个基于Lucene的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎，基于RESTfulweb接口。Elasticsearch是用Java开发的，并作为Apache许可条款下的开放源码发布，是当前流行的企业级搜索引擎。

Elasticsearch架构简单介绍如下。索引索引（index）是Elasticsearch对逻辑数据的逻辑存储，所以它可以分为更小的部分。你可以把索引看成关系型数据库的表。然而，索引的结构是为快速有效的全文索引准备的，特别是它不存储原始值。

全文本搜索插件有哪些

全文本搜索插件有：Elasticsearch，Solr，Sphinx。
1、Elasticsearch：这是一款基于Lucene的开源搜索引擎，支持实时搜索、近实时搜索和大规模数据处理，可广泛应用于企业搜索、网站搜索、应用程序搜索等领域。
2、Solr：这是一款基于Lucene的开源搜索平台，可实现全文本搜索、分布式搜索、数据挖掘和数据分析等功能，支持多种数据格式和数据源
3、Sphinx：这是一款开源的全文本搜索引擎，支持高效的实时和批处理搜索，适用于大规模数据和高并发访问的场景。

elasticsearch索引主要实现方式

Elasticsearch是什么?

Elasticsearch是位于ElasticStack核心的分布式搜索和分析引擎。Logstash和Beats有助于收集、聚合和丰富您的数据并将其存储在Elasticsearch中。Kibana使您能够以交互方式探索、可视化和分享对数据的见解，并管理。

Elasticsearch是一个分布式文档存储。Elasticsearch存储的是序列化为JSON文档的复杂数据结构，而不是以列行数据的形式存储信息。当集群中有多个Elasticsearch节点时，存储的文档分布在整个集群中，可以立即从任何节点访问。

Elasticsearch是由ShayBanon发起的一个开源搜索服务器项目，2010年2月发布。迄今，该项目已发展成为搜索和数据分析解决方案领域的主要一员，广泛应用于声名卓著或鲜为人知的搜索应用程序。

Elasticsearch是一个高度可扩展的开源全文搜索和分析引擎。它可以在很短的时间内存储，搜索和分析大量的数据。它通常作为具有复杂搜索场景情况下的核心发动机。

搜索引擎，不支持join表等操作。主要用于全文检索。不适合做数据库。

为什么mongodb不能替代elasticsearch区别

MongoDB是一款广泛使用的文档型数据库，而Elasticsearch则是一款基于Lucene的搜索引擎，它们在设计和应用上有很大的差异，因此不能说MongoDB可以完全替代Elasticsearch。以下是一些具体的原因：

• 数据结构：MongoDB主要针对的是数据的存储和查询，而Elasticsearch则是专注于全文搜索和分析，因此它们的数据结构和查询方式不同。MongoDB的查询速度可能会受到文本索引的限制，而Elasticsearch具有更强大的全文搜索和分析功能，可以快速检索和分析海量数据。

• 扩展性：Elasticsearch是一个分布式搜索引擎，可以水平扩展以处理大规模数据，而MongoDB则需要通过复制集或分片技术来扩展。因此在处理大规模数据时，Elasticsearch能够更好地处理。

• 实时性：Elasticsearch具有较高的实时性，能够快速响应用户的搜索请求，而MongoDB可能需要更长时间来执行复杂的查询，因此在实时性方面会有所劣势。

综上所述，MongoDB和Elasticsearch各有优缺点，它们的应用场景也不同。如果需要高效地处理海量文本数据，进行全文搜索和分析，那么Elasticsearch是一个更好的选择；而如果需要处理大量结构化数据或进行多种查询操作，则MongoDB是更适合的选择。

Elasticsearch 中的搜索类型

在执行分布式搜索时存在不同的集中执行路径。分布式搜索的操作需要被分发在所有相关的shard上，然后将所有的结果汇集返回。在进行分发和汇集的过程中，特别是通过搜索引擎中可以有好几种方式完成。
在执行分布式搜索时，一个问题就是从每个shard中检索出来多少结果。例如，如果我们有10个shard，第一个shard可能包含最相关的结果，而其他shard的结果排名都比较靠后。这种情况下，在执行请求时，我们需要从所有的shard中获得从0到10的结果，排序，然后返回最终正确的结果。
另一问题，则与搜索引擎有关，就是每个shard都代表着自己。在一个特定的shard上执行查询时，并不会考虑项的频率和来自其他shard的搜索引擎信息。如果我们希望支持精准的排序，我们必须首先汇集来自所有shard的项的频率来计算全局的项频率，然后在每个shard上使用这些全局频率信息执行查询。
同样，由于对结果排序的需要，返回一个巨大的文档集合，或者甚至进行翻页，保存正确的排序的代价太大。对于大结果集合的不排序滚动，可以通过 scan 这一搜索类型完成。
elasticsearch 非常灵活，支持不同的搜索类型基于 per search request 来执行。这个类型可以通过 search_type 这个参数进行设置。存在以下的类型：

参数值： query_then_fetch

这个请求分两步进行。第一步，查询转发到所有关联的shard上。每个shard执行该搜索请求并产生一个局部的排序的结果列表。每个shard返回足够的新给负责协调的节点从而进行合并和重排shard层面的结果得到最终排序的结果集合，最大长度由参数 size 确定。
在第二步，协调节点仅从相关shard上请求文档内容（和高亮部分，如果有的话）。

参数值： dfs_query_then_fetch

除了在初始的分发步计算分布式的项频率更为精准外，其他与 Query Then Fetch 相同。

参数值： count
特定的搜素类型可以返回匹配搜索请求的文档数目，但不会包含任何的文档在 total_hits 中，也可能会包含facet。这个比 count API更加有用，可以有更多的选项可以控制行为。

参数值： scan

scan 搜索类型关闭了排序的功能，保持在大规模结果集合上的高效滚动。参见 Efficient scrolling with Scroll-Scan 。

参数值：query_and_fetch

该模式是内部优化，当一个query_then_fetch请求单一的shard时自动选择。query_then_fetch的两步在一个单一的步骤内完成。这个模式不应由用户显式指定。

参数值：dfs_query_and_fetch

除了对一个初始分发过程，计算分布式项频率更加准确外，该类型和 query_and_fetch 相同。这个模式不应由用户显式指定。

分布式搜索引擎elasticsearch的架构原理

分布式搜索引擎：把大量的索引数据拆散成多块，每台机器放一部分，然 后利用多台机器对分散之后的数据进行搜索，所有操作全部是分布在多台机器上进行，形成了 完整的分布式的架构。

近实时，有两层意思：

集群包含多个节点，每个节点属于哪个集群都是通过一个配置来决定的，
Node 是集群中的一个节点，节点也有一个名称，默认是随机分配的。默认节点会去加入一个名 称为 elasticsearch 的集群。如果直接启动一堆节点，那么它们会自动组成一个elasticsearch 集群，当然一个节点也可以组成 elasticsearch 集群。

文档是 es 中最小的数据单元，一个 document 可以是1条客户数据、1条商品分类数据、1条 订单数据，通常用json 数据结构来表示。每个 index 下的 type，都可以存储多条 document。
1个 document 里面有多个 field，每个 field 就是1个数据字段。

es 集群多个节点，会自动选举1个节点为 master 节点，这个 master 节点其实就是干一些管理 的工作的，比如维护索引元数据、负责切换 primary shard 和 replica shard 身份等。要是 master 节点宕机了，那么会重新选举1个节点为 master 节点。 如果是非 master节点宕机了，那么会由 master 节点，让那个宕机节点上的 primary shard 的身 份转移到其他机器上的 replica shard。接着你要是修复了那个宕机机器，重启了之后，master 节点会控制将缺失的 replica shard 分配过去，同步后续修改的数据之类的，让集群恢复正常。 说得更简单1点，就是说如果某个非 master 节点宕机了，那么此节点上的 primary shard 不就 没了。那好，master 会让 primary shard 对应的 replica shard（在其他机器上）切换为 primary shard。如果宕机的机器修复了，修复后的节点也不再是 primary shard，而是 replica shard。

索引可以拆分成多个 shard ，每个 shard 存储部分数据。拆分多个 shard是有好处的，一是支持横向扩展，比如你数据量是 3T，3 个 shard，每个 shard 就 1T 的数据， 若现在数据量增加到 4T，怎么扩展，很简单，重新建1个有 4 个 shard 的索引，将数据导进 去；二是提高性能，数据分布在多个 shard，即多台服务器上，所有的操作，都会在多台机器 上并行分布式执行，提高了吞吐量和性能。 接着就是这个 shard 的数据实际是有多个备份，就是说每个 shard 都有1个 primary shard ，负责写入数据，但是还有多个 replica shard 。 primary shard 写入数据之后， 会将数据同步到其他几个 replica shard上去。
通过这个 replica 的方案，每个 shard 的数据都有多个备份，如果某个机器宕机了，没关系啊， 还有别的数据副本在别的机器上，这样子就高可用了。

总结：分布式就是两点，1.通过shard切片实现横向扩展；2.通过replica副本机制，实现高可用

基本概念

写数据过程：客户端通过hash选择一个node发送请求，这个node被称做coordinating node（协调节点），协调节点对docmount进行路由，将请求转发给到对应的primary shard，primary shard 处理请求，将数据同步到所有的replica shard，此时协调节点，发现primary shard 和所有的replica shard都处理完之后，就反馈给客户端。

客户端发送get请求到任意一个node节点，然后这个节点就称为协调节点，协调节点对document进行路由，将请求转发到对应的node，此时会使用随机轮询算法，在primary shard 和replica shard中随机选择一个，让读取请求负载均衡，接收请求的node返回document给协调节点，协调节点，返回document给到客户端

es最强大的是做全文检索，就是比如你有三条数据
1.java真好玩儿啊
2.java好难学啊
3.j2ee特别牛

你根据java关键词来搜索，将包含java的document给搜索出来。

更新/删除数据过程，首先还是write、merge操作，然后flush过程中：
1、write过程和上面的一致；
2、refresh过程有点区别

所谓的倒排索引，就是把你的数据内容先分词，每句话分成一个一个的关键词，然后记录好每一个关键词对应出现在了哪些 id 标识的数据。
然后你可以从其他地根据这个 id 找到对应的数据就可以了，这个就是倒排索引的数据格式 以及搜索的方式，这种利倒排索引查找数据的式，也被称之为全文检索。

Inverted Index就是我们常见的倒排索引, 主要包括两部分：
一个有序的数据字典 Dictionary（包括单词 Term 和它出现的频率）。
与单词 Term 对应的 Postings（即存在这个单词的文件）
当我们搜索的时候，首先将搜索的内容分解，然后在字典里找到对应 Term，从而查找到与搜索相关的文件内容。

本质上，Stored Fields 是一个简单的键值对 key-value。默认情况下，Stored Fields是为false的,ElasticSearch 会存储整个文件的 JSON source。

哪些情形下需要显式的指定store属性呢？大多数情况并不是必须的。从_source中获取值是快速而且高效的。如果你的文档长度很长，存储 _source或者从_source中获取field的代价很大，你可以显式的将某些field的store属性设置为yes。缺点如上边所说：假设你存 储了10个field，而如果想获取这10个field的值，则需要多次的io，如果从Stored Field 中获取则只需要一次，而且_source是被压缩过 的。

这个时候你可以指定一些字段store为true，这意味着这个field的数据将会被单独存储(实际上是存两份,source和 Stored Field都存了一份)。这时候，如果你要求返回field1（store：yes），es会分辨出field1已经被存储了，因此不会从_source中加载，而是从field1的存储块中加载。

Doc_values 本质上是一个序列化的 列式存储，这个结构非常适用于聚合（aggregations）、排序（Sorting）、脚本（scripts access to field）等操作。而且，这种存储方式也非常便于压缩，特别是数字类型。这样可以减少磁盘空间并且提高访问速度,ElasticSearch 可以将索引下某一个 Document Value 全部读取到内存中进行操作.

Doc_values是存在磁盘的

在es中text类型字段默认只会建立倒排索引，其它几种类型在建立倒排索引的时候还会建立正排索引，当然es是支持自定义的。在这里这个正排索引其实就是Doc Value。

即上文所描述的动态索引

往 es 写的数据，实际上都写到磁盘文件里去了，查询的时候，操作系统会将磁盘文件里的数据自动缓存到 filesystem cache 中去。

es 的搜索引擎严重依赖于底层的 filesystem cache ，你如果给 filesystem cache 更多的 内存，尽量让内存可以容纳所有的 idx segment file 索引数据文件，那么你搜索的时候就 基本都是走内存的，性能会非常高。 性能差距究竟可以有多大？我们之前很多的测试和压测，如果走磁盘一般肯定上秒，搜索性能 绝对是秒级别的，1秒、5秒、10秒。但如果是走 filesystem cache ，是走纯内存的，那么一 般来说性能比走磁盘要高一个数量级，基本上就是毫秒级的，从几毫秒到几百毫秒不等。

那如何才能节约filesystem cache这部分的空间呢？
当写数据到ES时就要考虑到最小化数据，当一行数据有30几个字段，并不需要把所有的数据都写入到ES，只需要把关键的需要检索的几列写入。这样能够缓存的数据就会越多。 所以需要控制每台机器写入的数据最好小于等于或者略大于filesystem cache空间最好。 如果要搜索海量数据，可以考虑用ES+Hbase架构。用Hbase存储海量数据，然后ES搜索出doc id后，再去Hbase中根据doc id查询指定的行数据。

当每台机器写入的数据大于cache os太多时，导致太多的数据无法放入缓存，那么就可以把一部分热点数据刷入缓存中。

对于那些你觉得比较热的、经常会有人访问的数据，最好做个专门的缓存预热系统，就是 对热数据每隔一段时间，就提前访问一下，让数据进入 filesystem cache 里去。这样下 次别人访问的时候，性能肯定会好很多。

把热数据和冷数据分开，写入不同的索引里，然后确保把热索引数据刷到cache里。

在ES里最好不要用复杂的关联表的操作。当需要这样的场景时，可以在创建索引的时候，就把数据关联好。比如在mysql中需要根据关联ID查询两张表的关联数据：select A.name ,B.age from A join B where A.id = B.id，在写入ES时直接去把相关联数据放到一个document就好。

es 的分页是较坑的，为啥呢？举个例子吧，假如你每页是 10 条数据，你现在要查询第 100 页，实际上是会把每个 shard 上存储的前 1000 条数据都查到1个协调节点上，如果你有个 5 个 shard，那么就有 5000 条数据，接着协调节点对这 5000 条数据进行一些合并、处理，再获取到 最终第 100 页的 10 条数据。
分布式的，你要查第 100 页的 10 条数据，不可能说从 5 个 shard，每个 shard 就查 2 条数据， 最后到协调节点合并成 10 条数据吧？你必须得从每个 shard 都查 1000 条数据过来，然后根据 你的需求进行排序、筛选等等操作，最后再次分页，拿到里面第 100 页的数据。你翻页的时 候，翻的越深，每个 shard 返回的数据就越多，而且协调节点处理的时间越长，非常坑爹。所 以用 es 做分页的时候，你会发现越翻到后面，就越是慢。

我们之前也是遇到过这个问题，用 es 作分页，前几页就几十毫秒，翻到 10 页或者几十页的时 候，基本上就要 5~10 秒才能查出来一页数据了。

解决方案吗？
1）不允许深度分页：跟产品经理说，你系统不允许翻那么深的页，默认翻的越深，性能就越差；
2）在APP或者公众号里，通过下拉来实现分页，即下拉时获取到最新页，可以通过scroll api来实现；
scroll 会1次性给你生成所有数据的1个快照，然后每次滑动向后翻页就是通过游标 scroll_id 移动获取下一页，性能会比上面说的那种分页性能要高很多很 多，基本上都是毫秒级的。 但是，唯1的缺点就是，这个适合于那种类似微博下拉翻页的，不能随意跳到任何一页的场 景。也就是说，你不能先进到第 10 页，然后去第 120 页，然后再回到第 58 页，不能随意乱跳 页。所以现在很多APP产品，都是不允许你随意翻页的，也有一些网站，做的就是你只能往 下拉，一页一页的翻。
初始化时必须指定 scroll 参数，告诉 es 要保存此次搜索的上下文多长时间。你需要确保用户不会持续不断翻页翻几个小时，否则可能因为超时而失败。
除了用 scroll api ，也可以用 search_after 来做， search_after 的思想是使用前一页的结果来帮助检索下一页的数据，显然，这种方式也不允许你随意翻页，你只能一页一页往后 翻。初始化时，需要使用一个唯1值的字段作为 sort 字段。

全文搜索之MySQL与ElasticSearch搜索引擎

MySQL支持全文索引和搜索功能。在MySQL中可以在CHAR、VARCHAR或TEXT列使用FULLTETXT来创建全文索引。
FULLTEXT索引主要用MATCH()...AGAINST语法来实现搜索：

MySQL的全文搜索存在以下局限：

通常来说MySQL自带的全文搜索使用起来局限性比较大，性能和功能都不太成熟，主要适用于小项目，大项目还是建议使用elasticsearch来做全文搜索。

ElasticSearch是一个分布式的开源搜索和分析引擎，适用于所有类型的数据，包括文本、数字、地理空间、结构化和非结构化数据，以下简称ES。

Elasticsearch 在 Apache Lucene 的基础上开发而成，Elasticsearch 以其简单的 REST 风格 API、分布式特性、速度和可扩展性而闻名，是 Elastic Stack 的核心组件。Elastic Stack 是适用于数据采集、充实、存储、分析和可视化的一组开源工具。

Elasticsearch 的实现原理主要分为以下几个步骤，首先用户将数据提交到Elasticsearch 数据中心，再通过分词控制器去将对应的数据分词，将其权重和分词结果一并存入数据，当用户搜索数据时候，再根据权重将结果排名，打分，再将返回结果呈现给用户。

由于ES是基于RESTfull Web接口的，因此我们直接按照惯例传递JSON参数调用接口即可实现增删改查，并且不需要我们做额外的管理操作就可以直接索引文档，ES已经内置了所有的缺省操作，可以自动帮我们定义类型。

再次执行PUT，会对库中已有的id为1的数据进行覆盖，每修改一次_version字段的版本号就会加1。

默认搜索会返回前10个结果：

返回的几个关键词：

查询字符串搜索，可以像传递URL参数一样传递查询语句。

精确查询：

全文搜索：

以上两种方法都需要考虑数据更改后如何与ES进行同步。

ElasticSearch海量数据使用简述

应用场景当中经常会遇到模糊查询或多条件匹配查询，数据量较小的情况下通过简单的数据库模糊查询是可以解决的，但是对于数据量庞大的情况，数据库模糊查询就会出现性能问题。这种情况下的一种解决方案就是根据查询内容构建反向索引，借助搜索引擎进行查询，提升查询性能。

目前使用比较多的分布式搜索引擎是ElasticSearch。那么项目中如何使用ES？如何保证ES的数据更新？下面简单做个描述。

Elasticsearch使用可以简单分为两个阶段。数据初始化阶段、数据更新阶段。

数据初始化阶段。数据初始化常见的方式如下：

一、通过应用程序手动将数据库中的数据，调用ES接口API插入ES索引库中。

二、同过数据迁移工具将数据初始化到ES数据库。目前常用的ES同步工具有logstash-input-jdbc、DataX。通过同步迁移工具可以全量将数据库数据初始化到ES索引库中。

数据更新阶段。数据更新阶段常见的处理方式如下：

一、通过应用服务直接调用ES更新接口。这种方式实现比较简单但是对业务侵入性比较大。

二、对于实时性要求不高的可以采用定时任务监控数据表变化然后调用ES接口实现数据更新。

三、业务应用中通过发送消息异步更新数据。

四、通过DataX同步工具定时将修改的数据同步到ES库中。

上述是ElasticSearch使用的简单描述。使用的关键还是数据库与ES间的数据同步。能否用的好关键也是数据间的同步。