大朗网站建设公司,自己做的网站怎么设置文件下载,seo收录查询工具,中文网站开发软件一 ES初识
1.1 概述 ElasticSearch#xff1a;是基于 Lucene 的 Restful 的分布式实时全文搜索引擎#xff0c;每个字段都被索引并可被搜索#xff0c;可以快速存储、搜索、分析海量的数据。是ELK的一个组成,是一个产品#xff0c;而且是非常完善的产品#xff0c;ELK代表…一 ES初识
1.1 概述 ElasticSearch是基于 Lucene 的 Restful 的分布式实时全文搜索引擎每个字段都被索引并可被搜索可以快速存储、搜索、分析海量的数据。是ELK的一个组成,是一个产品而且是非常完善的产品ELK代表的是E就是ElasticSearchL就是LogstachK就是kibana
EEalsticSearch 搜索和分析的功能。LLogstach 搜集数据的功能类似于flume使用方法几乎跟flume一模一样是日志收集系统。KKibana 数据可视化分析可以用图表的方式来去展示文不如表表不如图是数据可视化平台 分析日志的用处假如一个分布式系统有 1000 台机器系统出现故障时我要看下日志还得一台一台登录上去查看是不是非常麻烦 但是如果日志接入了 ELK 系统就不一样。比如系统运行过程中突然出现了异常在日志中就能及时反馈日志进入 ELK 系统中我们直接在 Kibana 就能看到日志情况。如果再接入一些实时计算模块还能做实时报警功能。 这都依赖ES强大的反向索引功能这样我们根据关键字就能查询到关键的错误日志了。
ES官网https://www.elastic.co/cn/elasticsearch/
1.2 ES由来 在上一篇文章中搜索实现之lucene中讲述了lunece和es的关系下面就再说说两个直接的联系吧。 Lucene有两个难以解决的问题
数据越大存不下来那我就需要多台服务器存数据那么我的Lucene不支持分布式的那就需要安装多个Lucene然后通过代码来合并搜索结果。这样很不好数据要考虑安全性一台服务器挂了那么上面的数据不就消失了。 ES就是分布式的集群每一个节点其实就是Lucene当用户搜索的时候会随机挑一台然后这台机器自己知道数据在哪不用我们管这些底层。 ES的优点
分布式的功能数据高可用集群高可用API更简单和更高级。支持的语言很多支持PB级别的数据完成搜索的功能和分析功能基于Lucene隐藏了Lucene的复杂性提供简单的API
ES的性能比HBase高咱们的竞价引擎最后还是要存到ES中的。
二 ES概念,安装和使用
2.1 基本概念
1NRT(Near RealTime) 近实时。 2Cluster集群 ES是一个分布式的系统且ES直接解压不需要配置就可以使用在hadoop1上解压一个ES在hadoop2上解压了一个ES接下来把这两个ES启动起来。他们就构成了一个集群。 在ES里面默认有一个配置clustername 默认值就是ElasticSearch,如果这个值是一样的就属于同一个集群不一样的值就是不一样的集群。 集群中的每一台服务器就是Node节点。
3index 索引索引库 我们为什么使用ES因为想把数据存进去然后再查询出来。我们在使用Mysql或者Oracle的时候为了区分数据我们会建立不同的数据库库下面还有表的。其实ES功能就像一个关系型数据库在这个数据库我们可以往里面添加数据查询数据。 ES中的索引非传统索引的含义ES中的索引是存放数据的地方是ES中的一个概念词汇。index类似于我们Mysql里面的一个数据库 create database user; 好比就是一个索引库 4type类型 类型是用来定义数据结构的。在每一个index下面可以有一个或者多个type好比数据库里面的一张表。相当于表结构的描述描述每个字段的类型。 5document 文档就是最终的数据了可以认为一个文档就是一条记录。是ES里面最小的数据单元就好比表里面的一条数据 6Field字段 好比关系型数据库中列的概念一个document有一个或者多个field组成。 例如
朝阳区一个Mysql数据库房子create database chaoyaninfo房间create table people
7shard分片 一台服务器无法存储大量的数据ES把一个index里面的数据分为多个shard分布式的存储在各个服务器上面 8replica副本 一个分布式的集群难免会有一台或者多台服务器宕机如果我们没有副本这个概念。就会造成我们的shard发生故障无法提供正常服务。我们为了保证数据的安全我们引入了replica的概念跟hdfs里面的概念是一个意思。可以保证我们数据的安全。 在ES集群中我们一模一样的数据有多份能正常提供查询和插入的分片我们叫做 primary shard其余的我们就管他们叫做 replica shard备份的分片 当我们去查询数据的时候我们数据是有备份的它会同时发出命令让我们有数据的机器去查询结果最后谁的查询结果快我们就要谁的数据这个不需要我们去控制它内部就自己控制了 9总结 在默认情况下我们创建一个库的时候默认会帮我们创建5个主分片primary shrad和5个副分片replica shard所以说正常情况下是有10个分片的。 同一个节点上面副本和主分片是一定不会在一台机器上面的就是拥有相同数据的分片是不会在同一个节点上面的。 所以当你有一个节点的时候这个分片是不会把副本存在这仅有的一个节点上的当你新加入了一台节点ES会自动的给你在新机器上创建一个之前分片的副本。 10举例 比如一首诗有诗题、作者、朝代、字数、诗内容等字段那么首先我们可以建立一个名叫 Poems 的索引然后创建一个名叫 Poem 的类型类型是通过 Mapping 来定义每个字段的类型。 比如诗题、作者、朝代都是 Keyword 类型诗内容是 Text 类型而字数是 Integer 类型最后就是把数据组织成 Json 格式存放进去了。 Keyword 类型是不会分词的直接根据字符串内容建立反向索引Text 类型在存入 Elasticsearch 的时候会先分词然后根据分词后的内容建立反向索引。
2.2 安装 咱们如果想很爽的使用ES需要安装3个东西ES、Kibana、ElasticSearch Head。通过Kibana可以对ES进行便捷的可视化操作通过ElasticSearch Head可以查看ES的状态及数据可以理解为ES的图形化界面。 2.2.1 安装ES和Kibana
首先开始安装ES、Kibana同时安装这两个加启动一共需要3步3行代码搞定 1搜索docker镜像库里可用的ES镜像可以看到stars排名第一的是官方的ES镜像第二是大牛已经融合了ES7.7和Kibana7.7的镜像那咱们就用第二个了。
docker search elasticsearch2拉取镜像
docker pull nshou/elasticsearch-kibana3最后咱们把镜像启动为容器就可以了端口映射保持不变咱们给这个容器命名为eskibana到这里ES和Kibana就安装配置完成了容器启动后它们也就启动了一般不会出错是不是非常方便节省大把时间放到开发上来这也是我一直推荐docker的原因。
docker run -d -p 9200:9200 -p 9300:9300 -p 5601:5601 --name eskibana ns
hou/elasticsearch-kibana2.2.2 安装ElasticSearch Head
ElasticSearch Head它相当于是ES的图形化界面这个更简单它是一个浏览器的扩展程序直接在chrome浏览器扩展程序里下载安装即可 1打开chrome浏览器在扩展程序chrome应用商店那里搜索elasticsearch 2选择ElasticSearch Head点击添加至Chrome进行扩展程序的安装即可
2.2.3 验证
到这里咱们的ES、Kibana、ElasticSearch Head都已经安装完成了下面咱们验证一下看是否安装成功 1验证ES 打开浏览器输入IP:端口比如我的http://127.0.0.1:9200/然后就看到了那句经典的You Know, for Search 2验证Kibana
打开浏览器输入Kibana的IP:端口比如我的http://127.0.0.1:5601/然后会看到如下界面 这里面可以提供很多模拟数据感兴趣的可以自己玩玩咱们学习期间只要使用左下角那个扳手形状的Dev Tools就可以了点击后会出现如下界面 3验证Es head 这个更简单只需要点击之前咱们安装的那个扩展程序图标就可以了 点击信息还可以看到集群或者索引的信息很方便大家没事可以玩一玩熟悉一下 通过验证我们已经全部安装配置成功了那么接下来就让我们一起练习一下基础的增删改查加深对ES的理解吧
2.3 基本使用
前面我们已经介绍过了ES 是RESTful 风格的系统所以我们需要先掌握RESTful 的四个关键词PUT修改POST添加DELETE删除GET查询。其中在ES里面PUT和POST的界限并不是很分明有时候PUT也作为添加。
2.3.1 索引操作
1创建一个空索引 如下代码咱们创建了一个0副本2分片的ropledata索引然后咱们可以在Elasticsearch Head里刷新一下并查看索引的信息
PUT /ropledata
{settings: { number_of_shards: 2, number_of_replicas: 0}
}2修改副本 咱们如果对刚才创建的索引副本数量不满意可以进行修改注意分片不允许修改。
PUT ropledata/_settings
{ number_of_replicas : 2
}3删除索引 当这个索引不想用了可以进行删除执行如下命令即可执行成功后刷新ElasticSearch Head可以看到刚才创建的ropledata索引消失了
DELETE /ropledata2.3.2 数据操作
1插入数据 插入数据的时候可以指定id如果不指定的话ES会自动帮我们生成。我们以指定id为例如下代码是我们创建了一个101的文档创建成功后可以在Elasticsearch Head的数据浏览模块里看到这些数据代码及演示如下
//指定id
POST /ropledata/_doc/101
{id:1,name:且听_风吟,page:https://ropledata.blog.csdn.net,say:欢迎点赞收藏关注一起学习
}2修改数据 这里大家要特别注意ES里的文档是不可以修改的但是可以覆盖所以ES修改数据本质上是对文档的覆盖。ES对数据的修改分为全局更新和局部更新咱们分别进行code并对比 1全局更新
PUT /ropledata/_doc/101
{ id:1,name:且听_风吟,page:https://ropledata.blog.csdn.net,say:再次欢迎点赞收藏关注一起学习
}大家可以多全局更新几次会发现每次全局更新之后这个文档的_version都会发生改变 2局部更新
POST /ropledata/_update/101
{doc:{say:奥力给}
}这时候我们可以多次去执行上面的局部更新代码会发现除了第一次执行后续不管又执行了多少次_version都不再变化 局部更新的底层流程 内部先获取到对应的文档
将传递过来的字段更新到文档的json中(这一步实质上也是一样的);将老的文档标记为deleted到一定时候才会物理删除;将修改后的新的文档创建出来。
性能对比
全局更新本质上是替换操作即使内容一样也会去替换局部更新本质上是更新操作只有遇到新的东西才更新没有新的修改就不更新局部更新比全局更新的性能好因此推荐使用局部更新。
3查询数据 ES的数据查询知识点非常多也非常复杂后面我打算单独讲解演示本文只展示最基本的根据id搜索数据的code
GET /ropledata/_doc/1014删除数据 比如我们想把ropledata索引下的id为101的文档删除可以使用如下命令
DELETE /ropledata/_doc/101查询或者删除的时候指定的ID是文档里面得字段id吗 不是的这点容易混淆查询或者删除时候用到的ID是创建文档时候指定或者ES自动生成的那个id而不是文档里面的那个叫id 字段文档里面的文档字段是可以没有id 的。 三 ES常见问题
ES基础相关
1ES的基本概念
index 索引索引类似于mysql 中的数据库Elasticesearch 中的索引是存在数据的地方包含了一堆有相似结构的文档数据。type 类型类型是用来定义数据结构可以认为是 mysql 中的一张表type 是 index 中的一个逻辑数据分类。document 文档类似于 MySQL 中的一行不同之处在于 ES 中的每个文档可以有不同的字段但是对于通用字段应该具有相同的数据类型文档是es中的最小数据单元可以认为一个文档就是一条记录。Field 字段Field是Elasticsearch的最小单位一个document里面有多个field。shard 分片单台机器无法存储大量数据es可以将一个索引中的数据切分为多个shard分布在多台服务器上存储。有了shard就可以横向扩展存储更多数据让搜索和分析等操作分布到多台服务器上去执行提升吞吐量和性能。replica 副本任何服务器随时可能故障或宕机此时 shard 可能会丢失通过创建 replica 副本可以在 shard 故障时提供备用服务保证数据不丢失另外 replica 还可以提升搜索操作的吞吐量。
2docs_value的作用 倒排索引虽然可以提高搜索性能但也存在缺陷比如我们需要对数据做排序或聚合等操作时lucene 会提取所有出现在文档集合的排序字段然后构建一个排好序的文档集合而这个步骤是基于内存的如果排序数据量巨大的话容易造成内存溢出和性能缓慢。 doc_values 就是 es 在构建倒排索引的同时会对开启 doc_values 的字段构建一个有序的 “document文档 field value” 的列式存储映射可以看作是以文档维度实现了根据指定字段进行排序和聚合的功能降低对内存的依赖。另外 doc_values 保存在操作系统的磁盘中当 doc_values 大于节点的可用内存ES可以从操作系统页缓存中加载或弹出从而避免发生内存溢出的异常但如果 docValues 远小于节点的可用内存操作系统就自然将所有 doc_values 存于内存中堆外内存有助于快速访问。 mapping配置项详解
3text 和 keyword类型的区别
两个类型的区别主要是分词keyword 类型是不会分词的直接根据字符串内容建立倒排索引所以keyword类型的字段只能通过精确值搜索到Text 类型在存入 Elasticsearch 的时候会先分词然后根据分词后的内容建立倒排索引
4query 和 filter 的区别
query查询操作不仅仅会进行查询还会计算分值用于确定相关度filter查询操作仅判断是否满足查询条件不会计算任何分值也不会关心返回的排序问题同时filter 查询的结果可以被缓存提高性能。
5ES的分布式原理
Elasticsearch 会对存储的数据进行切分划分到不同的分片上同时每一个分片会生成多个副本从而保证分布式环境的高可用。ES集群中的节点是对等的节点间会选出集群的 Master由 Master 会负责维护集群状态信息并同步给其他节点。Elasticsearch 的性能会不会很低不会ES只有建立 index 和 type 时需要经过 Master而数据的写入有一个简单的 Routing 规则可以路由到集群中的任意节点所以数据写入压力是分散在整个集群的。
6ES的Master选举 Elasticsearch 的选主是 ZenDiscovery 模块负责的主要包含Ping节点之间通过这个RPC来发现彼此和 Unicast单播模块包含一个主机列表以控制哪些节点需要ping通这两部分
确认候选主节点的最少投票通过数量elasticsearch.yml 设置的值 discovery.zen.minimum_master_nodes选举时集群中每个节点对所有 master候选节点node.master: true根据 nodeId 进行字典排序然后选出第一个节点第0位暂且认为它是master节点。如果对某个节点的投票数达到阈值并且该节点自己也选举自己那这个节点就是master否则重新选举一直到满足上述条件。
补充master节点的职责主要包括集群、节点和索引的管理不负责文档级别的管理data节点可以关闭http功能。
7Elasticsearch是如何避免脑裂现象
脑裂产生原因
网络问题集群间的网络延迟导致一些节点访问不到 master认为 master 挂掉了从而选举出新的master并对 master 上的分片和副本标红分配新的主分片。节点负载主节点的角色既为 master 又为 data访问量较大时可能会导致 ES 停止响应造成大面积延 迟此时其他节点得不到主节点的响应认为主节点挂掉了会重新选取主节点。内存回收data 节点上的 ES 进程占用的内存较大引发 JVM 的大规模内存回收造成 ES 进程失去响应。
解决方案
减少误判discovery.zen.ping_timeout 节点状态的响应时间超过这个时间就会重新选举master默认为 3s可以适当调大如果 master在该响应时间的范围内没有做出响应应答判断该节点已经挂掉了。调大参数如 6sdiscovery.zen.ping_timeout:6可适当减少误判。选举触发discovery.zen.minimum_master_nodes:1。该参数是用于控制选举行为发生的最小集群主节点数量。当备选主节点的个数大于等于该参数的值且备选主节点中有该参数个节点认为主节点挂了进行选举。官方建议为n/21n 为主节点个数即有资格成为主节点的节点个数。角色分离即 master 节点与 data 节点分离限制角色 主节点配置为node.master: true node.data: false 从节点配置为node.master: false node.data: true ES的CURD流程
1ES写数据的整体流程 客户端选择 ES 的某个 node 发送请求过去这个 node 就是协调节点 coordinating nodecoordinating node 对 document 进行路由将请求转发给对应的 node有 primary shard实际的 node 上的 primary shard 处理请求然后将数据同步到 replica nodecoordinating node 等到 primary node 和所有 replica node 都执行成功之后最后返回响应结果给客户端。
2ES写数据的详细流程 主分片先将数据写入ES的 memory buffer然后定时默认1s将 memory buffer 中的数据写入一个新的 segment 文件中并进入操作系统缓存 Filesystem cache同时清空 memory buffer这个过程就叫做 refresh每个 segment 文件实际上是一些倒排索引的集合 只有经历了 refresh 操作之后这些数据才能变成可检索的。 ES 的近实时性数据存在 memory buffer 时是搜索不到的只有数据被 refresh 到 Filesystem cache 之后才能被搜索到而 refresh 是每秒一次 所以称 es 是近实时的可以手动调用 es 的 api 触发一次 refresh 操作让数据马上可以被搜索到 由于 memory Buffer 和 Filesystem Cache 都是基于内存假设服务器宕机那么数据就会丢失所以 ES 通过 translog 日志文件来保证数据的可靠性在数据写入 memory buffer 的同时将数据也写入 translog 日志文件中当机器宕机重启时es 会自动读取 translog 日志文件中的数据恢复到 memory buffer 和 Filesystem cache 中去。 ES 数据丢失的问题translog 也是先写入 Filesystem cache然后默认每隔 5 秒刷一次到磁盘中所以默认情况下可能有 5 秒的数据会仅仅停留在 memory buffer 或者 translog 文件的 Filesystem cache中而不在磁盘上如果此时机器宕机会丢失 5 秒钟的数据。也可以将 translog 设置成每次写操作必须是直接 fsync 到磁盘但是性能会差很多。 flush 操作不断重复上面的步骤translog 会变得越来越大不过 translog 文件默认每30分钟或者 阈值超过 512M 时就会触发 commit 操作即 flush操作将 memory buffer 中所有的数据写入新的 segment 文件中 并将内存中所有的 segment 文件全部落盘最后清空 translog 事务日志。 将 memory buffer 中的数据 refresh 到 Filesystem Cache 中去清空 buffer创建一个新的 commit point提交点同时强行将 Filesystem Cache 中目前所有的数据都 fsync 到磁盘文件中删除旧的 translog 日志文件并创建一个新的 translog 日志文件此时 commit 操作完成 详细可参考https://blog.csdn.net/a745233700/article/details/118076845
3ES更新和删除流程
删除和更新都是写操作但是由于 Elasticsearch 中的文档是不可变的因此不能被删除或者改动以展示其变更所以 ES 利用 .del 文件 标记文档是否被删除磁盘上的每个段都有一个相应的.del 文件
删除操作文档其实并没有真的被删除而是在 .del 文件中被标记为 deleted 状态。该文档依然能匹配查询但是会在结果中被过滤掉。更新操作就是将旧的 doc 标识为 deleted 状态然后创建一个新的 doc。 memory buffer 每 refresh 一次就会产生一个 segment 文件 所以默认情况下是 1s 生成一个 segment 文件这样下来 segment 文件会越来越多此时会定期执行 merge。每次 merge 的时候会将多个 segment 文件合并成一个同时这里会将标识为 deleted 的 doc 给物理删除掉不写入到新的 segment 中然后将新的 segment 文件写入磁盘这里会写一个 commit point 标识所有新的 segment 文件然后打开 segment 文件供搜索使用同时删除旧的 segment 文件 有关segment段合并过程欢迎阅读这篇文章Elasticsearch搜索引擎ES的segment段合并原理 4ES的搜索流程
搜索被执行一共分为两个阶段
query阶段客户端发送请求到 coordinate node协调节点将搜索请求广播到所有的 primary shard 或 replica每个分片在本地执行搜索并构建一个匹配文档的大小为 from size 的优先队列。接着每个分片返回各自优先队列中 所有 docId 和 打分值 给协调节点由协调节点进行数据的合并、排序、分页等操作产出最终结果。Fetch阶段协调节点根据 Query阶段产生的结果去各个节点上查询 docId 实际的 document 内容最后由协调节点返回结果给客户端。 coordinate node 对 doc id 进行哈希路由将请求转发到对应的 node此时会使用 round-robin 随机轮询算法在 primary shard 以及其所有 replica 中随机选择一个让读请求负载均衡。接收请求的 node 返回 document 给 coordinate node 。coordinate node 返回 document 给客户端。 Query Then Fetch 的搜索类型在文档相关性打分的时候参考的是本分片的数据这样在文档数量较少的时候可能不够准确DFS Query Then Fetch 增加了一个预查询的处理询问 Term 和 Document frequency这个评分更准确但是性能会变差。
6ES在高并发下如何保证读写一致性
对于更新操作可以通过版本号使用乐观并发控制以确保新版本不会被旧版本覆盖。 每个文档都有一个_version 版本号这个版本号在文档被改变时加一。Elasticsearch使用这个 _version 保证所有修改都被正确排序当一个旧版本出现在新版本之后它会被简单的忽略。利用_version的这一优点确保数据不会因为修改冲突而丢失比如指定文档的version来做更改如果那个版本号不是现在的我们的请求就失败了。 对于写操作一致性级别支持 quorum/one/all默认为 quorum即只有当大多数分片可用时才允许写操作。但即使大多数可用也可能存在因为网络等原因导致写入副本失败这样该副本被认为故障副本将会在一个不同的节点上重建。 one写操作只要有一个primary shard是active活跃可用的就可以执行 all写操作必须所有的primary shard和replica shard都是活跃可用的才可以执行 quorum默认值要求ES中大部分的shard是活跃可用的才可以执行写操作 对于读操作可以设置 replication 为 sync(默认)这使得操作在主分片和副本分片都完成后才会返回如果设置replication 为 async 时也可以通过设置搜索请求参数 _preference 为 primary 来查询主分片确保文档是最新版本。
ES的性能提升相关
1建立索引阶段性能提升方法
如果是大批量导入可以设置 index.number_of_replicas: 0 关闭副本等数据导入完成之后再开启副本使用批量请求并调整其大小每次批量数据 5–15 MB 大是个不错的起始点。如果搜索结果不需要近实时性可以把每个索引的 index.refresh_interval 改到30s增加 index.translog.flush_threshold_size 设置从默认的 512 MB 到更大一些的值比如 1 GB使用 SSD 存储介质段和合并Elasticsearch 默认值是 20 MB/s。但如果用的是 SSD可以考虑提高到 100–200 MB/s。如果你在做批量导入完全不在意搜索你可以彻底关掉合并限流。
2ES的深度分页与滚动搜索scroll 深度分页深度分页其实就是搜索的深浅度比如第1页第2页第10页第20页是比较浅的第10000页第20000页就是很深了。搜索得太深就会造成性能问题会耗费内存和占用cpu。而且es为了性能他不支持超过一万条数据以上的分页查询。那么如何解决深度分页带来的问题我们应该避免深度分页操作限制分页页数比如最多只能提供100页的展示从第101页开始就没了毕竟用户也不会搜的那么深。 滚动搜索 一次性查询1万数据往往会造成性能影响因为数据量太多了。这个时候可以使用滚动搜索也就是 scroll。 滚动搜索可以先查询出一些数据然后再紧接着依次往下查询。在第一次查询的时候会有一个滚动id相当于一个锚标记 随后再次滚动搜索会需要上一次搜索滚动id根据这个进行下一次的搜索请求。每次搜索都是基于一个历史的数据快照查询数据的期间如果有数据变更那么和搜索是没有关系的。
3ES在部署的时候Linux的那些设置优化
关闭缓存 swap;堆内存设置为Min节点内存/2, 32GB;设置最大文件句柄数线程池队列大小根据业务需要做调整磁盘存储 raid 方式——存储有条件使用 RAID10增加单节点性能以及避免单节点存储故障。 参考文档 https://blog.csdn.net/JENREY/article/details/81290535 https://blog.csdn.net/qq_26803795/article/details/106423578 https://blog.csdn.net/a745233700/article/details/115585342
