标签:构造 map 功能 max block 规则 列表 执行 自动
Elasticsearch是一个高度可扩展的、开源的、基于 Lucene 的全文搜索和分析引擎。它允许您快速,近实时地存储,搜索和分析大量数据,并支持多租户。
Elasticsearch也使用Java开发并使用 Lucene 作为其核心来实现所有索引和搜索的功能,但是它的目的是通过简单的 RESTful API 来隐藏 Lucene 的复杂性,从而让全文搜索变得简单。
不过,Elasticsearch 不仅仅是 Lucene 和全文搜索,我们还能这样去描述它:
而且,所有的这些功能被集成到一个服务里面,你的应用可以通过简单的RESTful API、各种语言的客户端甚至命令行与之交互。
在决定使用 Elasticsearch 的时候首先要考虑的是版本问题,Elasticsearch 目前有三个常用的稳定的主版本:2.x,5.x,6.x(排除 0.x 和 1.x)。
Elasticsearch 可以在这里查看所有历史版本,博主写这篇博文的时候最新的是 Elasticsearch 6.4.2。你可能会发现没有 3.x 和 4.x,ES 从 2.4.6 直接跳到了 5.0.0。这是为什么?
其实是为了ELK(ElasticSearch, logstash, kibana)技术栈的版本统一,免的给用户带来混乱。
我们知道 elasticsearch,kibana,logstash 都是 Elastic Stack 成员, 而且很多时候都是配合使用,那么为了协同开发,避免造成版本困惑,所以需要统一版本,至少保持在一个主版本号下。
在 Elasticsearch 是 2.x (2.x 的最后一版 2.4.6 的发布时间是 July 25, 2017) 的情况下,kibana 已经是 4.x(Kibana 4.6.5 的发布时间是 July 25, 2017),那么在 kibana 的下一主版本肯定是 5.x 了,所以 Elasticsearch 直接将自己的主版本发布为 5.0.0 了。统一之后,我们选版本就不会犹豫困惑了,我们选定 elasticsearch 的版本后再选择相同版本的 kibana 就行了,不用担忧版本不兼容的问题。
版本选择可以从以下几个方面考虑:
6.x 版本有点新,网上资料相对比较少(开发时间充足的可以研究)。
5.X 版本的数据可以直接迁移到 6.x; 但是 2.x 版本数据无法直接迁移到 6.x。
5.x 之后 Kibana 等工具的主版本号进行了统一。
6.3.0 以后内置支持 SQL 模块,这个 SQL 模块是属于 X-Pack 的一部分。
通过以上的版本号了解之后,综合考虑,我起始选择了 elasticsearch 6.4.0版本,其实主要是因为它新,kibana 也选择了 kibana 6.4.0。但是等本地开发完成准备部署的时候,运维通知切换到5.6.0,因为公司其他部门的是5.6.0,方便统一维护,还好 API 变化不大。
Elasticsearch5.0之后的版本至少需要Java 8。可通过如下命令检查Java版本,然后根据需要进行相应的安装/升级。
你可以从 elastic.co/download 下载你需要的版本的Elasticsearch,解压之后即可使用。
如果是集群形式的,可在 ...\elasticsearch-5.6.0\config\elasticsearch.yml
中配置一些你的集群信息:
elasticsearch 准备好之后,在安装目录中执行以下命令可以启动运行:
Linux
./bin/elasticsearch
Windows
D:\...\elasticsearch-6.4.0\bin\elasticsearch.bat
运行成功之后(启动日志里面会有.. started
标志),浏览器访问http://localhost:9200/?pretty
,你能看到类似以下返回信息(各版本稍微不同):
这说明你的 Elasticsearch 集群已经启动成功并且正常运行,接下来我们可以开始使用了。
由于 Elasticsearch 的交互方式是 Rest 形式的,这种不是很直观方便,我们先安装图视化界面,方便我们操作。可选择的目前主要有 elasticsearch-head 和 kibana。
elasticsearch-head 是一个用于浏览和与 elasticsearch 集群交互的Web前端。elasticsearch-head 是 elasticsearch 集群管理、数据可视化、增删查改、查询语句可视化工具。elasticsearch head 是托管的,可以在 github 下载或 fork。
有两种运行和安装elasticsearch-head的方法:
作为ElasticSearch的插件运行(这是首选方法)
注意:
插件的安装方法,5.0之前为 plugin -install …
,而在 5.0 以后为 elasticsearch-plugin -install …
。
作为独立的webapp运行
git clone git://github.com/mobz/elasticsearch-head.git
。成功后的界面如下,可以看到集群的状态信息:
由于 Head 安装起来比较麻烦( 需要安装 node.js ),网上资料也很多,所以我就不详细说了,更多信息可参考:elasticsearch-head
Kibana 和 elasticsearch 同属于 elastic 公司。 Kibana是一个开源分析和可视化平台,旨在与Elasticsearch协同工作。您使用Kibana搜索,查看和与存储在 Elasticsearch 索引中的数据进行交互。您可以轻松地执行高级数据分析,并在各种图表,表格和地图中可视化您的数据。
Kibana 使您可以轻松理解大量数据。其简单的基于浏览器的界面使您能够快速创建和共享动态仪表板,实时显示 Elasticsearch 查询的更改。
设置 Kibana 非常容易。您可以安装 Kibana 并在几分钟内开始探索您的 Elasticsearch 索引 - 无需代码,无需额外的基础架构。
同样可在 kibana 选择需要的对应版本(与 elasticsearch 版本对应),然后下载解压即可使用,具体步骤如下:
elasticsearch.url: "http://localhost:9200"
。如果运行成功,但是无法访问,可以关闭防火墙再试试。
一切准备就绪,我们正式操作之前,先来了解一些 ES 的核心基本概念,从一开始就理解这些概念将极大地帮助简化学习过程。
Elasticsearch是一个近乎实时(NRT)的搜索平台。这意味着从索引文档到可搜索文档的时间有一点延迟(通常是一秒)。通常有集群,节点,分片,副本等概念。
集群(cluster)是一组具有相同cluster.name
的节点集合,他们协同工作,共享数据并提供故障转移和扩展功能,当然一个节点也可以组成一个集群。
集群由唯一名称标识,默认情况下为“elasticsearch”。此名称很重要,因为如果节点设置为按名称加入集群的话,则该节点只能是集群的一部分。
确保不同的环境中使用不同的集群名称,否则最终会导致节点加入错误的集群。
【集群健康状态】
集群状态通过 绿,黄,红 来标识
- 绿色 - 一切都很好(集群功能齐全)。
- 黄色 - 所有数据均可用,但尚未分配一些副本(集群功能齐全)。
- 红色 - 某些数据由于某种原因不可用(集群部分功能)。
注意:当群集为红色时,它将继续提供来自可用分片的搜索请求,但您可能需要尽快修复它,因为存在未分配的分片。
要检查群集运行状况,我们可以在 Kibana 控制台中运行以下命令GET /_cluster/health
,得到如下信息:
节点,一个运行的 ES 实例就是一个节点,节点存储数据并参与集群的索引和搜索功能。
就像集群一样,节点由名称标识,默认情况下,该名称是在启动时分配给节点的随机通用唯一标识符(UUID)。如果不需要默认值,可以定义所需的任何节点名称。此名称对于管理目的非常重要,您可以在其中识别网络中哪些服务器与 Elasticsearch 集群中的哪些节点相对应。
可以将节点配置为按集群名称加入特定集群。默认情况下,每个节点都设置为加入一个名为 cluster 的 elasticsearch 集群,这意味着如果您在网络上启动了许多节点并且假设它们可以相互发现 - 它们将自动形成并加入一个名为 elasticsearch 的集群。
索引是具有某些类似特征的文档集合。例如,您可以拥有店铺数据的索引,商品的一个索引以及订单数据的一个索引。
索引由名称标识(必须全部小写),此名称用于在对其中的文档执行索引,搜索,更新和删除操作时引用索引。
类型,曾经是索引的逻辑类别/分区,允许您在同一索引中存储不同类型的文档,例如,一种类型用于用户,另一种类型用于博客帖子。
在 6.0.0 中弃用,以后将不再可能在索引中创建多个类型,并且将在更高版本中删除类型的整个概念。
文档是可以建立索引的基本信息单元。例如,您可以为单个客户提供文档,为单个产品提供一个文档,为单个订单提供一个文档。该文档以JSON(JavaScript Object Notation)表示,JSON是一种普遍存在的互联网数据交换格式。
在索引/类型中,您可以根据需要存储任意数量的文档。请注意,尽管文档实际上驻留在索引中,但实际上必须将文档编入索引/分配给索引中的类型。
索引可能存储大量可能超过单个节点的硬件限制的数据。例如,占用1TB磁盘空间的十亿个文档的单个索引可能不适合单个节点的磁盘,或者可能太慢而无法单独从单个节点提供搜索请求。
为了解决这个问题,Elasticsearch 提供了将索引细分为多个称为分片的功能。创建索引时,只需定义所需的分片数即可。每个分片本身都是一个功能齐全且独立的“索引”,可以托管在集群中的任何节点上。
设置分片的目的及原因主要是:
分片的分布方式以及如何将其文档聚合回搜索请求的机制完全由 Elasticsearch 管理,对用户而言是透明的。
在可能随时发生故障的网络/云环境中,分片非常有用,建议使用故障转移机制,以防分片/节点以某种方式脱机或因任何原因消失。为此,Elasticsearch 允许您将索引的分片的一个或多个副本制作成所谓的副本分片或简称副本。
副本,是对分片的复制。目的是为了当分片/节点发生故障时提供高可用性,它允许您扩展搜索量/吞吐量,因为可以在所有副本上并行执行搜索。
总而言之,每个索引可以拆分为多个分片。索引也可以复制为零次(表示没有副本)或更多次。复制之后,每个索引将具有主分片(从原始分片复制而来的)和复制分片(主分片的副本)。
可以在创建索引时为每个索引定义分片和副本的数量。创建索引后,您也可以随时动态更改副本数。您可以使用_shrink
和 _splitAPI
更改现有索引的分片数,但这不是一项轻松的任务,所以预先计划正确数量的分片是最佳方法。
默认情况下,Elasticsearch 中的每个索引都分配了5个主分片和1个副本,这意味着如果集群中至少有两个节点,则索引将包含5个主分片和另外5个副本分片(1个完整副本),总计为每个索引10个分片。
我们假设有一个集群由三个节点组成(Node1 , Node2 , Node3)。 它有两个主分片(P0 , P1),每个主分片有两个副本分片(R0 , R1)。相同分片的副本不会放在同一节点,所以我们的集群看起来如下图所示 “有三个节点和一个索引的集群”。
类似于关系型数据库:数据库集群,假如有个用户表,我担心数据量过大,我新建了多个用户表(即 Shard),将用户信息数据切分成多份,然后根据某种规则分到这些用户表中,我又担心某个表会出现异常造成数据丢失,我又将每个表分别备份了一次(即 Replica )。
副本是乘法,越多越浪费,但也越保险。分片是除法,分片越多,单分片数据就越少也越分散。
另外,我们可以画一个对比图来类比传统关系型数据库:
- 关系型数据库 -> Databases(库) -> Tables(表) -> Rows(行) -> Columns(列)。
- Elasticsearch -> Indeces(索引) -> Types(类型) -> Documents(文档) -> Fields(属性)。
Elasticsearch集群可以包含多个索引(indices)(数据库),每一个索引可以包含多个类型 (Types)(表),每一个类型包含多个文档(documents)(行),然后每个文档包含多个字段(Fields)(列)。
虽然这么类比,但是毕竟是两个差异化的产品,而且上面也说过在以后的版本中类型 (Types) 可能会被删除,所以一般我们创建索引都是一个种类对应一个索引。生鲜就创建商品的索引,生活用品就创建生活用品的索引,而不会说创建一个商品的索引,里面既包含生鲜的类型,又包含生活用品的类型。
而且你可能已经注意到索引(index)这个词在Elasticsearch中有着不同的含义,所以有必要在此做一下区分:
「索引」含义的区分
- 索引(名词) 如上文所述,一个索引(index)就像是传统关系数据库中的数据库,它是相关文档存储的地方,index的复数是 indices 或 indexes。
- 索引(动词) 「索引一个文档」表示把一个文档存储到索引(名词)里,以便它可以被检索或者查询。这很像SQL中的INSERT关键字,差别是,如果文档已经存在,新的文档将覆盖旧的文档。
- 倒排索引 传统数据库为特定列增加一个索引,例如B-Tree索引来加速检索。Elasticsearch和Lucene使用一种叫做倒排索引(inverted index)的数据结构来达到相同目的。
目前与 elasticsearch 交互主要有两种方式:Client API 和 RESTful API。
Client API方式:
Elasticsearch 为以下语言提供了官方客户端 --Groovy、JavaScript、.NET、 PHP、 Perl、 Python 和 Ruby--还有很多社区提供的客户端和插件,所有这些都可以在 Elasticsearch Clients 中找到。后面再开一篇来详细说明。
RESTful API with JSON over HTTP:
所有其他语言可以使用 RESTful API 通过端口 9200 和 Elasticsearch 进行通信,你可以用你最喜爱的 web 客户端访问 Elasticsearch 。事实上,正如你所看到的,你甚至可以使用 curl 命令来和 Elasticsearch 交互。
一个 Elasticsearch 请求和任何 HTTP 请求一样由若干相同的部件组成:
curl -X<VERB> ‘<PROTOCOL>://<HOST>:<PORT>/<PATH>?<QUERY_STRING>‘ -d ‘<BODY>‘
被 < >
标记的部件:
在应用程序中对象很少只是一个简单的键和值的列表。通常,它们拥有更复杂的数据结构,可能包括日期、地理信息、其他对象或者数组等。
也许有一天你想把这些对象存储在数据库中。使用关系型数据库的行和列存储,这相当于是把一个表现力丰富的对象挤压到一个非常大的电子表格中:你必须将这个对象扁平化来适应表结构,通常一个字段对应一列,而且又不得不在每次查询时重新构造对象。
Elasticsearch 是面向文档的,意味着它存储整个对象或文档。Elasticsearch 不仅存储文档,而且 每个文档的内容可以被检索。在 Elasticsearch 中,你对文档进行索引、检索、排序和过滤而不是对行列数据。这是一种完全不同的思考数据的方式,也是 Elasticsearch 能支持复杂全文检索的原因。
Elasticsearch 使用 JavaScript Object Notation 或者 JSON 作为文档的序列化格式。JSON 序列化被大多数编程语言所支持,并且已经成为 NoSQL 领域的标准格式。 它简单、简洁、易于阅读。几乎所有的语言都有相应的模块可以将任意的数据结构或对象 转化成 JSON 格式,只是细节各不相同。
一切准备就绪之后我们开始来使用起来,体验 ElasticSearch 的世界。首先,我们来查看我们的所有索引信息:
得到如下结果信息:
可以发现,当前只有一个索引,是.kibana
,当然这不是我们自己的,这是kibana的。
NBA的新的赛季又开始了,我相信大部分人有精彩比赛的时候还是会去关注的,我们创建一个 NBA 球队的索引,开始我们的学习之路,索引名称需是小写。
字段说明:
字段名称 | 字段说明 |
---|---|
nba | 索引 |
number_of_shards | 分片数 |
number_of_replicas | 副本数 |
name_cn | 球队中文名 |
name_en | 球队英文名 |
gymnasium | 球馆名称 |
championship | 总冠军次数 |
topStar | 当家球星 |
date | 加入NBA年份 |
如果格式书写正确,我们会得到如下返回信息,表示创建成功
索引创建完成之后,我们往索引中加入球队数据,1,2,3 是我们指定的 ID,如果不写 ES 会默认ID。
其实我们可以不创建上面的索引 mapping 直接推送数据,但是这样 ES 会根据数据信息自动为我们设定字段类型,这会造成索引信息不准确的风险。
索引数据 PUT 成功,会返回如下信息
上面新增完数据之后,这时候我们再执行开始的 MATCH_ALL ,就会发现我们自己的索引信息也在查询的结果里面了,只是查询的结果是全部信息,其中包括索引、分片和副本的信息,内容比较多。我们可单独查询自己需要的索引信息。
Elasticsearch 提供丰富且灵活的查询语言叫做 DSL 查询 (Query DSL) ,它允许你构建更加复杂、强大的搜索。
1.匹配查询 match,match_all
我们尝试一个最简单的搜索全部员工的请求:
# 查询全部球队的信息
得到的查询结果如下
响应的数据结果分为两部分
第一部分为:分片副本信息,第二部分 hits
包装的为查询的数据集。
注意:
响应内容不仅会告诉我们哪些文档被匹配到,而且这些文档内容完整的被包含在其中—我们在给用户展示搜 索结果时需要用到的所有信息都有了。
# 查询英文名称为:"Golden State Warriors" 的球队信息
可得到的查询结果为:
2.过滤查询 Filter
我们让搜索变的复杂一些。我们想要找到当家球星是勒布朗·詹姆斯,但是我们只想得到总冠军多余1次的球队。我们的语句将做一些改变用来添加过滤器(filter),它允许我们有效的执行一个结构化搜索:
我们发现每次查询,查询结果里面都有一个 _score
字段,一般Elasticsearch根据相关评分排序,相关评分是根据文档与语句的匹配度来得出, _score
值越高说明匹配度越高。
Elasticsearch如何进行全文字段搜索且首先返回相关性性最大的结果。相关性(relevance)概念在Elasticsearch中非常重要,而这也是它与传统关系型数据库中记录只有匹配和不匹配概念最大的不同。
由于篇幅限制,对于 ElasticSearch 最基本的概念暂时先介绍这么多,要写的内容还很多,经过接近一个月的技术调研和开发,目前对于 ES 也有一个总体的技术了解,但是很多细节还是需要琢磨的,ES 的功能确实强大且丰富,要想熟练耍起来,还是需要一定时间的。
后面会继续介绍 ES的相关内容,大概包括 ES 服务的 Java 语言搭建,ES 的 SQL方式查询等等内容。有兴趣的可以先关注本人的博客,由于质量要求大概一星期更新一篇。
另外,我这里添加一个园友ReyCG对本篇文章的思维导图总结,通过该思维导图我们可以更加清晰的理解Elasticsearch的基础信息。
标签:构造 map 功能 max block 规则 列表 执行 自动
原文地址:https://www.cnblogs.com/liliuguang/p/12356196.html