elasticsearch collapse原理？

一、elasticsearch collapse原理？

一、Elasticsearch概述

Elasticsearch 是一个基于Lucene的分布式搜索引擎。

搜索引擎三大过程：爬取内容、进行分词、建立反向索引。

二、Elasticsearch如何快速索引：倒排索引或反向索引

将key映射value，改为value映射key。

倒排索引：即把文件ID对应到关键词的映射转换为关键词到文件ID的映射，每个关键词都对应着一系列的文件，这些文件中都出现这个关键词。

三、总结

1.Elasticsearch 中的索引、类型和文档的概念比较重要，类似于 MySQL 中的数据库、表和行。

2.Elasticsearch 也是 Master-slave 架构，也实现了数据的分片和备份。

3.Elasticsearch 一个典型应用就是 ELK 日志分析系统

二、elasticsearch怎么使用？

用2个Map作为传参，一个是must，一个是should。代码如下：

//创建查询

SearchRequestBuilder srb = client.prepareSearch(INDEX);

srb.setTypes(ASK_TYPE);

srb.setSearchType(SearchType.DFS_QUERY_THEN_FETCH);

//分页

srb.setFrom((pageNo - 1) * pageSize).setSize(pageSize);

//按时间倒序

SortBuilder sortBuilder = SortBuilders.fieldSort("date").order(SortOrder.DESC);

srb.addAggregation(aggregation);//聚合

srb.addSort(sortBuilder);//排序

/**********************主要看这里 start*********************************/

if(null != mustMap && mustMap.size() > 0){

//创建一个查询

BoolQueryBuilder queryBuilder = QueryBuilders.boolQuery();

//这里查询的条件用map传递

for(String key : mustMap.keySet()){

queryBuilder.must(QueryBuilders.termQuery(key,mustMap.get(key)));

}

//这里查询的条件用map传递

for(String key : shouldMap.keySet()){

queryBuilder.should(QueryBuilders.termQuery(key,mustMap.get(key)));

}

//查询

srb.setQuery(queryBuilder);

}

/**********************主要看这里 end*********************************/

//请求

SearchResponse response = srb.get();

//更多看这里：http://www.sojson.com/tag_elasticsearch.html

三、elasticsearch开源吗？

必须是的。获取源码地址：

https://github.com/elastic/elasticsearch

四、elasticsearch 密码错误？

答，更新数据，确认密码是否正确，重试

五、elasticsearch管理规范？

shard是Elasticsearch数据存储的最小单位，index的存储容量为所有shard的存储容量之和。Elasticsearch集群的存储容量则为所有index存储容量之和。

一个shard就对应了一个lucene的library。对于一个shard，Elasticsearch增加了translog的功能，类似于HBase WAL，是数据写入过程中的中间数据，其余的数据都在lucene库中管理的。

所以Elasticsearch索引使用的存储内容主要取决于lucene中的数据存储。

六、elasticsearch存储结构？

基于lucene的存储结构

Lucene是一个功能强大的搜索库，但是基于Lucene进行开发比较复杂。ElasticSearch是基于lucene开发的搜索引擎，提供了更简单易用的API。

索引实际上是lucene中的概念，一个索引由多个索引段构成，大部分的场景是写一次，读多次。当满足某些条件时，多个索引段会合并成一个更大的索引段。索引段的减少有助于搜索效率的提高(可能是lucene内部原理决定的)，但是频繁的段合并会影响性能。

Elasticsearch中的每次刷新都会新创建一个段，新创建的段里面的数据在下一次刷新之前是不会被搜索到的。ES的段合并是在后台进行的。

七、elasticsearch centos

在今天的博客文章中，我们将重点探讨如何在CentOS操作系统上安装和配置Elasticsearch。

什么是Elasticsearch？

Elasticsearch是一个常用的开源搜索引擎，它提供了一个分布式、RESTful的全文搜索引擎，具有实时分析功能。

在CentOS上安装Elasticsearch的步骤

下面是在CentOS上安装Elasticsearch的步骤：

1. 步骤一：首先，确保您的CentOS系统已经安装并配置了Java。您可以通过运行java -version命令来检查Java的版本。
2. 步骤二：接下来，您需要下载Elasticsearch的RPM安装包。您可以在Elasticsearch官方网站上找到适用于CentOS的安装包。
3. 步骤三：下载安装包后，使用以下命令来安装Elasticsearch：

配置Elasticsearch

一旦安装完成，接下来需要对Elasticsearch进行一些基本配置。

Elasticsearch的主要配置文件位于/etc/elasticsearch/elasticsearch.yml。您可以使用任何文本编辑器来编辑此文件，根据您的需求进行配置更改。

启动Elasticsearch服务

当您完成配置后，您可以使用以下命令来启动Elasticsearch服务：

您还可以使用chkconfig命令将Elasticsearch设置为开机启动。

验证Elasticsearch安装

要验证Elasticsearch是否已正确安装并运行，请执行以下命令：

如果一切正常，您应该能够看到有关Elasticsearch的信息。

总结

通过本文，您应该已经了解了如何在CentOS操作系统上安装和配置Elasticsearch。记得查看官方文档以获取更多关于Elasticsearch的配置和使用信息。

八、elasticsearch数据怎么删除？

其实限制一个node最高不超过3个shard也没有这必要，我们的做法是按照主机上SSD的数量来定shard的数量，因为这个时候每个shard实际上会落到一个硬盘上去。

至于数据存储的问题，首先要考虑业务，再确定shard和index的策略：

一般涉及到日志类的数据存储，应该按照日期来分index，这样查新的时候直接查最近写入的index就可以了，旧的index数据也可以定期删除或是转移到SATA盘里面去；

只用一个index也有好处，管理方便，但是需要提前考虑好数据的增长速度；

shard多了其实会更加浪费资源，但是一个shard太大了对恢复和迁移也是个问题，这种优化其实官方也没啥好的说法，总之一切看自己的实际情况，慢慢测试了。

九、elasticsearch哪国开发的？

美国开发的。

ElasticSearch是一个基于Lucene的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎，基于RESTful web接口。

Elasticsearch是用Java开发的，并作为Apache许可条款下的开放源码发布，是当前流行的企业级搜索引擎。设计用于云计算中，能够达到实时搜索，稳定，可靠，快速，安装使用方便。

官方客户端在Java、.NET（C#）、PHP、Python、Apache Groovy、Ruby和许多其他语言中都是可用的。根据DB-Engines的排名显示，Elasticsearch是最受欢迎的企业搜索引擎，其次是Apache Solr，也是基于Lucene。

十、elasticsearch的优缺点？

优点：

1.高并发。实测es单机分配10g内存单实例，写入能力1200qps，60g内存、12核CPU起3个实例预计可达到6000qps。

2.同机房单条数据写入平均3ms（比mysql慢，mg不清楚）3.容错能力比mg强。比如1主多从，主片挂了从片会自动顶上4.满足大数据下实时读写需求，无需分库（不存在库的概念）。5.易扩展。实例间做下配置即可扩展并发性和容积，自动分配的写入机制，无需操心传统db中多主同步的诟病6.支持较复杂的条件查询，group by、排序都不是问题7.具有一定的关系性，但不用担心大字段的问题缺点：1.不支持事务2.读写有一定延时（不知道其他大牛是否遇到这个问题），我是写入一分钟后再做读操作3.无权限管理也是最近开始用，说下我的应用场景，用来存储线上日志做实时分析（类似淘宝鹰眼，但是完全实时），存储结构化的日志及原文，也调研过很多db，mg也有考虑过，相比之下实现和运维成本mg都要高不少我的场景如下：1.高并发，设计日志并发80wqps（实际存储会用一些策略缩小规模，约万级别）2.单条数据体积大，允许最大20k3.要求支持条件查询4.实时性高，目前从日志存储开始到出分析结果3分钟，包含前面提到的读写延时（求解决方案）目前就想到这么多，欢迎交流