ElasticSearch - 基础入门（一）

最新推荐文章于 2023-03-30 21:48:26 发布

观沧听白

最新推荐文章于 2023-03-30 21:48:26 发布

阅读量128

点赞数

分类专栏： JAVA 文章标签： elasticsearch

本文链接：https://blog.csdn.net/hantingbai/article/details/108710364

版权

JAVA 专栏收录该内容

4 篇文章 0 订阅

订阅专栏

目录：基础入门

1 - 为什么要使用ElasticSearch
- 1.1 - ElasticSearch对比Solr
2 - ElasticSearch相关概念
3 - ElasticSearch接口语法
4 - IK分词器
- 4.1 - 什么是IK分词器
- 4.2 - 为什么使用IK分词器

1 - 为什么要使用ElasticSearch

ElasticSearch 是一个开源的搜索引擎，建立在一个全文搜索引擎库 Apache Lucene基础上。

Lucene 可以说是当前最先进、高性能、全功能的搜索引擎库。

但是Lucene仅仅是一个库，为了充分发挥它的功能呢，需要使用Java将Lucene直接集成到应用程序当中。

而Elasticsearch 虽然也是采用Java编写的，但是它的目的是让全文检索变得更加简单，内部使用Lucene做索引与搜索，隐藏Lucene的复杂性，提供一套简单的RESTful API。

但是，ElasticSearch不仅仅是Lucene，也不仅仅是一个全文搜索引擎。

它可以作为一个分布式的实时文档存储，每一个字段都可以被索引或者搜索。

或者作为一个分布式实时分析搜索引擎，它能够胜任上百个服务节点的扩展，并支持PB级别的结构化或者非结构化数据。

ElasticSearch将所有的功能打包成一个单独的服务，这样就可以通过程序与它提供的简单的RESTful API 进行通信，可以使用自己喜欢的编程语言充当Web客户端，甚至可以采用命令行。

就ElasticSearch而言，起步很简单，开箱即用，仅需要最少的理解，就可以很快具有生产力。

随着能力的增强，可以利用ElasticSearch更多的高级特性，它的整个引擎是可配置并极其灵活的。

1.1 - ElasticSearch对比Solr

Solr 利用 Zookeeper 进行分布式管理，而 Elasticsearch 自身带有分布式协调管理功能;
Solr 支持更多格式的数据，而 Elasticsearch 仅支持json文件格式；
Solr 官方提供的功能更多，而 Elasticsearch 本身更注重于核心功能，高级功能多有第三方插件提供；
Solr 在传统的搜索应用中表现好于 Elasticsearch，但在处理实时搜索应用时效率明显低于 Elasticsearch

2 - ElasticSearch相关概念

2.1 - 概述

ElasticSearch是面向文档的，这意味着它可以存储整个对象或者文档。然而他不仅仅是存储，还会索引每个文档的内容，使之可以被搜索。

在ElasticSearch当中，可以对文档进行索引、搜索、排序、过滤。

2.2 - 核心概念

2.2.1 - 类型 index

一个索引就是一个拥有几分相似特征的文档的集合。

一个索引用一个名字来标识（必须全部是小写字母），并且当要对对应这个索引的文档进行索引、搜索、更新和删除的时候，都要使用到这个名字。

再一个集群当中，可以定义任意多的索引。

2.2.2 - 类型 type

在一个索引当中，可以定义一种或者多种类型。

一个类型是你的索引的一个逻辑上的分类/分区，其语义完全由你来定。

通常，会把具有一组共同字段的文档定义一个类型。假设你运营了一个博客凭条，并且将你所有的数据存储到了一个索引当中。那么在这个索引中，你可以为用户数据定义一个类型，为博客数据定义一个类型，当然，也可以为评论数据定义另一个类型。

2.2.3 - 字段 Field

相当于是数据库的字段，对文档数据根据不同属性进行的分类标识。

2.2.4 - 映射 mapping

mapping是处理数据的方式和规则方面做一些限制。比如某个字段的数据类型、默认值、分析器、是否被索引等等，这些都是映射里面可以设置的，其他就是处理es里面数据的一些使用规则设置这也被叫做映射。

按照最优规则处理数据对于性能提高很大，因此才需要建立映射，并且需要思考如何建立映射才能对性能更好。

2.2.5 - 文档 document

一个文档是一个可被索引的基础单元。文档以Json格式来表示，而Json是一个到处存在的互联网数据交互格式。

在一个index/type里面，可以存储任意多的文档。尽管一个文档，物理上存在于一个索引当中，但是文档必须被索引/赋予一个索引的type。

2.2.6 - 接近实时 NRT

ElasticSearch是一个接近实时的搜索平台。这意味着，从索引一个文档直到这个文档能够被搜索到有一个轻微的延迟（通常是一秒内）。

2.2.7 - 集群 cluster

一个集群就是由一个或者多个节点组织在一起，它们共同持有整个的数据，并一起提供索引和搜索功能。一个集群由一个唯一的名字标识，这个名字默认就是‘elasticsearch’。这个名字是很重要的，因为一个节点只能通过制定某个集群的名字，来加入这个集群。

2.2.8 - 节点 node

一个节点是集群中的一个服务器，作为集群的一部分，它存储数据，参与集群的索引和搜索功能。和集群类似，一个节点也是由一个名字来标识的，默认情况下，这个名字是一个随机漫威漫画角色名字。这个名字会在启动的时候赋予节点。这个名字对于管理工作来说很重要，因为在这个管理的过程中，需要确定网络中那些服务器对应与Elaticsearch集群中的哪些节点。

一个节点可以通过配置集群名称来加入一个指定的集群。这意味着，如果你的网络中启动了若干个节点，并假设它们都能够互相发现彼此，它们会自动形成并加入一个叫做‘elasticsearch’的集群中。

在一个集群里，只要你想，就可以有任意多的节点。而且，如果在当前网络中没有运行任何节点，这个时候启动一个节点，会默认创建并加入一个叫做‘elasticsearch’的集群。

2.2.9 - 分片和复制 shards&replicas

一个索引可以存储超出单个节点硬件限制的大量数据。

比如，一个具有十亿文档的索引占据1TB的磁盘空间，而任一节点都没有这样大的磁盘空间，或者单个节点处理搜索请求，响应太慢。

为了解决这个问题，ElasticSearch提供了将索引划分成多份的能力，这些份就叫做分片。

当创建一个索引时，可以指定想要的分片数量。每个分片本身也是一个功能完善并且独立的‘索引’，这个‘索引’可以被放置到集群中的任何节点上。

分片允许水平分割或者扩展内存容量，也允许在分片上进行分布式的、并行的操作，进而提高性能/吞吐量。

至于一个分片怎么分布，它的文档怎么聚合回搜索请求，是完全由ElasticSearch管理的。对于用户来说，这些都是透明的。

在一个网络的环境里，失败随时可能发生，在某个分片/节点不知道为什么就处于离线状态，或者由于某些原因消失了。这种情况下，有一个故障转移机制是非常有用的。

为了解决上述问题，ElasticSearch允许创建分片的一份或者多份拷贝，这些拷贝叫做复制分片，或者直接叫做复制。

复制之所以重要，有两个主要原因：在分片/节点失败的情况下，提供了高可用性。因为这个原因，注意到复制分片从不与原/主要分片置于同一节点上是非常重要的。

而且还扩展了搜索量/吞吐量，因为搜索可以在所有的复制上并行运行。

总之，每个索引都可以被分成多个分片。一个索引也可以被复制多次。一旦复制了，每个索引就有了主分片（作为复制源的分片）和复制分片（主分片的拷贝）之别。

分片和复制的数量可以在索引创建的时候指定。在索引创建之后，可以在任何时候动态的修改复制的数量，但是不能修改分片的数量。

默认情况下，ElasticSearch中的每个索引被分成五个主分片和一个复制分片。这意味着，如果集群中有两个节点，那么索引就会有五个主分片和另外五个复制分片，每个索引总共有十个分片。

3 - ElasticSearch接口语法

curl ‐X<VERB> '<PROTOCOL>://<HOST>:<PORT>/<PATH>?<QUERY_STRING>' ‐d '<BODY>'

参数	解释
VERB	适当的 HTTP 方法或谓词 : GET 、 POST 、 PUT 、 HEAD 或者 DELETE 。
PROTOCOL	http 或者 https （如果你在 Elasticsearch 前面有一个 https 代理）。
HOST	Elasticsearch 集群中任意节点的主机名，或者用 localhost 代表本地机器上的节点。
PORT	运行 Elasticsearch HTTP 服务的端口号，默认是 9200。
PATH	API 的终端路径（例如 _count 将返回集群中文档数量）。Path 可能包含多个组件，例如： _cluster/stats 和 _nodes/stats/jvm
QUERY_STRING	任意可选的查询字符串参数 (例如 ?pretty 将格式化地输出 JSON 返回值，使其更容易阅读)
BODY	一个 JSON 格式的请求体 (如果请求需要的话)

4 - IK分词器

4.1 - 什么是IK分词器

KAnalyzer是一个开源的，基于java语言开发的轻量级的中文分词工具包。从2006年12月推出1.0版开始，IKAnalyzer已经推出了3个大版本。

最初，它是以开源项目Lucene为应用主体的，结合词典分词和文法分析算法的中文分词组件。新版本的IKAnalyzer3.0则发展为面向Java的公用分词组件，独立于Lucene项目，同时提供了对Lucene的默认优化实现。

IK分词器3.0的特性如下：

采用了特有的“正向迭代最细粒度切分算法“，具有60万字/秒的高速处理能力。
采用了多子处理器分析模式，支持：英文字母（IP地址、Email、URL）、数字（日期，常用中文数量词，罗马数字，科学计数法），中文词汇（姓名、地名处理）等分词处理。
对中英联合支持不是很好,在这方面的处理比较麻烦.需再做一次查询,同时是支持个人词条的优化的词典存储，更小的内存占用。
支持用户词典扩展定义。
针对Lucene全文检索优化的查询分析器IKQueryParser；采用歧义分析算法优化查询关键字的搜索排列组合，能极大的提高Lucene检索的命中率。