如何建wap网站,做影视网站该怎么发展,企业信用信息网公示网官网查询,做网站设计需要哪些软件索引模板了解么
索引模板#xff0c;一种复用机制#xff0c;就像一些项目的开发框架如 Laravel 一样#xff0c;省去了大量的重复#xff0c;体力劳动。当新建一个 Elasticsearch 索引时#xff0c;自动匹配模板#xff0c;完成索引的基础部分搭建。
模板定义#xf…索引模板了解么
索引模板一种复用机制就像一些项目的开发框架如 Laravel 一样省去了大量的重复体力劳动。当新建一个 Elasticsearch 索引时自动匹配模板完成索引的基础部分搭建。
模板定义看似复杂拆分来看主要为如下几个部分
{ order: 0, // 模板优先级 template: sample_info*, // 模板匹配的名称方式 settings: {...}, // 索引设置 mappings: {...}, // 索引中各字段的映射定义 aliases: {...} // 索引的别名
}
模板优先级
一个模板可能绝大部分符合新建索引的需求但是局部需要微调此时如果复制旧的模板修改该模板后成为一个新的索引模板即可达到我们的需求但是这操作略显重复。此时可以采用模板叠加与覆盖来操作。模板的优先级是通过模板中的 order 字段定义的数字越大优先级越高。
索引模板的匹配
索引模板中的 template 字段定义的是该索引模板所应用的索引情况。如 template: tete* 所表示的含义是当新建索引时所有以 tete 开头的索引都会自动匹配到该索引模板。利用该模板进行相应的设置和字段添加等。
setting 部分
索引模板中的 setting 部分一般定义的是索引的主分片、拷贝分片、刷新时间、自定义分析器等。
Elasticsearch 是如何实现 master 选举的
前提条件
只有候选主节点mastertrue的节点才能成为主节点。
最小候选主节点数min_master_nodes的目的是防止脑裂。
实现步骤
第一步确认候选主节点数达标elasticsearch.yml 设置的值discovery.zen.minimum_master_nodes作用是只有足够的master候选节点时才可以选举出一个master。该参数必须设置为集群中master候选节点的quorum数量。quorum的算法master候选节点数量/21(就是必须超过所有候选主节点一般以上可以思考redis cluster、zk集群的脑裂问题也有类似的参数设置)第二步对所有候选主节点根据nodeId字典排序每次选举每个节点都把自己所知道节点排一次序然后选出第一个第0位节点暂且认为它是master节点。第三步如果对某个节点的投票数达到一定的值候选主节点数n/21并且该节点自己也选举自己那这个节点就是master。否则重新选举一直到满足上述条件。
【补充】master 节点的职责主要包括集群、节点和索引的管理不负责文档级别的管理data 节点可以关闭 http 功能。
如何解决ES集群的脑裂问题
【原因】
所谓集群脑裂是指 Elasticsearch 集群中的节点比如共 20 个可能因为网络问题其中的 10 个选了一个 master另外 10 个选了另一个 master 的情况。
【解决】
当集群 master 候选数量不小于 3 个时可以通过设置最少投票通过数量discovery.zen.minimum_master_nodes最小候选主节点数超过所有候选节点一半以上来解决脑裂问题
对公司ES集群了解ES集群架构索引数据大小分片数量
想了解应聘者之前公司接触的ES使用场景、规模有没有做过比较大规模的索引设计、规划、调优
解答
查看es集群状态
curl -XGET http://localhost:9200/_cat/health?v返回结果
{cluster: es-9pu872sa, #集群名称status: green, #集群状态 green代表健康yellow代表分配了所有主分片但至少缺少一个副本此时集群数据仍旧完整red代表部分主分片不可用可能已经丢失数据node.data: 8, #代表在线的数据节点的数量node.total: 11, #代表在线的节点总数量init: 0, #initializing_shards 初始化中的分片数量 正常情况为 0relo: 0, #relocating_shards 迁移中的分片数量正常情况为 0pending_tasks: 0, #准备中的任务任务指迁移分片等 正常情况为 0unassign: 0, #unassigned_shards 未分配的分片 正常情况为 0pri: 3699, #active_primary_shards 存活的主分片数量 正常情况下 shards的数量是pri的两倍shards: 4343, #active_shards 存活的分片数量active_shards_percent: 100.0%, #正常分片百分比 正常情况为 100%max_task_wait_time: -, #任务最长等待时间epoch: 1696748727,timestamp: 07:05:27
}
模块运营ES集群11个节点6个hot节点16C64G配置5个warm节点4C16G。集群因为有部门内其他项目也在用跟我们业务相关主要索引在8个以上例如模块运营
主要业务索引
菜单访问记录按天 mcs_menu_user_access-yyyyMMdd
菜单访问统计按月 mcs_menu_user_access_aggregation-yyyyMM
菜单访问小时统计按月 mcs_menu_user_access_aggregation_hour-yyyyMM
事件访问明细索引 mcs_menu_user_access_action-yyyyMM
数据量计算前提公司菜单总数在2300个左右公司员工访问总人数在5-6w左右
菜单访问记录索引mcs_menu_user_access6个分片没有副本。每日数据增量在600w左右一个月30天数据量在2亿左右。单索引大概4G一个月所有该索引大概120G菜单访问统计按天索引mcs_menu_user_access_aggregation6个分片没有副本。一个月也在1300w左右单索引一个月大概15G的数据量菜单访问小时统计按月索引mcs_menu_user_access_aggregation_hour 6个分片没有副本。一个月40002左右的数据。一个月所有该索引大概30G事件访问明细按月索引 mcs_menu_user_access_action 12个分片没有副本。一个月数据量大概在5亿作业占用磁盘大概在400G
索引增量根据日期有的按月有的按天递增每月递增33索引以上。
菜单访问相关的数据量没那么大索引分片在6个分片为节省磁盘和性能没有副本
事件访问明细索引数据量笔记打索引分片在12个一样没有副本 保存近1年的数据1年以前的数据删除。
这一年的数据做采取了冷热分离机制热数据存储到SSD提高检索效率冷数据定期进行shrink操作以缩减存储近6个月的数据在hot节点前6个月的数据移到warm节点 冷热数据分离了解么
ES集群的索引写入及查询速度主要依赖于磁盘的IO速度冷热数据分离的关键为使用SSD磁盘存储数据。若全部使用SSD成本过高且存放冷数据较为浪费因而使用普通SATA磁盘与SSD磁盘混搭可做到资源充分利用性能大幅提升的目标。为了解决控制成本的前提下读写性能问题Elasticsearch冷热分离架构应运而生。
冷数据索引查询频率低基本无写入一般为当天或最近2天以前的数据索引
热数据索引查询频率高写入压力大一般为当天数据索引 实现原理
Hot节点设置索引节点写节点同时保持近期频繁使用的索引。 属于IO和CPU密集型操作建议使用SSD的磁盘类型保持良好的写性能节点的数量设置一般是大于等于3个。将节点设置为hot类型node.attr.box_type: hot
Warm节点设置 用于不经常访问的read-only索引。由于不经常访问一般使用普通的磁盘即可。内存、CPU的配置跟Hot节点保持一致即可节点数量一般也是大于等于3个。将节点设置为warm类型node.attr.box_type: warm
可以通过两种方式对数据进行冷热的那种处理
1、针对索引设置冷热属性指定某个索引为热索引另一个索引为冷索引。通过索引的分布来实现控制数据分布的目的。业务上根据实际情况对索引设置冷热属性如果按照时间定期处理。
index.routing.allocation.include.{attribute}表示索引可以分配在包含多个值中其中一个的节点上。index.routing.allocation.require.{attribute}表示索引要分配在包含索引指定值的节点上通常一般设置一个值。index.routing.allocation.exclude.{attribute}表示索引只能分配在不包含所有指定值的节点上。
2、通过索引生命周期管理ES (版本6.6) 提供了索引生命周期管理功能。索引生命周期管理可以通过 API 或者 kibana 界面配置详情可参考 index-lifecycle-management。使用索引生命周期管理可以实现索引数据的自动滚动跟过期并结合冷热分离架构进行数据的降冷跟删除。 一般通过kibana界面去创建代理任务进行配置实现索引的动态管理索引的生命周期被分为Hot phrase,Warm phase, Cold phase,Delete phrase四个阶段
Hot phrase: 该阶段可以根据索引的文档数大小时长决定是否调用rollover API来滚动索引Warm phrase: 当一个索引在Hot phrase被roll over后便会进入Warm phrase进入该阶段的索引会被设置为read-only, 用户可以为这个索引设置要使用的attribute 如对于冷热分离策略这里可以选择temperature: warm属性。另外还可以对索引进行forceMerge, shrink等操作Cold phrase: 可以设置当索引rollover一段时间后进入cold阶段这个阶段也可以设置一个属性。从冷热分离架构可以看出冷热属性是具备扩展性的不仅可以指定hot, warm, 也可以扩展增加hot, warm, cold, freeze等多个冷热属性。如果想使用三层的冷热分离的话这里可以指定为temperature: cold, 此处还支持对索引的freeze操作Delete phrase: 可以设置索引rollover一段时间后进入delete阶段进入该阶段的索引会自动被删除。 分片不均衡原因解决方案
可能存在的部分原因有以下几种
Shard设置不合理大多数负载不均问题是由于shard设置不合理导致建议优先排查。Segment大小不均存在典型的冷热数据需求场景。说明例如查询中添加了routing或查询频率较高的热点数据则必然导致数据出现负载不均。没有释放长连接导致流量不均。说明该问题时常暴露于采用负载均衡及多可用区架构部署时。
解决方案
方案一手动移动分片
例如移动node-1的分片0到node-4
curl -XPOST http://localhost:9200/_cluster/reroute -d {commands:[{move:{index:indexName, # 索引名shard: 0, # 需要移动的分片from_node:node-1, # 从哪个节点移出来to_node:node-4 # 需要移到哪个节点
}}]}
优点操作简单恢复时间短不必修改master node的配置master node长期负载后高
缺点索引大移动时有很高的IO索引容易损坏需要做备份不能解决master node既是数据节点又是负载均衡转发器的问题
【注意】分片和副本无法移动到同一个节点
方案二重建索引从另外一个集群导入
删除原来的索引重新建立索引利用elasticsearch dump等工具从另一个集群中把数据导入到新的索引中
优点可以重新配置master node和data node主从负载均匀
缺点费时间容易数据丢失需要验证数据的一致性
方案三配置平衡参数
使用命令恢复平衡
PUT_cluster/settings
{persistent: {cluster.routing.rebalance.enable: all}
} 解决Elasticsearch分片未分配的问题
原因
出现这个问题的原因是原有分片未正常关闭和清理所以当分片要重新分配回出问题节点的时候没有办法获得分片锁。
这不会造成分片数据丢失只需要重新触发一下分配。
unassigned 分片问题可能的原因如下:
INDEX_CREATED: 由于创建索引的API导致未分配。CLUSTER_RECOVERED: 由于完全集群恢复导致未分配。INDEX_REOPENED: 由于打开open或关闭close一个索引导致未分配。DANGLING_INDEX_IMPORTED: 由于导入dangling索引的结果导致未分配。NEW_INDEX_RESTORED: 由于恢复到新索引导致未分配。EXISTING_INDEX_RESTORED: 由于恢复到已关闭的索引导致未分配。REPLICA_ADDED: 由于显式添加副本分片导致未分配。ALLOCATION_FAILED: 由于分片分配失败导致未分配。NODE_LEFT: 由于承载该分片的节点离开集群导致未分配。REINITIALIZED: 由于当分片从开始移动到初始化时导致未分配例如使用影子shadow副本分片。REROUTE_CANCELLED: 作为显式取消重新路由命令的结果取消分配。REALLOCATED_REPLICA: 确定更好的副本位置被标定使用导致现有的副本分配被取消出现未分配。
解决方案如下
执行修复命令: POST /_cluster/reroute?retry_failed Elasticsearch 索引文档的过程
想了解ES的底层原理不只是关注业务本身。
这里的索引文档应该理解为文档写入ES创建索引的过程。这里说下单文档索引的过程 客户发送请求向ES集群某节点写入数据。如果没有指定路由/协调节点请求的节点作为协调节点第1个节点协调节点接受到请求后使用文档_id 来确定文档属于哪个分片计算分片的算法是shard hash(routing) % number_of_primary_shardsrouting默认是文档_id也可以自定义routing。确定分片之后请求会被转到另外的节点假定节点 3。因此分片 0 的主分片分配到节点3上面节点 3 在主分片上执行写操作如果成功则将请求并行转发到节点 1和节点 2 的副本分片上等待结果返回。所有的副本分片都报告成功节点 3 将向协调节点节点 1报告成功节点 1 向请求客户端报告写入成功。 Elasticsearch 写入数据的过程
es的写入过程还是很复杂的整个过程中还涉及到refresh刷新、强制flush一些操作画个图可能更好理解一些 添加doc的流程
将数据写入buffer缓冲区域同步会将记录写入到translog日志文件中之后返回结果。写到buffer缓冲区中的数据是还不能被search到的可以通过get得到数据之后buffer缓冲区中的数据在空间被占用或者通过refresh近实时性的刷新操作将数据刷到segment段中之后这个时候才能被search之后通过fsync操作将segment中的数据写入到磁盘还会清空buffer缓冲区等待接收新的数据
translog 和 flush操作的作用
translog文件为了保证数据安全而存在的机制因为文档doc刚开始是写到内存中的还没有入到磁盘。如果此时服务器宕机那么数据就丢失了。引入translog文档写入buffer时是同时写入到translog文件中的这个是落盘的。这样就能防止数据丢失并且translog是追加的方式因此性能比较好
flush操作每隔30分钟或者translog日志文件达到一定大小默认512M的时候就会触发一次flush操作此时ES会执行一次flush操作先将segment刷到磁盘。原有translog文件已经落盘会生成一份新的translog日志文件
近实时性-refresh操作
es接收数据请求时先存入buffer缓冲区中默认每隔一秒会从buffer中将数据写入segment中这个过程叫做refresh
当一个文档写入Lucene后是不能被立即查询到的Elasticsearch提供了一个refresh操作会定时地为内存中新写入的数据生成一个新的segment此时被处理的文档均可以被检索到。refresh操作的时间间隔由refresh_interval参数控制默认为1s, 当然还可以在写入请求中带上refresh表示写入后立即refresh另外还可以调用refresh API显式refresh。
产生的问题
于是这个过程中就产生了大量的segment数量越多就会占用更多的内存并且还会影响查询的效率因为查询数据是要具体到分片上去的其实就是遍历segment文件进行查询segment越多就会影响性能
merge操作
由于refresh操作1秒钟执行一次每次都会产生一个segment段会产生大量的segment段。这对于查询性能来说影响很大并且占用空间。因此ES会运行一个任务检测segment对符合要求的segment段进行合并操作提高查询速度。用户也可以手动调用_forcemerge API强制合并merge 常用基本调优思路有哪些
设计阶段调优
根据业务增量需求采取基于日期模板创建索引常用的方式就是基于索引模板在索引数据的时候动态创建索引。获取也可以通过rollover API动态滚动创建索引。rollover API翻滚索引指的就是 对满足特定条件的拥有别名的索引进行采用旧索引的配置创建新索引并对将新索引别名下的is_write_index设为true使用别名进行索引管理每天定时在业务量低的时间点对索引做force_merge强制合并segment段操作手动释放磁盘空间force_merge强制合并是指ES索引文档会产生很多个小segment段每一个段都会占用cpu资源、句柄、内存等并且查询的时候要到段上面进行搜索段越多效率越慢所以需要进行合并段操作对这些segment进行合并减少磁盘空间优化查询效率采取冷热分离机制热数据存储到SSD提高检索效率冷数据定期进行shrink压缩操作以缩减存储采取curator进行索引的生命周期管理仅针对需要分词的字段合理的设置分词器Mapping阶段充分结合各个字段的属性是否需要检索、是否需要存储等
写入调优思路
写入前副本数设置为 0设置副本数 number_of_replicas 0写入前关闭 refresh_interval 设置为-1禁用刷新机制写入过程中采取 bulk 批量写入写入后恢复副本数和刷新间隔尽量使用自动生成的 id。
查询调优思路
禁用 wildcardwildcard 检索可以定义为支持通配符的模糊检索。类似于mysql的like禁用批量 terms成百上千的场景充分利用倒排索引机制能 keyword 类型尽量 keyword数据量大时候可以先基于时间敲定索引再检索设置合理的路由机制。
