云服务器内容精选

  • 写入性能优化 基于Elasticsearch的数据写入流程分析,有以下几种性能优化方案。 表1 写入性能优化 优化方案 方案说明 使用SSD盘或升级集群配置 使用SSD盘可以大幅提升数据写入与merge操作的速度,对应到 CSS 服务,建议选择“超高IO型”存储,或者超高IO型主机。 采用Bulk API 客户端采用批量数据的写入方式,每次批量写入的数据建议在1~10MB之间。 随机生成_id 如果采用指定_id的写入方式,数据写入时会先触发一次查询操作,进而影响数据写入性能。对于不需要通过_id检索数据的场景,建议使用随机生成的_id。 设置合适的分片数 分片数建议设置为集群数据节点的倍数,且分片的大小控制在50GB以内。 关闭副本 数据写入与查询错峰执行,在数据写入时关闭数据副本,待数据写入完成后再开启副本。 Elasticsearch 7.x版本中关闭副本的命令如下: PUT {index}/_settings { "number_of_replicas": 0 } 调整索引的刷新频率 数据批量写入时,可以将索引的刷新频率“refresh_interval”设置为更大的值或者设置为“-1”(表示不刷新),通过减少分片刷新次数提高写入性能。 Elasticsearch 7.x版本中,将更新时间设置为15s的命令如下: PUT {index}/_settings { "refresh_interval": "15s" } 优化写入线程数与写入队列大小 为应对突发流量,可以适当地提升写入线程数与写入队列的大小,防止突发流量导致出现错误状态码为429的情况。 Elasticsearch 7.x版本中,可以修改如下自定义参数实现写入优化:thread_pool.write.size,thread_pool.write.queue_size。 设置合适的字段类型 指定集群中各字段的类型,防止Elasticsearch默认将字段猜测为keyword和text的组合类型,增加不必要的数据量。其中keyword用于关键词搜索,text用于全文搜索。 对于不需要索引的字段,建议“index”设置为“false”。 Elasticsearch 7.x版本中,将字段“field1”设置为不建构索引的命令如下: PUT {index} { "mappings": { "properties": { "field1":{ "type": "text", "index": false } } } } 优化shard均衡策略 Elasticsearch默认采用基于磁盘容量大小的Load balance策略,在多节点场景下,尤其是在新扩容的节点上,可能出现shard在各节点上分配不均的问题。为避免这类问题,可以通过设置索引级别的参数“routing.allocation.total_shards_per_node”控制索引分片在各节点的分布情况。此参数可以在索引模板中配置,也可以修改已有索引的setting生效。 修改已有索引的setting的命令如下: PUT {index}/_settings { "index": { "routing.allocation.total_shards_per_node": 2 } }
  • 数据写入流程 图1 数据写入流程 如图1所示,以Elasticsearch集群为例,介绍客户端往Elasticsearch或OpenSearch集群中写入数据的流程。图中的P表示主分片Primary,R表示副本分片Replica,主副分片在数据节点Node里是随机分配的,但是不能在同一个节点里。 客户端向Node1发送写数据请求,此时Node1为协调节点。 节点Node1根据数据的_id将数据路由到分片2,此时请求会被转发到Node3,并执行写操作。 当主分片写入成功后,它将请求转发到Node2的副本分片上。当副本写入成功后,Node3将向协调节点报告写入成功,协调节点向客户端报告写入成功。 Elasticsearch中的单个索引由一个或多个分片(shard)组成,每个分片包含多个段(Segment),每一个Segment都是一个倒排索引。 图2 Elasticsearch的索引组成 如图3所示,将文档插入Elasticsearch时,文档首先会被写入缓冲区Buffer中,同时写入日志Translog中,然后在刷新时定期从该缓冲区刷新文档到Segment中。刷新频率由refresh_interval参数控制,默认每1秒刷新一次。更多写入性能相关的介绍请参见Elasticsearch的官方介绍Near Real-Time Search。 图3 文档插入Elasticsearch的流程
  • 问题现象 查看日志提示: [ERROR] Mpp task queryDataAnalyseById or updateDataAnalyseHistoryEndTimesAndResult fail, dataAnalyseId:17615 org.postgresql.util.PSQLException: ERROR: memory is temporarily unavailablesql:vacuum full dws_customer_360.t_user_resource;
  • 查询性能优化 基于Elasticsearch的数据查询流程分析,有以下几种性能优化方案。 表1 查询性能优化 优化方案 方案说明 通过routing减少检索扫描的分片数 在数据入库时指定routing值,将数据路由到某个特定的分片,查询时通过该routing值将请求转发到某个特定的分片,而不是相关索引的所有分片,进而提升集群整体的吞吐能力。 Elasticsearch 7.x版本中,设置命令如下: 指定routing值插入数据 PUT /{index}/_doc/1?routing=user1{ "title": "This is a document"} 根据routing值去查询数据 GET /{index}/_doc/1?routing=user1 采用index sorting减少检索扫描的Segments数 当请求落到某个分片时,会逐个遍历其Segments,通过使用index sorting,可以使得范围查询、或者排序查询在段内提前终止(early-terminate)。 Elasticsearch 7.x版本中,示例命令如下: //假设需要频繁使用字段date做范围查询。PUT {index}{ "settings": { "index": { "sort.field": "date", "sort.order": "desc" } }, "mappings": { "properties": { "date": { "type": "date" } } }} 增加query cache提升缓存命中的概率 当filter请求在段内执行时,会通过bitset保留其刷选结果,当下一个类似的查询过来时,就可以复用之前查询的结果,以此减少重复查询。 增加query cache可以通过修改集群的参数配置实现,将自定义缓存参数“indices.queries.cache.size”设置为更大的值。具体操作请参见参数配置,修改参数配置后一定要重启集群使参数生效。 提前Forcemerge,减小需要扫描的Segments数 对于定期滚动后的只读索引,可以定期执行forcemerge,将小的Segments合并为大的Segments,并将标记为“deleted”状态的索引彻底删除,提升查询效率。 Elasticsearch 7.x版本中,配置示例如下: //假设配置索引forcemerge后segments数量为10个。POST /{index}/_forcemerge?max_num_segments=10
  • 数据查询流程 图1 数据查询流程 如图1所示,以Elasticsearch集群为例,介绍客户端往Elasticsearch或OpenSearch集群发送查询请求的流程。图中的P表示主分片Primary,R表示副本分片Replica,主副分片在数据节点Node里是随机分配的,但是不能在同一个节点里。 客户端向Node1发送查询请求,此时Node1为协调节点。 节点Node1根据查询请求的索引以及其分片分布,进行分片选择;然后将请求转发到Node1、Node2、Node3。 各分片分别执行查询任务;当各分片查询成功后,将查询结果汇聚到Node1,然后协调节点向客户端返回查询结果。 对于某个查询请求,其在节点上默认可并行查询5个分片,多于5个分片时将分批进行查询;在单个分片内,通过逐个遍历各个Segment的方式进行查询。 图2 Elasticsearch的索引组成