特产网站建设的目的,家居商城网站模板,wordpress 商业网站,网站建设找泉州效率网络一、Elasticsearch集群配置
1、硬件选择
Elasticsearch的基础是 Lucene #xff0c;所有的索引和文档数据是存储在本地的磁盘中#xff0c;
具体的路径可在 ES 的配置文件 ../config/elasticsearch.yml 中配置#xff0c;如下#xff1a;磁盘在现代服务器上通常都是瓶颈。…一、Elasticsearch集群配置
1、硬件选择
Elasticsearch的基础是 Lucene 所有的索引和文档数据是存储在本地的磁盘中
具体的路径可在 ES 的配置文件 ../config/elasticsearch.yml 中配置如下磁盘在现代服务器上通常都是瓶颈。Elasticsearch 重度使用磁盘你的磁盘能处理的吞吐量越大你的节点就越稳定。这里有一些优化磁盘 I/O 的技巧1、使用 SSD。就像其他地方提过的 他们比机械磁盘优秀多了。2、使用 RAID 0。条带化 RAID 会提高磁盘 I/O代价显然就是当一块硬盘故障时整个就故障了。
不要使用镜像或者奇偶校验 RAID 因为副本已经提供了这个功能。3、另外使用多块硬盘并允许 Elasticsearch 通过多个 path.data
目录配置把数据条带化分配到它们上面。4、不要使用远程挂载的存储比如 NFS 或者 SMB/CIFS 。这个引入的延迟对性能来说完全是背道而驰的。
2、分片策略
2.1、分片大小保持在10GB-50GB之间
分片大小保持在10GB-50GB之间大的分片在故障恢复时会占用较长的时间。当某个节点发生故障时Elasticsearch会根据剩余节点的数据自动的重新平衡分片。恢复进程通常是在网络之间拷贝分片的内容因此一个100GB的分片会比50GB的分片花费更多的时间。相比之下小分片的开销更大搜索效率也更低。搜索50个1GB分片将比搜索一个包含相同数据的50GB分片占用更多资源。分片的大小并没有强制的限制。但经验值是10-50GB之间的分片通常在日志和时间序列的数据流索引上表现更好。 总结打分片性能好故障恢复慢小分片性能差故障恢复快。
2.2、每GB堆内存对应少于20个分片
数据节点可以容纳的分片数与节点的堆内存成比例。例如具有30GB堆内存的节点最多应该有600个分片。越是低于此比例就越能保持节点性能。如果发现节点超过每GB 20个以上的分片请考虑添加另一个节点。单节点分片数计算JVM堆大小*20
2.3、避免节成为热点
如果分配给特定节点的分片太多该节点可能会成为热点。例如如果单个节点包含的分片太多索引量太大则该节点可能会出现问题。
3、推迟分片分配
推迟因通讯中断导致分片再次检测平衡。
对于节点瞬时中断的问题默认情况集群会等待一分钟来查看节点是否会重新加入如果这个节点在此期间重新加入重新加入的节点会保持其现有的分片数据不会触发新的分片分配。这样就可以减少 ES 在自动再平衡可用分片时所带来的极大开销。通过修改参数delayed_timeout 可以延长再均衡的时间可以全局设置也可以在索引级别进行修改#PUT /_all/_settings
{settings: {index.unassigned.node_left.delayed_timeout: 5m}
}
4、路由选择 当我们查询文档的时候Elasticsearch 如何知道一个文档应该存放到哪个分片中呢 它其实是通过下面这个公式来计算出来 shard hash(routing) % number_of_primary_shards routing默认值是文档的 id 也可以采用自定义值比如用户 id 。 不带routing 查询 在查询的时候因为不知道要查询的数据具体在哪个分片上所以整个过程分为2 个步骤 1. 分发请求到达协调节点后协调节点将查询请求分发到每个分片上。 2. 聚合 : 协调节点搜集到每个分片上查询结果在将查询的结果进行排序之后给用户返回结果。 带routing 查询 查询的时候可以直接根据routing 信息定位到某个分片查询不需要查询所有的分片经过协调节点排序。 向上面自定义的用户查询如果routing 设置为 userid 的话就可以直接查询出数据来效率提升很多。 5、写入速度优化 ES的默认配置是综合了数据可靠性、写入速度、搜索实时性等因素。实际使用时我们需要根据公司要求进行偏向性的优化。 针对于搜索性能要求不高但是对写入要求较高的场景我们需要尽可能的选择恰当写优化策略。 综合来说可以考虑以下几个方面来提升写索引的性能 1、加大 Translog Flush 目的是降低 Iops 、 Writeblock 。 2、增加 Index Refresh 间隔目的是减少 Segment Merge 的次数。 3、调整 Bulk 线程池和队列。 4、优化节点间的任务分布。 5、优化 Lucene 层的索引建立目的是降低 CPU 及 IO 5.1、批量数据提交 ES提供了 Bulk API 支持批量操作当我们有大量的写任务时可以使用 Bulk 来进行批量写入。 通用的策略如下 Bulk 默认设置批量提交的数据量不能超过 100M 。数据条数一般是根据文档的大小和服务器性能而定的但是单次批处理的数据大小应从 5MB 15MB 逐渐增加当性能没有提升时把这个数据量作为最大值。 5.2 优化存储设备 ES是一种密集使用磁盘的应用在段合并的时候会频繁操作磁盘所以对磁盘要求较高当磁盘速度提升之后集群的整体性能会大幅度提高。 5.3 合理使用段合并 1、segment段创建过程 当我们往 ElasticSearch 写入数据时数据是先写入 memory buffer然后定时默认每隔1s将 memory buffer 中的数据写入一个新的 segment 文件中并进入 Filesystem cache同时清空 memory buffer这个过程就叫做 refresh每个 Segment 事实上是一些倒排索引的集合 只有经历了 refresh 操作之后数据才能变成可检索的。 ElasticSearch 每次 refresh 一次都会生成一个新的 segment 文件这样下来 segment 文件会越来越多。那这样会导致什么问题呢因为每一个 segment 都会占用文件句柄、内存、cpu资源更加重要的是每个搜索请求都必须访问每一个segment这就意味着存在的 segment 越多搜索请求就会变的更慢。 每个 segment 是一个包含正排空间占比90~95% 倒排空间占比5~10%的完整索引文件每次搜索请求会将所有 segment 中的倒排索引部分加载到内存进行查询和打分然后将命中的文档号拿到正排中召回完整数据记录。如果不对segment做配置就会导致查询性能下降 那么 ElasticSearch 是如何解决这个问题呢 ElasticSearch 有一个后台进程专门负责 segment 的合并定期执行 merge 操作将多个小 segment 文件合并成一个 segment在合并时被标识为 deleted 的 doc或被更新文档的旧版本不会被写入到新的 segment 中。合并完成后然后将新的 segment 文件 flush 写入磁盘然后创建一个新的 commit point 文件标识所有新的 segment 文件并排除掉旧的 segement 和已经被合并的小 segment然后打开新 segment 文件用于搜索使用等所有的检索请求都从小的 segment 转到 大 segment 上以后删除旧的 segment 文件这时候索引里 segment 数量就下降了。如下 2、segment的merge 对性能的影响 segment 合并的过程需要先读取小的 segment归并计算再写一遍 segment最后还要保证刷到磁盘。可以说合并大的 segment 需要消耗大量的 I/O 和 CPU 资源同时也会对搜索性能造成影响。所以 Elasticsearch 在默认情况下会对合并线程进行资源限制确保它不会对搜索性能造成太大影响。 默认情况下归并线程的限速配置 indices.store.throttle.max_bytes_per_sec 是 20MB。对于写入量较大磁盘转速较高甚至使用 SSD 盘的服务器来说这个限速是明显过低的。对于 ELK Stack 应用建议可以适当调大到 100MB或者更高。设置方式如下 PUT /_cluster/settings { persistent : { indices.store.throttle.max_bytes_per_sec : 100mb } } 或者不限制 PUT /_cluster/settings { transient : { indices.store.throttle.type : none } } 5.4 减少Refresh的次数 Lucene在新增数据时采用了延迟写入的策略默认情况下索引的 refresh_interval 为1 秒。 Lucene将待写入的数据先写到内存中超过 1 秒默认 时就会触发一次 Refresh然后 Refresh 会把内存中的的数据刷新到操作系统的文件缓存系统中。 如果我们对搜索的实效性要求不高可以将Refresh 周期延长例如 30 秒。 这样还可以有效地减少段刷新次数但这同时意味着需要消耗更多的Heap 内存。 5.5、加大Flush设置
Flush的主要目的是把文件缓存系统中的段持久化到硬盘当 Translog 的数据量达到512MB 或者 30 分钟时会触发一次 Flush。index.translog.flush_threshold_size 参数的默认值是 512MB 我们进行修改。增加参数值意味着文件缓存系统中可能需要存储更多的数据所以我们需要为操作系统的文件缓存系统留下足够的空间。
5.6、减少副本的数量
ES为了保证集群的可用性提供了 Replicas 副本支持然而每个副本也会执行分析、索引及可能的合并过程所以 Replicas 的数量会严重影响写索引的效率。当写索引时需要把写入的数据都同步到副本节点副本节点越多写索引的效率就越慢查询并发越高。
如果我们需要大批量进行写入操作可以先禁止Replica 复制设置index.number_of_replicas: 0 关闭副本。在写入完成后 Replica 修改回正常的状态。
6、内存设置
Xmx 和 Xms 的大小是相同的。其目的是为了能够在 Java 垃圾回收机制清理完堆区后不需要重新分隔计算堆区的大小而浪费资源可以减轻伸缩堆大小带来的压力。
假设你有一个64G 内存的机器按照正常思维思考你可能会认为把 64G 内存都给ES 比较好但现实是这样吗 越大越好
虽然内存对 ES 来说是非常重要的但是答案是否定的
因为ES 堆内存的分配需要满足以下两个原则
不要超过物理内存的 50%。 Lucene 的设计目的是把底层 OS 里的数据缓存到内存中。
Lucene的段是分别存储到单个文件中的这些文件都是不会变化的所以很利于缓存同时操作系统也会把这些段文件缓存起来以便更快的访问。如果我们设置的堆内存过大Lucene 可用的内存将会减少就会严重影响降低 Lucene 的全文本查询性能。
堆内存的大小最好不要超过 32GB 。在 Java 中所有对象都分配在堆上然后有一个 Klass Pointer 指针指向它的类元数据。这个指针在64 位的操作系统上为 64 位
7、集群模式
7.1、集群类型
1、master node节点
整个集群的管理者、索引管理、分片管理以及整个集群的状态的管理master节点是从master候选节点中选出的成为master候选节点的方式node.master:true 默认true data node数据节点存储主要数据负责索引的数据的检索和聚合等操作设置data node的方式如下 node.master:true node.data:false 2、data node节点
该节点和应用创建连接、接收索引请求会存储分配在该node上的shard的数据并负责这些shard的写入、查询等ES集群的性能取决于该节点的个数每个节点最优配置的情况下data节点会占用大量的CPU、io和内存data节点的分片执行查询语句、获得查询结果后将结果反馈给Coordinating此过程较消耗硬件资源设置成为data节点的方式 node.data:true node.master:false 3、coordinating node节点
协调节点所有节点都可以接受来自客户端的请求进行转发因为每个节点都知道集群的所有索引分片的分布情况但是别的节点都还肩负着别的工作如果请求压力过大可能会拖垮整个集群的响应速度所以就专门有了这个协调节点他什么都不用做只处理请求和请求结果这种设计的好处是,如果集群资源不足,被干死的是coordinating node, marster、data节点安全,设置成为coordinating node节点的方式 node.data:false node.master:false 4、ingest node节点
预处理节点主要是对数据进行预处理比如对字段重命名分解字段内容增加字段等类似于Logstash 就是对数据进行预处理ingest里面可以定义pipeline管道pipeline可以由很多个processor官方预定义28个构成用来出来预处理数据使用方式先定义好预处理pipeline然后在存储数据的时候指定pipeline如成为ingest node的方式 node.ingest:true 默认true
7.2、稳定压倒一切的配置
3个master参与选主、N个data存储、计算、coordinating高并发请求场景需要设置次节点 8、其他设置
1、cluster.name配置ES 的集群名称。建议改成与所存数据相关的名称ES 会自动发现在同一网段下的集群名称相同的节点2、node.name集群中的节点名在同一个集群中不能重复。节点的名称一旦设置就不能再改变了。当然也可以设置成服务器的主机名称3、node.data指定该节点是否存储索引数据。默认为True 。数据的增、删、改、查都是在 Data 节点完成的。4、index.number_of_shards设置都索引分片个数。也可以在创建索引时设置该值具体设置为多大的值要根据数据量的大小来定。如果数据量不大则设置成 1 时效率最高5、index.number_of_replicas设置默认的索引副本个数。副本数越多集群的可用性越 好但是写索引时需要同步的数据越多。6、transport.tcp.compress设置在节点间传输数据时是否压缩默认为False不压缩7、discovery.zen.minimum_master_nodes设置在选举Master 节点时需要参与的最少的候选主节点数默认为 1 。如果使用默认值则当网络不稳定时有可能会出现脑裂。合理的数值为 (master_eligible_nodes/2)1 其中master_eligible_nodes 表示集群中的候选主节点数8、discovery.zen.ping.timeout 设置在集群中自动发现其他节点时Ping 连接的超时时间默认为 3 秒。在较差的网络环境下需要设置得大一点防止因误判该节点的存活状态而导致分片的转移
二、开发注意优化
1、客户端选择
目前支持客户端有sql、dml、dml。为了开发效率建议选择sql方式es7版本对sql支持度比较友好其他版本可以安装es-sql插件实现sql效果。
2、字段类型设置
无分词需求字段类型设置为keyworld不会被分词
3、搜索的深度分页设置
索引深度不易过深入否则会导致分页性能低。如果是数据导出需求可以用游标实现如果数据量过大可以通过设置新索引的方式做。比如index_2021_电器、index_2021_食品....
4、创建索引
1、Mapping设置与Query查询优化问题 在ES中创建Mappings时默认_source是enabletrue会存储整个document的值当执行search操作的时会返回整个document的信息。如果只想返回document的部分fields但_source会返回原始所有的内容当某些不需要返回的field很大时ES查询的性能会降低这时候可以考虑使用store结合_source的enablefalse来创建mapping。 2、设置索引刷新频率
index.refresh_interval刷新操作频率最近对索引的更改既可见默认1s。-1关闭刷新操作。设置符合自己项目需求越大性能越好。
5、explain分析慢查询
#es 性能分析语句
GET online_exercise/_doc/_search
{explain : true,query: {match_all: {}}
}
