赞
踩
GET、POST、PUT、DELETE、HEAD。
id | content |
---|---|
1001 | my name is zhang san |
1002 | i name is li si |
1003 | my name is wang wu |
keyword | id |
---|---|
name | 1001,1002,1003 |
zhang | 1001a |
my | 1001,1003 |
PUT请求:http://127.0.0.1:9200/索引名称
返回值:
{ "acknowledged"【响应结果】: true, # true 操作成功 //创建索引是否成功 "shards_acknowledged"【分片结果】: true, # 分片操作成功 "index"【索引名称】: "shopping" //创建的索引名称 } # 注意:创建索引库的分片数默认 1 片,在 7.0.0 之前的 Elasticsearch 版本中,默认 5 片
表头 | 含义 |
---|---|
health | 当前服务器健康状态: green(集群完整) yellow(单点正常、集群不完整) red(单点不正常) |
status | 索引打开、关闭状态 |
index | 索引名 |
uuid | 索引统一编号 |
pri | 主分片数量 |
rep | 副本数量 |
docs.count | 可用文档数量 |
docs.deleted | 文档删除状态(逻辑删除) |
store.size | 主分片和副分片整体占空间大小 |
pri.store.size | 主分片占空间大小 |
查看单个索引GET响应返回结果 { "shopping"【索引名】: { "aliases"【别名】: {}, "mappings"【映射】: {}, "settings"【设置】: { "index"【设置 - 索引】: { "creation_date"【设置 - 索引 - 创建时间】: "1614265373911", "number_of_shards"【设置 - 索引 - 主分片数量】: "1", "number_of_replicas"【设置 - 索引 - 副分片数量】: "1", "uuid"【设置 - 索引 - 唯一标识】: "eI5wemRERTumxGCc1bAk2A", "version"【设置 - 索引 - 版本】: { "created": "7080099" }, "provided_name"【设置 - 索引 - 名称】: "shopping" } } } }
全部查询:_search
单条数据查询:_doc
全量更新:PUT
单属性更新:POST
删除数据:DELETE
创建文档:PUT响应返回结果 { "_index"【索引】: "shopping", "_type"【类型-文档】: "_doc", "_id"【唯一标识】: "Xhsa2ncBlvF_7lxyCE9G", #可以类比为 MySQL 中的主键,随机生成 "_version"【版本】: 1, "result"【结果】: "created", #这里的 create 表示创建成功 "_shards"【分片】: { "total"【分片 - 总数】: 2, "successful"【分片 - 成功】: 1, "failed"【分片 - 失败】: 0 }, "_seq_no": 0, "_primary_term": 1 }
查看文档:GET响应返回结果 { "_index"【索引】: "shopping", "_type"【文档类型】: "_doc", "_id": "1", "_version": 2, "_seq_no": 2, "_primary_term": 2, "found"【查询结果】: true, # true 表示查找到,false 表示未查找到 "_source"【文档源信息】: { "title": "华为手机", "category": "华为", "images": "http://www.gulixueyuan.com/hw.jpg", "price": 4999.00 } }
多条件查询写法: { • "query":{//表示查询 • "match":{//部分匹配(match_all//全量查询,match_phrase//全匹配) • "条件key":"条件value" • } • }, • "from":0,//起始位置(页码-1*每页数据条数) • "size":2,//每页查询条数 • "_soource":{ • "title"//想要查询出来的字段 • }, • "sort":{ • "price":{//需要排序字段 • "order":"asc"//desc 排序方式 • } • } } { • "query":{ • "bool":{//条件参数 • "must":[//多个条件同时成立 should满足一个条件即成立 • { • "match":{ • "条件key":"条件value" • } • }, • { • "match":{ • "条件key":"条件value" • } • } • ], • "filter":{//过滤 • "range":{//范围 • "price":{//条件 • "gt":5000//大于 • } • } • } • } • }, • "highlight":{//高亮 • "pre_tags": "<font color='red'>", • "post_tags": "</font>", • "fields":{//字段 • "高亮字段" : {} • } • } } { • "aggs":{//聚合操作 • "price_group":{//名称,随意起名 (price_avg:平均值) • "terms":{//分组 (avg:平均值) • "分组字段" : "price" //分组字段 • } • } • }, • "size":0 //表示不需要原始数据 }
PUT添加映射关系 GET获取数据 { "properties":{//映射 "name":{ "type" : "text",//查询不需要完全匹配 "index" : true//是否能被索引,是否能被查询 }, "sex":{ "type" : "keyword",//查询需要完全匹配(不能被分词) "index" : true }, "tel":{ "type" : "keyword", "index" : false } } }
在Maven项目中的pom文件下引入依赖 <dependencies> <dependency> <groupId>org.elasticsearch</groupId> <artifactId>elasticsearch</artifactId> <version>7.8.0</version> </dependency> <!-- elasticsearch 的客户端 --> <dependency> <groupId>org.elasticsearch.client</groupId> <artifactId>elasticsearch-rest-high-level-client</artifactId> <version>7.8.0</version> </dependency> <!-- elasticsearch 依赖 2.x 的 log4j --> <dependency> <groupId>org.apache.logging.log4j</groupId> <artifactId>log4j-api</artifactId> <version>2.8.2</version> </dependency> <dependency> <groupId>org.apache.logging.log4j</groupId> <artifactId>log4j-core</artifactId> <version>2.8.2</version> </dependency> <dependency> <groupId>com.fasterxml.jackson.core</groupId> <artifactId>jackson-databind</artifactId> <version>2.9.9</version> </dependency> <!-- junit 单元测试 --> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.12</version> </dependency> </dependencies>
/* ES索引在java里简单操作: */ //创建ES客户端 RestHighLevelClient esClent = new RestHighLevelClient( RestClient.builder(new HttpHost("localhost",9200,"http")) ); //创建索引 CreateIndexResponse createIndexResponse = esClient.indices().create(new CreateIndexRequst("索引名称"),RequestOptions.DEFAULT); //响应状态 boolean acknowledged = createIndexResponse.isAcknowledged(); //查询索引 GetIndexResponse getIndexResponse = esClent.indices().get(new GetIndexRequest("索引名"),RequestOptions.DEFAULT); getIndexResponse.getAliases();//别名 getIndexResponse.getMappings();//配置 机构 getIndexResponse.getSettings();// //删除索引 DeleteIndexResponse deleteIndexResponse = esClent.indices().delete(new DeleteIndexRequest("索引名"),RequestOptions.DEFAULT); deleteIndexResponse.isAcknowledged();//响应状态 //关闭ES客户端 esClent.close();
/* ES数据在java里简单操作: */ //创建ES客户端 RestHighLevelClient esClient = new RestHighLevelClient( RestClient.builder(new HttpHost("localhost",9200,"http")) ); //插入数据 Map map = new Map(); map.put("name","zhangsan"); map.put("sex","男"); map.put("tel","15234456234"); //向ES插入数据,必须将数据转换为JSON格式 IndexRequest indexRequest = new IndexRequest.index("索引名").id("id"); ObjectMapper mapper = new ObjectMapper(); String userJson = mapper.writeValueAsString(map); indexRequest.source(userJson,XContentType.JSON); IndexResponse indexResponse = esClient.index(indexRequest,RequestOptions.DEFAULT); indexResponse.getResult();//插入响应状态(CREATED:插入成功) //修改数据 UpdateRequest updateRequest = new UpdateRequest().index("索引名").id("id"); updateRequest.doc(XContentType.JSON,"sex","女"); UpdateResponse updateResponse = esClient.update(updateRequest,RequestOptions.DEFAULT); updateResponse.getResult();//修改响应状态(CREATED:修改成功) //查询数据 GetREquest getRequest = new GetRequest().index("索引名").id("id"); GetResponse getResponse = esClient.get(getRequest,RequestOptions.DEEFAULT); getResponse.getSouceAsString(); //删除数据 DeleteRequest deleteRequest = new DeleteRequest().index("索引名").id("id"); DeleteResponse deleteResponse = esClient.delete(deleteRequest,RequestOptions.DEFAULT); //关闭ES客户端 esClient.close();
/* ES数据在java里批量操作: */ //创建ES客户端 RestHighLevelClient esClient = new RestHighLevelClient( RestClient.builder(new HttpHost("localhost",9200,"http")) ); //批量插入数据 BulkRequest bulkRequest = new BulkRequest(); bulkRequest.add(new IndexRequest.index("索引名").id("1001").source(XContentType.JSON,"name","zhangsan")); bulkRequest.add(new IndexRequest.index("索引名").id("1002").source(XContentType.JSON,"name","lisi")); BulkResponse bulkResponse = esClient.bulk(bulkRequest,RequestOptions.DEFAULT); bulkResponse.getTook(); bulkResponse.getItems(); //批量删除数据 bulkRequest.add(new DeleteRequest.index("索引名").id("1001")); bulkRequest.add(new DeleteRequest.index("索引名").id("1002")); BulkResponse bulkResponse = esClient.bulk(bulkRequest,RequestOptions.DEFAULT); bulkResponse.getTook(); bulkResponse.getItems(); //关闭ES客户端 esClient.colse();
/* Java里操作ES数据的使用 */ //创建ES客户端 RestHighLevelClient esClient = new RestHighLevelClient( RestClient.builder(new HttpHost("localhost",9200,"http")) ); //查询索引中全部的数据 matchAllQuery SearchRequest searchRequest = new SearchRequest().indices("索引名"); searchRequest.source(new SearchSourecBuilder().query(QueryBuilders.matchAllQuery())); SearchResponse searchResponse = esClient.search(searchRequest,RequestOptions.DEFAULT); SearchHits hits = searchResponse.getHits(); hits.getTotalHits(); searchResponse.getTook(); //条件查询 termQuery SearchRequest searchRequest = new SearchRequest().indices("索引名"); searchRequest.source(new SearchSourceBuilder().query(QueryBuilders.termQuery("age",30))); SearchResponse searchResponse = esClient.search(searchRequest,RequestOptions.DEFAULT); SearchHits searchHits = searchResponse.getHits(); hits.getTotalHits(); searchResponse.getTook(); //分页 排序 过滤字段 查询 SearchRequest searchRequest = new SearchRequest().indices("索引名"); SearchSourceBuilder builder = new SearchSourceBuilder().query(QueryBuilder.matchAllQuery()); ---------------------------------------------------------------- // (当前页码-1)*每页显示条数 builder.from(0);//分页用 builder.size(2);//分页用 ---------------------------------------------------------------- builder.sort("排序字段",SortOrder.DESC);//排序用 ---------------------------------------------------------------- String[] excludes = {};//排除的内容 String[] includes = {"name"};//包含的内容 builder.fetchSource(includes,excludes);//过滤字段查询 ---------------------------------------------------------------- searchRequest.source(builder); SearchResponse searchResponse = esClient.search(searchRequest,RequestOptions.DEFAULT); SearchHits searchHits = searchResponse.getHits(); hits.getTotalHits(); searchResponse.getTook(); //组合查询 SearchRequest searchRequest = new SearchRequest().indices("索引名"); SearchSourceBuilder builder = new SearchSourceBuilder(); BoolQueryBuilder boolQueryBuilder = QueryBuilder.boolQuery(); boolQueryBuilder.must(QueryBuilder.matchQuery("age",30));//满足这个条件 boolQueryBuilder.mustNot(QueryBuilder.matchQuery("sex","男"));//不满足这个条件 --------------------------满足30或者满足40------------------------------------ boolQueryBuilder.should(QueryBuilder.matchQuery("age",30)); boolQueryBuilder.should(QueryBuilder.matchQuery("age",40)); searchRequest.source(builder.query(boolQueryBuilder)); ----------------------------------------------------------------------------- //范围查询 RangeQueryBuilder rangeQuery = QueryBuilders.rangeQuery("age"); rangerQuery.get(30);//>= rangerQuery.lte(40);//<= searchRequest.source(builder.query(rangerQuery)); ----------------------------------------------------------------------------- //模糊查询 searchRequest.source(builder.query( QueryBuilder.fuzzyQuery("name","wangwu").fuzziness(Fuzziness.ONE))); ----------------------------------------------------------------------------- //高亮查询 TermsQueryBuilder termQueryBuilder = QueryBuilder.termsQuery("name","wangwu"); HighlightBuilder highlightBuilder = new HighlightBuilder(); highlightBuilder.preTags("<font color='red' >");//添加前缀 highlightBuilder.postTags("</font>");//添加后缀 highlightBuilder.field("name");//高亮标签内容 builder.highter(highlightBuilder); builder.query(termQueryBuilder); searchRequest.source(builder); ----------------------------------------------------------------------------- //聚合查询 AggregationBuilder aggregationBuilder = AggregationBuilders.max("maxAge").field("age"); builder.aggregation(aggregationBuilder); searchRequest.source(builder); ---------------------------------------------------------------------------- //分组查询 AggregationBuilder aggregationBuilder = AggregationBuilders.terms("ageGroup").field("age"); builder.aggregation(aggregationBuilder); searchRequest.source(builder); --------------------------------------------------------------------------- SearchResponse searchResponse = esClient.search(searchRequest,RequestOptions.DEFAULT); SearchHits searchHits = searchResponse.getHits(); hits.getTotalHits(); searchResponse.getTook(); //关闭ES客户端 esClient.close();
单机:
集群:
一个集群就是由一个或者多个服务器节点组织在一起的,共通持有整个的数据,并一起提供索引和搜索功能。一个Elasticsearch集群有一个唯一的名字标识,这个名字默认就是“elasticsearch”。这个名字是重要的,因为一个节点只能通过指定某个集群的名字,来加入这个集群。
节点Node:
集群中包含很多服务器,一个节点就是其中的一个服务器。作为集群的一部分,它存储数据,参与集群的索引和搜索功能。(注:一个节点就是一个服务器不绝对)
#节点 1 的配置信息: #集群名称,节点之间要保持一致 cluster.name: my-elasticsearch #节点名称,集群内要唯一 node.name: node-1001 node.master: true node.data: true #ip 地址 network.host: localhost #http 端口 http.port: 1001 #tcp 监听端口 transport.tcp.port: 9301 #discovery.seed_hosts: ["localhost:9301", "localhost:9302","localhost:9303"] #discovery.zen.fd.ping_timeout: 1m #discovery.zen.fd.ping_retries: 5 #集群内的可以被选为主节点的节点列表 #cluster.initial_master_nodes: ["node-1", "node-2","node-3"] #跨域配置 #action.destructive_requires_name: true http.cors.enabled: true http.cors.allow-origin: "*"
集群状态查询:
http://ip地址:端口号/_cluster/health
Elasticsearch索引的精髓:一切设计都是为了提高搜素的性能。
5.x支持多种type 6.x只能有一种type 7.x不在支持自定义索引类型(默认类型为:_doc)
一个文档是一个可被索引的基础信息单元,也就是一条数据(以JSON格式表示)
相当于是数据表的字段,对文档数据根据不同属性进行的分类标识
是处理数据的方式和规则方面的一些限制。
分片很重要,主要有两方面的原因:
1、允许你水平分割/扩展你的内容容量。
2、允许你在分片之上进行分布式的、并行的操作,进而提高性能/吞吐量。
复制分片之所以重要,主要有两个原因:
1、在分片/节点失败的情况下,提供了高可用性。因为这个原因,注意到复制分片从不与原/主要(original/primary)分片置于同一节点是非常重要的。
2、扩展你的搜索量/吞吐量,因为搜素可以在所有的副本上并行进行。
将分片分配给某个节点的过程,包括分配主分片或者副本。
单节点情况下分片正常启用,副本不进行分配
<?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.3.6.RELEASE</version> <relativePath/> </parent> <groupId>com.atguigu.es</groupId> <artifactId>springdata-elasticsearch</artifactId> <version>1.0</version> <properties> <maven.compiler.source>8</maven.compiler.source> <maven.compiler.target>8</maven.compiler.target> </properties> <dependencies> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-elasticsearch</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-devtools</artifactId> <scope>runtime</scope> <optional>true</optional> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-test</artifactId> <scope>test</scope> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-test</artifactId> </dependency> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> </dependency> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-test</artifactId> </dependency> </dependencies> </project>
# es 服务地址 elasticsearch.host=127.0.0.1 # es 服务端口 elasticsearch.port=9200 # 配置日志级别,开启 debug 日志 logging.level.com.atguigu.es=debug
Elasticsearch 的基础是 Lucene,所有的索引和文档数据是存储在本地的磁盘中,具体的路径可在 ES 的配置文件../config/elasticsearch.yml 中配置,如下: # Path to directory where to store the data (separate multiple locations by comma): #path.data: /path/to/data # Path to log files: #path.logs: /path/to/logs 磁盘在现代服务器上通常都是瓶颈。Elasticsearch 重度使用磁盘,你的磁盘能处理的吞吐量 越大,你的节点就越稳定。这里有一些优化磁盘 I/O 的技巧: 使用 SSD。就像其他地方提过的, 他们比机械磁盘优秀多了。 使用 RAID 0。条带化 RAID 会提高磁盘 I/O,代价显然就是当一块硬盘故障时整个就故障了。不要 使用镜像或者奇偶校验 RAID 因为副本已经提供了这个功能。 另外,使用多块硬盘,并允许 Elasticsearch 通过多个 path.data 目录配置把数据条带化分配到它们上 面。 不要使用远程挂载的存储,比如 NFS 或者 SMB/CIFS。这个引入的延迟对性能来说完全是背道而驰 的。
分片和副本的设计为 ES 提供了支持分布式和故障转移的特性,但并不意味着分片和副本是可以无限分配的。而且索引的分片完成分配后由于索引的路由机制,我们是不能重新修改分片数的。 可能有人会说,我不知道这个索引将来会变得多大,并且过后我也不能更改索引的大小,所以为了保险起见,还是给它设为 1000 个分片吧。但是需要知道的是,一个分片并不是没有代价的。需要了解: 一个分片的底层即为一个 Lucene 索引,会消耗一定文件句柄、内存、以及 CPU 运转。 每一个搜索请求都需要命中索引中的每一个分片,如果每一个分片都处于不同的节点还好, 但如果多个分片都需要在同一个节点上竞争使用相同的资源就有些糟糕了。 用于计算相关度的词项统计信息是基于分片的。如果有许多分片,每一个都只有很少的数据会导致很低的相关度。 一个业务索引具体需要分配多少分片可能需要架构师和技术人员对业务的增长有个预先的判断,横向扩展应当分阶段进行。为下一阶段准备好足够的资源。 只有当你进入到下一个阶段,你才有时间思考需要作出哪些改变来达到这个阶段。一般来说,我们遵循一些原则: 控制每个分片占用的硬盘容量不超过 ES 的最大 JVM 的堆空间设置(一般设置不超过 32G,参考下文的 JVM 设置原则),因此,如果索引的总容量在 500G 左右,那分片大小在 16 个左右即可;当然,最好同时考虑原则 2。 考虑一下 node 数量,一般一个节点有时候就是一台物理机,如果分片数过多,大大超过了节点数,很可能会导致一个节点上存在多个分片,一旦该节点故障,即使保持了 1 个以上的副本,同样有可能会导致数据丢失,集群无法恢复。所以, 一般都设置分片数不超过节点数的 3 倍。 主分片,副本和节点最大数之间数量,我们分配的时候可以参考以下关系:节点数<=主分片数*(副本数+1)
对于节点瞬时中断的问题,默认情况,集群会等待一分钟来查看节点是否会重新加入,如果这个节点在此期间重新加入,重新加入的节点会保持其现有的分片数据,不会触发新的分片分配。这样就可以减少 ES 在自动再平衡可用分片时所带来的极大开销。 通过修改参数 delayed_timeout ,可以延长再均衡的时间,可以全局设置也可以在索引级别进行修改: PUT /_all/_settings { "settings": { "index.unassigned.node_left.delayed_timeout": "5m" } }
当我们查询文档的时候,Elasticsearch 如何知道一个文档应该存放到哪个分片中呢?它其实是通过下面这个公式来计算出来: shard = hash(routing) % number_of_primary_shards routing 默认值是文档的 id,也可以采用自定义值,比如用户 id。 不带 routing 查询 在查询的时候因为不知道要查询的数据具体在哪个分片上,所以整个过程分为 2 个步骤 分发:请求到达协调节点后,协调节点将查询请求分发到每个分片上。 聚合: 协调节点搜集到每个分片上查询结果,在将查询的结果进行排序,之后给用户返回结果。 带 routing 查询 查询的时候,可以直接根据 routing 信息定位到某个分配查询,不需要查询所有的分配,经过协调节点排序。 向上面自定义的用户查询,如果 routing 设置为 userid 的话,就可以直接查询出数据来,效率提升很多。
ES 的默认配置,是综合了数据可靠性、写入速度、搜索实时性等因素。实际使用时,我们需要根据公司要求,进行偏向性的优化。 针对于搜索性能要求不高,但是对写入要求较高的场景,我们需要尽可能的选择恰当写优化策略。综合来说,可以考虑以下几个方面来提升写索引的性能: 加大 Translog Flush ,目的是降低 Iops、Writeblock。 增加 Index Refresh 间隔,目的是减少 Segment Merge 的次数。 调整 Bulk 线程池和队列。 优化节点间的任务分布。 优化 Lucene 层的索引建立,目的是降低 CPU 及 IO。
ES 提供了 Bulk API 支持批量操作,当我们有大量的写任务时,可以使用 Bulk 来进 行批量写入。 通用的策略如下:Bulk 默认设置批量提交的数据量不能超过 100M。数据条数一般是 根据文档的大小和服务器性能而定的,但是单次批处理的数据大小应从 5MB~15MB 逐渐 增加,当性能没有提升时,把这个数据量作为最大值。
ES 是一种密集使用磁盘的应用,在段合并的时候会频繁操作磁盘,所以对磁盘要求较高,当磁盘速度提升之后,集群的整体性能会大幅度提高。
Lucene 以段的形式存储数据。当有新的数据写入索引时,Lucene 就会自动创建一个新的段。 随着数据量的变化,段的数量会越来越多,消耗的多文件句柄数及 CPU 就越多,查询效率就会下降。 由于 Lucene 段合并的计算量庞大,会消耗大量的 I/O,所以 ES 默认采用较保守的策 略,让后台定期进行段合并
Lucene 在新增数据时,采用了延迟写入的策略,默认情况下索引的 refresh_interval 为1 秒。 Lucene 将待写入的数据先写到内存中,超过 1 秒(默认)时就会触发一次 Refresh, 然后 Refresh 会把内存中的的数据刷新到操作系统的文件缓存系统中。 如果我们对搜索的实效性要求不高,可以将 Refresh 周期延长,例如 30 秒。 这样还可以有效地减少段刷新次数,但这同时意味着需要消耗更多的 Heap 内存。
Flush 的主要目的是把文件缓存系统中的段持久化到硬盘,当 Translog 的数据量达到512MB 或者 30 分钟时,会触发一次 Flush。 index.translog.flush_threshold_size 参数的默认值是 512MB,我们进行修改。增加参数值意味着文件缓存系统中可能需要存储更多的数据,所以我们需要为操作系统 的文件缓存系统留下足够的空间。
ES 为了保证集群的可用性,提供了 Replicas(副本)支持,然而每个副本也会执行分 析、索引及可能的合并过程,所以 Replicas 的数量会严重影响写索引的效率。 当写索引时,需要把写入的数据都同步到副本节点,副本节点越多,写索引的效率就越 慢。 如 果 我 们 需 要 大 批 量 进 行 写 入 操 作 , 可 以 先 禁 止 Replica 复 制 , 设 置 index.number_of_replicas: 0 关闭副本。在写入完成后,Replica 修改回正常的状态。
ES 默认安装后设置的内存是 1GB,对于任何一个现实业务来说,这个设置都太小了。 如果是通过解压安装的 ES,则在 ES 安装文件中包含一个 jvm.option 文件,添加如下命令来设置 ES 的堆大小,Xms 表示堆的初始大小,Xmx 表示可分配的最大内存,都是 1GB。 确保 Xmx 和 Xms 的大小是相同的,其目的是为了能够在 Java 垃圾回收机制清理完堆区后不需要重新分隔计算堆区的大小而浪费资源,可以减轻伸缩堆大小带来的压力。 假设你有一个 64G 内存的机器,按照正常思维思考,你可能会认为把 64G 内存都给ES 比较好,但现实是这样吗, 越大越好?虽然内存对 ES 来说是非常重要的,但是答案是否定的! 因为 ES 堆内存的分配需要满足以下两个原则: 不要超过物理内存的 50%:Lucene 的设计目的是把底层 OS 里的数据缓存到内存中。 Lucene 的段是分别存储到单个文件中的,这些文件都是不会变化的,所以很利于缓存,同时操作系 统也会把这些段文件缓存起来,以便更快的访问。 如果我们设置的堆内存过大,Lucene 可用的内存将会减少,就会严重影响降低 Lucene 的全文本查询性能。 堆内存的大小最好不要超过 32GB:在 Java 中,所有对象都分配在堆上,然后有一个 Klass Pointer 指 针指向它的类元数据。 这个指针在 64 位的操作系统上为 64 位,64 位的操作系统可以使用更多的内存(2^64)。在 32 位的系统上为 32 位,32 位的操作系统的最大寻址空间为 4GB(2^32)。 但是 64 位的指针意味着更大的浪费,因为你的指针本身大了。浪费内存不算,更糟糕的是,更大的 指针在主内存和缓存器(例如 LLC, L1 等)之间移动数据的时候,会占用更多的带宽。 最终我们都会采用 31 G 设置 -Xms 31g -Xmx 31g 假设你有个机器有 128 GB 的内存,你可以创建两个节点,每个节点内存分配不超过 32 GB。 也就是说 不超过 64 GB 内存给 ES 的堆内存,剩下的超过 64 GB 的内存给 Lucene
参数名 | 参数值 | 说明 |
---|---|---|
cluster.name | elasticsearch | 配置 ES 的集群名称,默认值是 ES,建议改成与所存数据相关的名称,ES 会自动发现在同一网段下的 集群名称相同的节点 |
node.name | node-1 | 集群中的节点名,在同一个集群中不能重复。节点的名称一旦设置,就不能再改变了。当然,也可以设 置 成 服 务 器 的 主 机 名 称 , 例 如node.name:${HOSTNAME}。 |
node.master | true | 指定该节点是否有资格被选举成为 Master 节点,默认是 True,如果被设置为 True,则只是有资格成为Master 节点,具体能否成为 Master 节点,需要通过选举产生。 |
node.data | true | 指定该节点是否存储索引数据,默认为 True。数据的增、删、改、查都是在 Data 节点完成的。 |
index.number_of_shards | 1 | 设置都索引分片个数,默认是 1 片。也可以在创建索引时设置该值,具体设置为多大都值要根据数据量的大小来定。如果数据量不大,则设置成 1 时效率最高 |
index.number_of_replicas | 1 | 设置默认的索引副本个数,默认为 1 个。副本数越多,集群的可用性越好,但是写索引时需要同步的数据越多。 |
transport.tcp.compress | true | 设置在节点间传输数据时是否压缩,默认为 False,不压缩 |
discovery.zen.minimum_master_nodes | 1 | 设置在选举 Master 节点时需要参与的最少的候选主节点数,默认为 1。如果使用默认值,则当网络不稳定时有可能会出现脑裂。 合理的数值为 (master_eligible_nodes/2)+1 ,其中master_eligible_nodes 表示集群中的候选主节点数 |
discovery.zen.ping.timeout | 3s | 设置在集群中自动发现其他节点时 Ping 连接的超时时间,默认为 3 秒。 在较差的网络环境下需要设置得大一点,防止因误判该节点的存活状态而导致分片的转移 |
系统中的数据,随着业务的发展,时间的推移,将会非常多,而业务中往往采用模糊查询进行数据的搜索,而模糊查询会导致查询引擎放弃索引,导致系统查询数据时都是全表扫描,在百万级别的数据库中,查询效率是非常低下的,而我们使用 ES 做一个全文索引,将经常查询的系统功能的某些字段,比如说电商系统的商品表中商品名,描述、价格还有 id 这些字段我们放入 ES 索引库里,可以提高查询速度。
Elasticsearch 的选主是 ZenDiscovery 模块负责的,主要包含 Ping(节点之间通过这个 RPC 来发现彼此)和 Unicast(单播模块包含一个主机列表以控制哪些节点需要 ping 通)这两部分 对所有可以成为 master 的节点(node.master: true)根据 nodeId 字典排序,每次选举每个节点都把自己所知道节点排一次序,然后选出第一个(第 0 位)节点,暂且认为它是 master 节点。 如果对某个节点的投票数达到一定的值(可以成为 master 节点数 n/2+1)并且该节点自己也选举自己,那这个节点就是 master。否则重新选举一直到满足上述条件。 master 节点的职责主要包括集群、节点和索引的管理,不负责文档级别的管理;data 节点可以关闭 http功能。
“脑裂”问题可能的成因: 网络问题:集群间的网络延迟导致一些节点访问不到 master,认为 master 挂掉了从而选举出新的master,并对 master 上的分片和副本标红,分配新的主分片 节点负载:主节点的角色既为 master 又为 data,访问量较大时可能会导致 ES 停止响应造成大面积延迟,此时其他节点得不到主节点的响应认为主节点挂掉了,会重新选取主节点。 内存回收:data 节点上的 ES 进程占用的内存较大,引发 JVM 的大规模内存回收,造成 ES 进程失去 响应。 脑裂问题解决方案: 减少误判:discovery.zen.ping_timeout 节点状态的响应时间,默认为 3s,可以适当调大,如果 master在该响应时间的范围内没有做出响应应答,判断该节点已经挂掉了。调大参数(如 6s,discovery.zen.ping_timeout:6),可适当减少误判。 选举触发: discovery.zen.minimum_master_nodes:1 该参数是用于控制选举行为发生的最小集群主节点数量。当备选主节点的个数大于等于该参数的值,且备选主节点中有该参数个节点认为主节点挂了,进行选举。官方建议为(n/2)+1,n 为主节点个数(即有资格成为主节点的节点个数) 角色分离:即 master 节点与 data 节点分离,限制角色 主节点配置为:node.master: true node.data: false 从节点配置为:node.master: false node.data: true
协调节点默认使用文档 ID 参与计算(也支持通过 routing),以便为路由提供合适的分片:shard = hash(document_id) % (num_of_primary_shards) 当分片所在的节点接收到来自协调节点的请求后,会将请求写入到 Memory Buffer,然后定时(默认 是每隔 1 秒)写入到 Filesystem Cache,这个从 Memory Buffer 到 Filesystem Cache 的过程就叫做 refresh; 当然在某些情况下,存在 Momery Buffer 和 Filesystem Cache 的数据可能会丢失,ES 是通过 translog的机制来保证数据的可靠性的。其实现机制是接收到请求后,同时也会写入到 translog 中,当 Filesystem cache 中的数据写入到磁盘中时,才会清除掉,这个过程叫做 flush; 在 flush 过程中,内存中的缓冲将被清除,内容被写入一个新段,段的 fsync 将创建一个新的提交点,并将内容刷新到磁盘,旧的 translog 将被删除并开始一个新的 translog。 flush 触发的时机是定时触发(默认 30 分钟)或者 translog 变得太大(默认为 512M)时;
删除和更新也都是写操作,但是 Elasticsearch 中的文档是不可变的,因此不能被删除或者改动以展示其变更; 磁盘上的每个段都有一个相应的.del 文件。当删除请求发送后,文档并没有真的被删除,而是在.del文件中被标记为删除。该文档依然能匹配查询,但是会在结果中被过滤掉。当段合并时,在.del 文件中被标记为删除的文档将不会被写入新段。 在新的文档被创建时,Elasticsearch 会为该文档指定一个版本号,当执行更新时,旧版本的文档在.del文件中被标记为删除,新版本的文档被索引到一个新段。旧版本的文档依然能匹配查询,但是会在结果中被过滤掉。
搜索被执行成一个两阶段过程,我们称之为 Query Then Fetch; 在初始查询阶段时,查询会广播到索引中每一个分片拷贝(主分片或者副本分片)。 每个分片在本地执行搜索并构建一个匹配文档的大小为 from + size 的优先队列。PS:在搜索的时候是会查询Filesystem Cache 的,但是有部分数据还在 Memory Buffer,所以搜索是近实时的。 每个分片返回各自优先队列中 所有文档的 ID 和排序值 给协调节点,它合并这些值到自己的优先队列中来产生一个全局排序后的结果列表。 接下来就是取回阶段,协调节点辨别出哪些文档需要被取回并向相关的分片提交多个 GET 请求。每个分片加载并丰富文档,如果有需要的话,接着返回文档给协调节点。一旦所有的文档都被取回了,协调节点返回结果给客户端。 Query Then Fetch 的搜索类型在文档相关性打分的时候参考的是本分片的数据,这样在文档数量较少的时候可能不够准确,DFS Query Then Fetch 增加了一个预查询的处理,询问 Term 和 Document frequency,这个评分更准确,但是性能会变差。
64 GB 内存的机器是非常理想的,但是 32 GB 和 16 GB 机器也是很常见的。少于 8 GB 会适得其反。 如果你要在更快的 CPUs 和更多的核心之间选择,选择更多的核心更好。多个内核提供的额外并发远胜过稍微快一点点的时钟频率。 如果你负担得起 SSD,它将远远超出任何旋转介质。 基于 SSD 的节点,查询和索引性能都有提升。如果你负担得起,SSD 是一个好的选择。 即使数据中心们近在咫尺,也要避免集群跨越多个数据中心。绝对要避免集群跨越大的地理距离。 请确保运行你应用程序的 JVM 和服务器的 JVM 是完全一样的。 在 Elasticsearch 的几个地方,使用 Java 的本地序列化。 通过设置 gateway.recover_after_nodes、gateway.expected_nodesgateway.recover_after_time 可以在集群重启的时候避免过多的分片交换,这可能会让数据恢复从数个小时缩短为几秒钟。 Elasticsearch 默认被配置为使用单播发现,以防止节点无意中加入集群。只有在同一台机器上运行的节点才会自动组成集群。最好使用单播代替组播。 不要随意修改垃圾回收器(CMS)和各个线程池的大小。 把你的内存的(少于)一半给 Lucene(但不要超过 32 GB!),通过 ES_HEAP_SIZE 环境变量设置。 内存交换到磁盘对服务器性能来说是致命的。如果内存交换到磁盘上,一个 100 微秒的操作可能变成 10 毫秒。 再想想那么多 10 微秒的操作时延累加起来。 不难看出 swapping 对于性能是多么可怕。 Lucene 使用了大量的文件。同时,Elasticsearch 在节点和 HTTP 客户端之间进行通信也使用了大量的套接字。 所有这一切都需要足够的文件描述符。你应该增加你的文件描述符,设置一个很大的值,如 64,000。
使用批量请求并调整其大小:每次批量数据 5–15 MB 大是个不错的起始点。 存储:使用 SSD 段和合并:Elasticsearch 默认值是 20 MB/s,对机械磁盘应该是个不错的设置。如果你用的是 SSD,可以考虑提高到 100–200 MB/s。如果你在做批量导入,完全不在意搜索,你可以彻底关掉合并限流。另外还可以增加 index.translog.flush_threshold_size 设置,从默认的 512 MB 到更大一些的值,比如 1 GB,这可以在一次清空触发的时候在事务日志里积累出更大的段。 如果你的搜索结果不需要近实时的准确度,考虑把每个索引的 index.refresh_interval 改到 30s。 如果你在做大批量导入,考虑通过设置 index.number_of_replicas: 0 关闭副本。
倒排词典的索引需要常驻内存,无法 GC,需要监控 data node 上 segment memory 增长趋势。 各类缓存,field cache, filter cache, indexing cache, bulk queue 等等,要设置合理的大小,并且要应该根据最坏的情况来看 heap 是否够用,也就是各类缓存全部占满的时候,还有 heap 空间可以分配给其他任务吗?避免采用 clear cache 等“自欺欺人”的方式来释放内存。 避免返回大量结果集的搜索与聚合。确实需要大量拉取数据的场景,可以采用 scan & scroll api 来实现。 cluster stats 驻留内存并无法水平扩展,超大规模集群可以考虑分拆成多个集群通过 tribe node 连接。 想知道 heap 够不够,必须结合实际应用场景,并对集群的 heap 使用情况做持续的监控。
Elasticsearch 提供的首个近似聚合是 cardinality 度量。它提供一个字段的基数,即该字段的 distinct或者 unique 值的数目。它是基于 HLL 算法的。HLL 会先对我们的输入作哈希运算,然后根据哈希运算的结果中的 bits 做概率估算从而得到基数。其特点是:可配置的精度,用来控制内存的使用(更精确 = 更多内存);小的数据集精度是非常高的;我们可以通过配置参数,来设置去重需要的固定内存使用量。无论数千还是数十亿的唯一值,内存使用量只与你配置的精确度相关
可以通过版本号使用乐观并发控制,以确保新版本不会被旧版本覆盖,由应用层来处理具体的冲突; 另外对于写操作,一致性级别支持 quorum/one/all,默认为 quorum,即只有当大多数分片可用时才允许写操作。但即使大多数可用,也可能存在因为网络等原因导致写入副本失败,这样该副本被认为故障,分片将会在一个不同的节点上重建。 对于读操作,可以设置 replication 为 sync(默认),这使得操作在主分片和副本分片都完成后才会返回;如果设置 replication 为 async 时,也可以通过设置搜索请求参数_preference 为 primary 来查询主分片,确保文档是最新版本.
elasticsearch-head 插件 通过 Kibana 监控 Elasticsearch。你可以实时查看你的集群健康状态和性能,也可以分析过去的集群、索引和节点指标
集群是一个或多个节点(服务器)的集合,它们共同保存您的整个数据,并提供跨所有节点的联合索引和搜索功能。群集由唯一名称标识,默认情况下为“elasticsearch”。此名称很重要,因为如果节点设置为按名称加入群集,则该节点只能是群集的一部分。 节点是属于集群一部分的单个服务器。它存储数据并参与群集索引和搜索功能。 索引就像关系数据库中的“数据库”。它有一个定义多种类型的映射。索引是逻辑名称空间,映射到一个或多个主分片,并且可以有零个或多个副本分片。 MySQL =>数据库 Elasticsearch =>索引 文档类似于关系数据库中的一行。不同之处在于索引中的每个文档可以具有不同的结构(字段),但是对于通用字段应该具有相同的数据类型。 MySQL => Databases => Tables => Columns / Rows Elasticsearch => Indices => Types =>具有属性的文档 类型是索引的逻辑类别/分区,其语义完全取决于用户。
倒排索引是搜索引擎的核心。搜索引擎的主要目标是在查找发生搜索条件的文档时提供快速搜索。ES中的倒排索引其实就是 lucene 的倒排索引,区别于传统的正向索引,倒排索引会再存储数据时将关键词和数据进行关联,保存到倒排表中,然后查询时,将查询内容进行分词后在倒排表中进行查询,最后匹配数据即可。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。