Elasticsearch是一个高度可扩展开源的全文搜索引擎.它搜索几乎是实时的,用ES做为搜索引擎,为复杂搜索功能的需求提供解决方案.java
ES的使用场景:node
网上商场,搜索商品.mysql
ES配合logstash,kibana,日志分析.linux
本教程的其余部分,将指导你完成ES的安装,启动,浏览,以及数据的CRUD.若是你完整的完成了本教程,你应该已经对ES有很好的了解了,但愿你能从中受到启发.sql
ES有几个核心概念,从一开始理解这些概念将对你后面的学习有很大帮助。shell
近实时(NRT)express
ES是一个近实时的搜索引擎(平台),表明着从添加数据到能被搜索到只有不多的延迟。(大约是1s)json
集群api
能够将多台ES服务器做为集群使用,能够在任何一台节点上进行搜索。集群有一个默认的名称(可修改),“elasticsearch”,这个集群名称必须是惟一的,由于集群的节点是经过集群名称来加入集群的。数组
确保在相同环境中不要有相同的集群名称,不然有可能节点会加入到非预期的集群中。
节点
节点是做为集群的一部分的单个服务器,存储数据,而且参与集群的索引和搜索功能。与集群同样,节点由一个名称标识,默认状况下,该名称是在启动时分配给节点的随机通用惟一标识符(UUID)。若是不但愿使用默认值,则能够定义所需的任何节点名称。此名称对于管理目的很重要,由于您但愿肯定网络中的哪些服务器对应于ElasticSearch集群中的哪些节点。
索引
索引是具备某种类似特性的文档集合。例如,您能够拥有客户数据的索引、产品目录的另外一个索引以及订单数据的另外一个索引。索引由一个名称(必须所有是小写)标识,当对其中的文档执行索引、搜索、更新和删除操做时,该名称用于引用索引。在单个集群中,您能够定义任意多个索引。
若是你学习过Mysql ,能够将其暂时理解为 MySql中的 database。
类型
一个索引能够有多个类型。例如一个索引下能够有文章类型,也能够有用户类型,也能够有评论类型。在一个索引中不能再建立多个类型,在之后的版本中将删除类型的整个概念。
在Elasticsearch 7.0.0或更高版本中建立的索引再也不接受
_default_
映射。在6.x中建立的索引将继续像之前同样在Elasticsearch 6.x中运行。在7.0中的API中不推荐使用类型,对索引建立,放置映射,获取映射,放置模板,获取模板和获取字段映射API进行重大更改。
文档
一个文档是一个可被索引的基础信息单元。好比,你能够拥有某一个客户的文档,某一个产品的一个文档,固然,也能够拥有某个订单的一个文档。文档以JSON(Javascript Object Notation)格式来表示,而JSON是一个处处存在的互联网数据交互格式。
在一个index/type里面,你能够存储任意多的文档。注意,尽管一个文档,物理上存在于一个索引之中,文档必须被索引/赋予一个索引的type。
分片和副本
索引可能存储大量数据,这些数据可能会c超出单个节点的硬件限制。例如,占用1TB磁盘空间的10亿个文档的单个索引可能不适合单个节点的磁盘,或者速度太慢,没法单独知足单个节点的搜索请求。
为了解决这个问题,ElasticSearch提供了将索引细分为多个片断(称为碎片)的能力。建立索引时,只需定义所需的碎片数量。每一个分片(shard)自己就是一个彻底功能性和独立的“索引”,能够托管在集群中的任何节点上。
为何要分片?
它容许您水平拆分/缩放内容量
它容许您跨碎片(可能在多个节点上)分布和并行操做,从而提升性能/吞吐量
如何分配分片以及如何将其文档聚合回搜索请求的机制彻底由ElasticSearch管理,而且对做为用户的您是透明的。
在随时可能发生故障的网络/云环境中,很是有用,强烈建议在碎片/节点以某种方式脱机或因任何缘由消失时使用故障转移机制。为此,ElasticSearch容许您将索引分片的一个或多个副本复制成所谓的副本分片,简称为副本分片。
为何要有副本?
当分片/节点发生故障时提供高可用性。所以,须要注意的是,副本分片永远不会分配到复制它的原始/主分片所在的节点上。
容许您扩展搜索量/吞吐量,由于能够在全部副本上并行执行搜索。
总而言之,每一个索引能够分割成多个分片。索引也能够零次(意味着没有副本)或屡次复制。复制后,每一个索引将具备主分片(从中复制的原始分片)和副本分片(主分片的副本)。
能够在建立索引时为每一个索引定义分片和副本的数量。建立索引后,您还能够随时动态更改副本的数量。您可使用收缩和拆分API更改现有索引的分片数量,建议在建立索引时就考虑好分片和副本的数量。
默认状况下,ElasticSearch中的每一个索引都分配一个主分片和一个副本,这意味着若是集群中至少有两个节点,则索引将有一个主分片和另外一个副本分片(一个完整副本),每一个索引总共有两个分片。
每一个ElasticSearch分片都是一个Lucene索引。在一个Lucene索引中,能够有最多数量的文档。从Lucene-5843起,限制为2147483519(=integer.max_value-128)个文档。您可使用 api监视碎片大小(之后会讲到)。
接下来让咱们开始有趣的部分吧...
二进制文件可从www.slastic.co/downloads以及过去发布的全部版本中得到。对于每一个版本,Windows、Linux和MacOS以及Linux的DEB和RPM软件包以及Windows的MSI安装软件包都提供了与平台相关的存档版本。
Linux
简单起见,咱们使用tarb包进行安装
下载ElasticSearch 7.1.1 Linux tar。
curl -L -O https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-7.1.1-linux-x86_64.tar.gz复制代码
解压
tar -xvf elasticsearch-7.1.1-linux-x86_64.tar.gz复制代码
解压完成将在当前目录中建立一组文件和文件夹,而后咱们进入bin目录。
cd elasticsearch-7.1.1/bin复制代码
启动节点和单个集群
./elasticsearch复制代码
Windows
对于Windows用户,咱们建议使用msi安装程序包。该包包含一个图形用户界面(GUI),指导您完成安装过程。
而后双击下载的文件以启动GUI。在第一个屏幕中,选择安装目录:
而后选择是做为服务安装,仍是根据须要手动启动ElasticSearch。要与Linux示例保持一致,请选择不做为服务安装:
对于配置,只需保留默认值:
取消选中全部插件以不安装任何插件:
单击“安装”按钮后,将安装ElasticSearch:
默认状况下,ElasticSearch将安装在%ProgramFiles%\Elastic\ElasticSearch。进入安装目录,打开命令提示符,输入
.\elasticsearch.exe复制代码
成功运行节点
若是安装一切顺利,您将看到下面的一堆消息:
[2018-09-13T12:20:01,766][INFO ][o.e.e.NodeEnvironment ] [localhost.localdomain] using [1] data paths, mounts [[/home (/dev/mapper/fedora-home)]], net usable_space [335.3gb], net total_space [410.3gb], types [ext4][2018-09-13T12:20:01,772][INFO ][o.e.e.NodeEnvironment ] [localhost.localdomain] heap size [990.7mb], compressed ordinary object pointers [true][2018-09-13T12:20:01,774][INFO ][o.e.n.Node ] [localhost.localdomain] node name [localhost.localdomain], node ID [B0aEHNagTiWx7SYj-l4NTw][2018-09-13T12:20:01,775][INFO ][o.e.n.Node ] [localhost.localdomain] version[7.1.1], pid[13030], build[oss/zip/77fc20e/2018-09-13T15:37:57.478402Z], OS[Linux/4.16.11-100.fc26.x86_64/amd64], JVM["Oracle Corporation"/OpenJDK 64-Bit Server VM/10/10+46][2018-09-13T12:20:01,775][INFO ][o.e.n.Node ] [localhost.localdomain] JVM arguments [-Xms1g, -Xmx1g, -XX:+UseConcMarkSweepGC, -XX:CMSInitiatingOccupancyFraction=75, -XX:+UseCMSInitiatingOccupancyOnly, -XX:+AlwaysPreTouch, -Xss1m, -Djava.awt.headless=true, -Dfile.encoding=UTF-8, -Djna.nosys=true, -XX:-OmitStackTraceInFastThrow, -Dio.netty.noUnsafe=true, -Dio.netty.noKeySetOptimization=true, -Dio.netty.recycler.maxCapacityPerThread=0, -Dlog4j.shutdownHookEnabled=false, -Dlog4j2.disable.jmx=true, -Djava.io.tmpdir=/tmp/elasticsearch.LN1ctLCi, -XX:+HeapDumpOnOutOfMemoryError, -XX:HeapDumpPath=data, -XX:ErrorFile=logs/hs_err_pid%p.log, -Xlog:gc*,gc+age=trace,safepoint:file=logs/gc.log:utctime,pid,tags:filecount=32,filesize=64m, -Djava.locale.providers=COMPAT, -XX:UseAVX=2, -Dio.netty.allocator.type=unpooled, -Des.path.home=/home/manybubbles/Workspaces/Elastic/master/elasticsearch/qa/unconfigured-node-name/build/cluster/integTestCluster node0/elasticsearch-7.0.0-alpha1-SNAPSHOT, -Des.path.conf=/home/manybubbles/Workspaces/Elastic/master/elasticsearch/qa/unconfigured-node-name/build/cluster/integTestCluster node0/elasticsearch-7.0.0-alpha1-SNAPSHOT/config, -Des.distribution.flavor=oss, -Des.distribution.type=zip][2018-09-13T12:20:02,543][INFO ][o.e.p.PluginsService ] [localhost.localdomain] loaded module [aggs-matrix-stats][2018-09-13T12:20:02,543][INFO ][o.e.p.PluginsService ] [localhost.localdomain] loaded module [analysis-common][2018-09-13T12:20:02,543][INFO ][o.e.p.PluginsService ] [localhost.localdomain] loaded module [ingest-common][2018-09-13T12:20:02,544][INFO ][o.e.p.PluginsService ] [localhost.localdomain] loaded module [lang-expression][2018-09-13T12:20:02,544][INFO ][o.e.p.PluginsService ] [localhost.localdomain] loaded module [lang-mustache][2018-09-13T12:20:02,544][INFO ][o.e.p.PluginsService ] [localhost.localdomain] loaded module [lang-painless][2018-09-13T12:20:02,544][INFO ][o.e.p.PluginsService ] [localhost.localdomain] loaded module [mapper-extras][2018-09-13T12:20:02,544][INFO ][o.e.p.PluginsService ] [localhost.localdomain] loaded module [parent-join][2018-09-13T12:20:02,544][INFO ][o.e.p.PluginsService ] [localhost.localdomain] loaded module [percolator][2018-09-13T12:20:02,544][INFO ][o.e.p.PluginsService ] [localhost.localdomain] loaded module [rank-eval][2018-09-13T12:20:02,544][INFO ][o.e.p.PluginsService ] [localhost.localdomain] loaded module [reindex][2018-09-13T12:20:02,545][INFO ][o.e.p.PluginsService ] [localhost.localdomain] loaded module [repository-url][2018-09-13T12:20:02,545][INFO ][o.e.p.PluginsService ] [localhost.localdomain] loaded module [transport-netty4][2018-09-13T12:20:02,545][INFO ][o.e.p.PluginsService ] [localhost.localdomain] no plugins loaded[2018-09-13T12:20:04,657][INFO ][o.e.d.DiscoveryModule ] [localhost.localdomain] using discovery type [zen][2018-09-13T12:20:05,006][INFO ][o.e.n.Node ] [localhost.localdomain] initialized[2018-09-13T12:20:05,007][INFO ][o.e.n.Node ] [localhost.localdomain] starting ...[2018-09-13T12:20:05,202][INFO ][o.e.t.TransportService ] [localhost.localdomain] publish_address {127.0.0.1:9300}, bound_addresses {[::1]:9300}, {127.0.0.1:9300}[2018-09-13T12:20:05,221][WARN ][o.e.b.BootstrapChecks ] [localhost.localdomain] max file descriptors [4096] for elasticsearch process is too low, increase to at least [65535][2018-09-13T12:20:05,221][WARN ][o.e.b.BootstrapChecks ] [localhost.localdomain] max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144][2018-09-13T12:20:08,355][INFO ][o.e.c.s.MasterService ] [localhost.localdomain] elected-as-master ([0] nodes joined)[, ], reason: master node changed {previous [], current [{localhost.localdomain}{B0aEHNagTiWx7SYj-l4NTw}{hzsQz6CVQMCTpMCVLM4IHg}{127.0.0.1}{127.0.0.1:9300}{testattr=test}]}[2018-09-13T12:20:08,360][INFO ][o.e.c.s.ClusterApplierService] [localhost.localdomain] master node changed {previous [], current [{localhost.localdomain}{B0aEHNagTiWx7SYj-l4NTw}{hzsQz6CVQMCTpMCVLM4IHg}{127.0.0.1}{127.0.0.1:9300}{testattr=test}]}, reason: apply cluster state (from master [master {localhost.localdomain}{B0aEHNagTiWx7SYj-l4NTw}{hzsQz6CVQMCTpMCVLM4IHg}{127.0.0.1}{127.0.0.1:9300}{testattr=test} committed version [1] source [elected-as-master ([0] nodes joined)[, ]]])[2018-09-13T12:20:08,384][INFO ][o.e.h.n.Netty4HttpServerTransport] [localhost.localdomain] publish_address {127.0.0.1:9200}, bound_addresses {[::1]:9200}, {127.0.0.1:9200}[2018-09-13T12:20:08,384][INFO ][o.e.n.Node ] [localhost.localdomain] started复制代码
咱们能够看到名为“6-bjhwl”的节点(在您的示例中是一组不一样的字符)已经启动,并将本身选为单个集群中的主机。如今还不用担忧master是什么意思。这里最重要的是,咱们已经在一个集群中启动了一个节点。
如前所述,咱们能够覆盖集群或节点名。当启动ElasticSearch时,能够从命令行执行此操做,以下所示:
./elasticsearch -Ecluster.name=my_cluster_name -Enode.name=my_node_name复制代码
还请注意标记为http的行,其中包含可从中访问节点的http地址(192.168.8.112)和端口(9200)的信息。默认状况下,ElasticSearch使用端口9200提供对其RESTAPI的访问。若有必要,此端口可配置。
使用REST API
如今咱们已经启动并运行了节点(和集群),下一步就是了解如何与之通讯。幸运的是,ElasticSearch提供了一个很是全面和强大的RESTAPI,您可使用它与集群进行交互。可使用API执行的少数操做以下:
检查集群、节点和索引的运行情况、状态和统计信息。
管理集群、节点和索引数据和元数据。
对索引执行CRUD(建立、读取、更新和删除)和搜索操做。
执行高级搜索操做,如分页、排序、筛选、脚本编写、聚合和许多其余操做。
让咱们从一个基本的健康检查开始,咱们可使用它来查看集群的运行状况。咱们将使用curl来实现这一点,但您可使用任何容许您进行HTTP/REST调用的工具。假设咱们仍然在启动ElasticSearch并打开另外一个命令shell窗口的同一个节点上。
为了检查集群的运行情况,咱们将使用_cat
API。您能够在Kibana的控制台中运行下面的命令,方法是单击“在控制台中查看”,或者使用curl,方法是单击下面的“复制为curl”连接并将其粘贴到终端中。
curl -X GET "localhost:9200/_cat/health?v"复制代码
响应结果:
epoch timestamp cluster status node.total node.data shards pri relo init unassign pending_tasks max_task_wait_time active_shards_percent1475247709 17:01:49 elasticsearch green 1 1 0 0 0 0 0 0 - 100.0%复制代码
咱们能够看到名为“elasticsearch”的集群处于绿色状态。每当咱们请求集群健康时,咱们要么获得绿色、黄色,要么获得红色。
绿色-一切正常(集群功能齐全)
黄色-全部数据均可用,但某些副本还没有分配(群集彻底正常工做)
红色-因为任何缘由,某些数据不可用(群集部分正常工做)
注意:当集群为红色时,它将继续提供来自可用分片的搜索请求,但您可能须要尽快修复它,由于存在未分配的分片。
从上面的响应中,咱们能够看到总共1个节点,而且咱们有0个碎片,由于咱们在其中尚未数据。请注意,因为咱们使用的是默认群集名称(ElasticSearch),而且因为ElasticSearch默认状况下发如今同一台计算机上查找其余节点,所以您可能会意外启动计算机上的多个节点,并使它们都加入单个群集。在这个场景中,您可能会在上面的响应中看到多个节点。
咱们还能够获得集群中的节点列表:
curl -X GET "localhost:9200/_cat/nodes?v"复制代码
响应结果:
ip heap.percent ram.percent cpu load_1m load_5m load_15m node.role master name127.0.0.1 10 5 5 4.46 mdi * PB2SGZY复制代码
咱们能够看到一个名为“pb2sgzy”的节点,它是当前集群中的单个节点。
如今让咱们来看看咱们的索引:
curl -X GET "localhost:9200/_cat/indices?v"复制代码
响应结果:
health status index uuid pri rep docs.count docs.deleted store.size pri.store.size复制代码
这就意味着咱们在集群中尚未索引。
如今,让咱们建立一个名为“customer”的索引,而后再次列出全部索引:
curl -X PUT "localhost:9200/customer?pretty"curl -X GET "localhost:9200/_cat/indices?v"复制代码
第一个命令使用put动词建立名为“customer”的索引。咱们只需在调用的末尾附加pretty
命令它漂亮地打印JSON响应(若是有的话)。
响应结果:
health status index uuid pri rep docs.count docs.deleted store.size pri.store.sizeyellow open customer 95SQ4TSUT7mWBT7VNHH67A 1 1 0 0 260b 260b复制代码
第二个命令的结果告诉咱们,咱们如今有一个名为customer的索引,它有一个主碎片和一个副本(默认值),其中包含零个文档。
您可能还会注意到客户索引中有一个黄色的健康标签。回想咱们以前的讨论,黄色意味着一些副本还没有分配。此索引起生这种状况的缘由是,默认状况下,ElasticSearch为此索引建立了一个副本。由于目前只有一个节点在运行,因此在另外一个节点加入集群以前,还不能分配一个副本(为了高可用性)。一旦该副本分配到第二个节点上,该索引的运行情况将变为绿色。
如今咱们把一些东西放到客户索引中。咱们将在客户索引中索引一个简单的客户文档,其ID为1,以下所示:
curl -X PUT "localhost:9200/customer/_doc/1?pretty" -H 'Content-Type: application/json' -d'{ "name": "John Doe"}'复制代码
响应结果:
{ "_index" : "customer", "_type" : "_doc", "_id" : "1", "_version" : 1, "result" : "created", "_shards" : { "total" : 2, "successful" : 1, "failed" : 0 }, "_seq_no" : 0, "_primary_term" : 1}复制代码
从上面,咱们能够看到在客户索引中成功地建立了一个新的客户文档。文档还有一个内部ID 1,咱们在索引时指定了它。
须要注意的是,ElasticSearch不要求您在索引文档以前先显式建立索引。在上一个示例中,若是客户索引以前不存在,那么ElasticSearch将自动建立该索引。
如今让咱们检索刚才索引的文档:
curl -X GET "localhost:9200/customer/_doc/1?pretty"复制代码
响应结果:
{ "_index" : "customer", "_type" : "_doc", "_id" : "1", "_version" : 1, "_seq_no" : 25, "_primary_term" : 1, "found" : true, "_source" : { "name": "John Doe" }}复制代码
除了一个字段以外found
,这里没有发现任何异常的地方,说明咱们找到了一个具备请求的ID 1的文档和另外一个字段_source
,它返回了咱们从上一步索引的完整JSON文档。
如今,让咱们删除刚刚建立的索引,而后再次列出全部索引:
curl -X DELETE "localhost:9200/customer?pretty"curl -X GET "localhost:9200/_cat/indices?v"复制代码
响应结果:
health status index uuid pri rep docs.count docs.deleted store.size pri.store.size复制代码
这意味着索引被成功地删除了,如今咱们又回到了开始时集群中什么都没有的地方。
在咱们继续以前,让咱们再仔细看看咱们迄今为止学到的一些API命令:
#建立索引curl -X PUT "localhost:9200/customer"#建立文档(添加数据)curl -X PUT "localhost:9200/customer/_doc/1" -H 'Content-Type: application/json' -d'{ "name": "John Doe"}'#查询文档(查询数据)curl -X GET "localhost:9200/customer/_doc/1"#删除文档(删除数据)curl -X DELETE "localhost:9200/customer"复制代码
若是咱们仔细研究上述命令,咱们实际上能够看到在ElasticSearch中如何访问数据的模式。这种模式能够归纳以下:
<HTTP Verb> /<Index>/<Endpoint>/<ID>复制代码
这种REST访问模式在全部API命令中都很是广泛,若是您能记住它,那么您将在掌握ElasticSearch方面有一个很好的开端。
ElasticSearch提供近实时的数据操做和搜索功能。默认状况下,从索引/更新/删除数据到数据出如今搜索结果中,预计一秒钟的延迟(刷新间隔)。这是与其余平台(如SQL)的一个重要区别,在SQL中,数据在事务完成后当即可用。
建立/替换文档(修改数据)
咱们之前见过如何索引单个文档。让咱们再次回忆一下这个命令:
curl -X PUT "localhost:9200/customer/_doc/1?pretty" -H 'Content-Type: application/json' -d'{ "name": "John Doe"}'复制代码
一样,上面将把指定的文档索引到客户索引中,ID为1。若是咱们用不一样的(或相同的)文档再次执行上述命令,那么ElasticSearch将在现有文档的基础上替换(即从新建立)一个ID为1的新文档:
curl -X PUT "localhost:9200/customer/_doc/1?pretty" -H 'Content-Type: application/json' -d'{ "name": "Jane Doe"}'复制代码
上面将ID为1的文档的名称从“John Doe”更改成“Jane Doe”。另外一方面,若是咱们使用不一样的ID,则会建立新的文档,而且索引中已有的文档将保持不变。
上面的索引是一个ID为2的新文档。
建立时,ID是可填可不填的。若是未指定,ElasticSearch将生成一个随机ID。ElasticSearch生成的实际ID(或在前面的示例中显式指定的任何内容)做为索引API调用的一部分返回。
此示例演示如何索引没有显式ID的文档:
curl -X POST "localhost:9200/customer/_doc?pretty" -H 'Content-Type: application/json' -d'{ "name": "Jane Doe"}'复制代码
注意,在上述状况下,咱们使用的是post
动词而不是put
,由于咱们没有指定ID。
除了可以添加和替换文档以外,咱们也能够更新文档。请注意,Elasticsearch实际上并无在底层执行覆盖更新。而是先删除旧文档,再添加一条新文档。
这个例子把原来ID为1的名字修改为了Jane Doe,详情请看下面的例子:
curl -X POST "localhost:9200/customer/_update/1?pretty" -H 'Content-Type: application/json' -d'{ "doc": { "name": "Jane Doe" }}'复制代码
此示例演示如何经过将名称字段更改成“Jane Doe”来更新之前的文档(ID为1),同时向其添加年龄字段:
curl -X POST "localhost:9200/customer/_update/1?pretty" -H 'Content-Type: application/json' -d'{ "doc": { "name": "Jane Doe", "age": 20 }}'复制代码
也可使用简单的脚本执行更新,此示例使用脚本将年龄增长5:
curl -X POST "localhost:9200/customer/_update/1?pretty" -H 'Content-Type: application/json' -d'{ "script" : "ctx._source.age += 5"}'复制代码
Elasticsearch提供了给定条件下更新多个文档的功能,就像Sql中的updata ... where ...
后面的章节咱们会详细介绍。
删除文档至关简单。
此示例显示如何删除ID为2的之前的客户:
curl -X DELETE "localhost:9200/customer/_doc/2?pretty"复制代码
请参阅_delete_by_query API来删除与特定查询匹配的全部文档。值得注意的是,删除整个索引比使用delete By Query API删除全部文档要有效得多。 _delete_by_query API
会在后面详细介绍。
除了可以索引、更新和删除单个文档以外,Elasticsearch还提供了使用_bulk API批量执行上述操做的能力。此功能很是重要,由于它提供了一种很是有效的机制,能够在尽量少的网络往返的状况下尽量快地执行多个操做。
做为一个简单的例子,下面的调用在一个批量操做中索引两个文档(ID 1 - John Doe和ID 2 - Jane Doe):
curl -X POST "localhost:9200/customer/_bulk?pretty" -H 'Content-Type: application/json' -d'{"index":{"_id":"1"}}{"name": "John Doe" }{"index":{"_id":"2"}}{"name": "Jane Doe" }'复制代码
此例更新第一个文档(ID为1),而后在一次批量操做中删除第二个文档(ID为2):
curl -X POST "localhost:9200/customer/_bulk?pretty" -H 'Content-Type: application/json' -d'{"update":{"_id":"1"}}{"doc": { "name": "John Doe becomes Jane Doe" } }{"delete":{"_id":"2"}}'复制代码
请注意,对于delete操做,它以后没有对应的源文档,由于删除操做只须要删除文档的ID。
批量API不会由于某个操做失败而失败(有错误也会执行下去,最后会返回每一个操做的状态)。若是一个操做因为某种缘由失败,它将在失败以后继续处理其他的操做。当bulk API返回时,它将为每一个操做提供一个状态(与发送操做的顺序相同),以便检查某个特定操做是否失败。
样本数据
如今咱们已经了解了基本知识,让咱们尝试使用更真实的数据集。我准备了一个虚构的JSON客户银行帐户信息文档示例。每一个文档都有如下内容:
{ "account_number": 0, "balance": 16623, "firstname": "Bradshaw", "lastname": "Mckenzie", "age": 29, "gender": "F", "address": "244 Columbus Place", "employer": "Euron", "email": "bradshawmckenzie@euron.com", "city": "Hobucken", "state": "CO"}复制代码
该数据是使用www.json- generator.com/生成的,所以请忽略数据的实际值和语义,由于它们都是随机生成的。
加载样本数据
您能够从这里下载示例数据集(accounts.json)。将其提取到当前目录,而后按以下方式将其加载到集群中:
curl -H "Content-Type: application/json" -XPOST "localhost:9200/bank/_bulk?pretty&refresh" --data-binary "@accounts.json"curl "localhost:9200/_cat/indices?v"复制代码
响应结果:
health status index uuid pri rep docs.count docs.deleted store.size pri.store.sizeyellow open bank l7sSYV2cQXmu6_4rJWVIww 5 1 1000 0 128.6kb 128.6kb复制代码
这意味着咱们刚刚成功地将索引的1000个文档批量存储到银行索引中。
如今让咱们从一些简单的搜索开始。运行搜索有两种基本方法:
一种是经过REST请求URI发送搜索参数。
另外一种是经过REST请求体发送搜索参数。
请求体方法容许您更富表现力,还能够以更可读的JSON格式定义搜索。咱们将尝试请求URI方法的一个示例,可是在本教程的其他部分中,咱们将只使用请求体方法。
用于搜索的REST API能够从_search
端点访问。这个例子返回银行索引中的全部文档:
curl -X GET "localhost:9200/bank/_search?q=*&sort=account_number:asc&pretty"复制代码
让咱们首先分析一下搜索调用。咱们正在银行索引中搜索(_search
),q=*
参数指示Elasticsearch匹配索引中的全部文档。sort=account_number:asc
参数指示使用每一个文档的account_number字段按升序对结果排序。一样,pretty
参数只告诉Elasticsearch返回打印得很漂亮的JSON结果。
相应结果(部分显示):
{ "took" : 63, "timed_out" : false, "_shards" : { "total" : 5, "successful" : 5, "skipped" : 0, "failed" : 0 }, "hits" : { "total" : { "value": 1000, "relation": "eq" }, "max_score" : null, "hits" : [ { "_index" : "bank", "_type" : "_doc", "_id" : "0", "sort": [0], "_score" : null, "_source" : {"account_number":0,"balance":16623,"firstname":"Bradshaw","lastname":"Mckenzie","age":29,"gender":"F","address":"244 Columbus Place","employer":"Euron","email":"bradshawmckenzie@euron.com","city":"Hobucken","state":"CO"} }, { "_index" : "bank", "_type" : "_doc", "_id" : "1", "sort": [1], "_score" : null, "_source" : {"account_number":1,"balance":39225,"firstname":"Amber","lastname":"Duke","age":32,"gender":"M","address":"880 Holmes Lane","employer":"Pyrami","email":"amberduke@pyrami.com","city":"Brogan","state":"IL"} }, ... ] }}复制代码
关于回应,咱们能够看到:
took
Elasticsearch执行搜索所用的时间(以毫秒为单位)
timed_out
告诉咱们搜索是否超时
_shards
告诉咱们搜索了多少碎片,以及成功/失败搜索碎片的计数
hits
搜索结果
hits.total
包含与搜索条件匹配的文档总数相关的信息的对象
hits.total.value
总命中数的值。
hits.total.relation
:hits.total.value
值是准确的命中次数,在这种状况下它等于eq
或总命中次数的下界(大于或等于),在这种状况下它等于gte
。
hits.hits
实际的搜索结果数组(默认为前10个文档)
hits.sort
结果排序键(若是按分数排序,则丢失)
hits._score
和 max_score
——暂时忽略这些字段
hits.total
的准确度是由请求参数track_total_hits
控制,当track_total_hits
设置为true时,请求将精确地跟踪总命中“relation”:“eq”
。默认值为10,000,这意味着总命中数能够精确地跟踪到10,000个文档。经过显式地将track_total_hits
设置为true,能够强制进行准确的计数。有关详细信息,后面章节咱们会进行介绍。
这是使用请求体搜索的方式:
curl -X GET "localhost:9200/bank/_search" -H 'Content-Type: application/json' -d'{ "query": { "match_all": {} }, "sort": [ { "account_number": "asc" } ]}'复制代码
这里的不一样之处在于,咱们没有在URI中传递q=*,而是向_search API提供了json风格的查询请求体。咱们将在下一节中讨论这个JSON查询。
重要的是要了解,一旦您得到了搜索结果,Elasticsearch就会彻底处理请求,而且不会维护任何类型的服务器端资源,也不会在结果中打开游标。这是许多其余平台如SQL造成鲜明对比,你最初可能获得部分的子集查询结果预先而后不断返回到服务器,若是你想获取(或页面)其他的结果使用某种状态的服务器端游标。
Elasticsearch提供了一种JSON风格的查询语言,您可使用它来执行查询。这称为Query DSL。查询语言很是全面,乍一看可能有些吓人,但实际上学习它的最佳方法是从几个基本示例开始。
回到上一个例子,咱们执行了这个查询:
curl -X GET "localhost:9200/bank/_search" -H 'Content-Type: application/json' -d'{ "query": { "match_all": {} }}'复制代码
仔细分析上面的内容,query
部分告诉咱们进行查询操做,match_all
只是咱们想要运行的查询类型,match_all只是搜索指定索引中的全部文档。
除了查询参数,咱们还能够传递其余参数来影响搜索结果。在上一小节的最后,咱们传入了sort,这里咱们传入了size:
curl -X GET "localhost:9200/bank/_search" -H 'Content-Type: application/json' -d'{ "query": { "match_all": {} }, "size": 1}'复制代码
请注意,若是未指定大小,则默认为10。
下面的例子执行match_all
并返回文档10到19(from和size能够类比mysql中的limit ? ?):
curl -X GET "localhost:9200/bank/_search" -H 'Content-Type: application/json' -d'{ "query": { "match_all": {} }, "from": 10, "size": 10}'复制代码
from参数(基于0)指定从哪一个文档索引开始,size参数指定从from参数开始返回多少文档。该特性在实现搜索结果分页时很是有用。
注意,若是没有指定from,则默认值为0。
本这个例子执行match_all
操做,并按账户余额降序对结果进行排序,并返回前10个(默认大小)文档。
curl -X GET "localhost:9200/bank/_search" -H 'Content-Type: application/json' -d'{ "query": { "match_all": {} }, "sort": { "balance": { "order": "desc" } }}'复制代码
既然咱们已经看到了一些基本的搜索参数,那么让咱们深刻研究一下Query DSL。让咱们先看看返回的文档字段。默认状况下,做为全部搜索的一部分,返回完整的JSON文档。这被称为“源”(搜索命中中的_source
字段)。若是咱们不但愿返回整个源文档,咱们能够只请求从源中返回几个字段。
此示例显示如何从搜索中返回两个字段,即账号和余额(在!source
内):
curl -X GET "localhost:9200/bank/_search" -H 'Content-Type: application/json' -d'{ "query": { "match_all": {} }, "_source": ["account_number", "balance"]}'复制代码
注意,上面的示例只减小了_source
_字段。它仍然只返回一个名为_source
的字段,可是其中只包含account_number和balance字段。
若是您以前有了解过MySql,那么上面的内容在概念上与SQL SELECT from field list有些相似。
如今让咱们进入查询部分。在前面,咱们已经了解了如何使用match_all
查询来匹配全部文档。如今让咱们引入一个名为match
查询的新查询,它能够被看做是基本的字段搜索查询(即针对特定字段或字段集进行的搜索)。
本例返回编号为20的账户
类比mysql match相似于mysql 中的条件查询。
例如返回编号为20的账户:
curl -X GET "localhost:9200/bank/_search" -H 'Content-Type: application/json' -d'{ "query": { "match": { "account_number": 20 } }}'复制代码
此示例返回地址中包含“mill”的全部账户:
curl -X GET "localhost:9200/bank/_search" -H 'Content-Type: application/json' -d'{ "query": { "match": { "address": "mill" } }}'复制代码
此示例返回地址中包含“mill”或“lane”的全部账户:
curl -X GET "localhost:9200/bank/_search" -H 'Content-Type: application/json' -d'{ "query": { "match": { "address": "mill lane" } }}'复制代码
match (match_phrase)的一个变体,它返回地址中包含短语“mill lane”的全部账户:
curl -X GET "localhost:9200/bank/_search" -H 'Content-Type: application/json' -d'{ "query": { "match_phrase": { "address": "mill lane" } }}'复制代码
注意:match 中若是加空格,那么会被认为两个单词,包含任意一个单词将被查询到
match_parase 将忽略空格,将该字符认为一个总体,会在索引中匹配包含这个总体的文档。
如今让咱们介绍bool查询。bool查询容许咱们使用布尔逻辑将较小的查询组合成较大的查询。
若是您熟悉mysql,那么你就会发现布尔查询其实至关于 and or not...
这个例子包含两个匹配查询,返回地址中包含“mill”和“lane”的全部账户:
curl -X GET "localhost:9200/bank/_search" -H 'Content-Type: application/json' -d'{ "query": { "bool": { "must": [ { "match": { "address": "mill" } }, { "match": { "address": "lane" } } ] } }}'复制代码
在上面的示例中,bool must子句指定了全部必须为true的查询,则将文档视为匹配。
相反,这个例子包含两个匹配查询,并返回地址中包含“mill”或“lane”的全部账户:
curl -X GET "localhost:9200/bank/_search" -H 'Content-Type: application/json' -d'{ "query": { "bool": { "should": [ { "match": { "address": "mill" } }, { "match": { "address": "lane" } } ] } }}'复制代码
在上面的示例中,bool should子句指定了一个查询列表,其中任何一个查询必须为真,才能将文档视为匹配。
这个例子包含两个匹配查询,返回地址中既不包含“mill”也不包含“lane”的全部账户:
curl -X GET "localhost:9200/bank/_search" -H 'Content-Type: application/json' -d'{ "query": { "bool": { "must_not": [ { "match": { "address": "mill" } }, { "match": { "address": "lane" } } ] } }}'复制代码
在上面的例子中,bool must_not子句指定了一个查询列表,其中没有一个查询必须为真,才能将文档视为匹配。
咱们能够在bool查询中同时组合must、should和must_not子句。此外,咱们能够在这些bool子句中组合bool查询,以模拟任何复杂的多级布尔逻辑。
这个例子返回全部40岁但不居住在ID(aho)的人的帐户:
curl -X GET "localhost:9200/bank/_search" -H 'Content-Type: application/json' -d'{ "query": { "bool": { "must": [ { "match": { "age": "40" } } ], "must_not": [ { "match": { "state": "ID" } } ] } }}'复制代码
在上一节中,咱们跳过了一个名为document score(搜索结果中的_score字段)的小细节。分数是一个数值,它是衡量文档与咱们指定的搜索查询匹配程度的一个相对指标。分数越高,文档越相关,分数越低,文档越不相关。
可是查询并不老是须要生成分数,特别是当它们只用于“过滤”文档集时。Elasticsearch会自动优化查询执行,以免计算无用的分数。
咱们在上一节中介绍的bool查询还支持filter子句,它容许咱们使用查询来限制将由其余子句匹配的文档,而不改变计算分数的方式。做为一个示例,让咱们介绍范围查询,它容许咱们根据一系列值筛选文档。这一般用于数字或日期筛选。
本例使用bool查询返回余额在20000到30000之间的全部账户,包括余额。换句话说,咱们但愿找到余额大于或等于20000,小于或等于30000的帐户。
curl -X GET "localhost:9200/bank/_search" -H 'Content-Type: application/json' -d'{ "query": { "bool": { "must": { "match_all": {} }, "filter": { "range": { "balance": { "gte": 20000, "lte": 30000 } } } } }}'复制代码
经过分析上面的内容,bool查询包含一个match_all
查询(查询部分)和一个range
查询(筛选部分)。咱们能够将任何其余查询替换到查询和筛选器部分中。在上面的例子中,范围查询很是有意义,由于落入范围的文档都“相等”匹配,没有文档比有更有意义(由于是筛选过的)。
除了match_all、match、bool和range
查询以外,还有许多其余可用的查询类型,咱们在这里不深刻讨论它们。既然咱们已经对它们的工做原理有了基本的了解,那么在学习和试验其余查询类型时应用这些知识应该不会太难。
聚合提供了对数据进行分组和提取统计信息的能力。考虑聚合最简单的方法是大体将其等同于SQL GROUP by和SQL聚合函数。在Elasticsearch中,您能够执行返回命中的搜索,同时在一个响应中返回与全部命中分离的聚合结果。这是很是强大和高效的,由于您能够运行查询和多个聚合,并一次性得到这两个(或任何一个)操做的结果,从而避免使用简洁和简化的API进行网络往返。
首先,这个示例按状态对全部账户进行分组,而后返回按count降序排列的前10个(默认)状态(也是默认):
curl -X GET "localhost:9200/bank/_search" -H 'Content-Type: application/json' -d'{ "size": 0, "aggs": { "group_by_state": { "terms": { "field": "state.keyword" } } }}'复制代码
在SQL中,上述聚合在概念上与:
SELECT state, COUNT(*) FROM bank GROUP BY state ORDER BY COUNT(*) DESC LIMIT 10;复制代码
{ "took": 29, "timed_out": false, "_shards": { "total": 5, "successful": 5, "skipped" : 0, "failed": 0 }, "hits" : { "total" : { "value": 1000, "relation": "eq" }, "max_score" : null, "hits" : [ ] }, "aggregations" : { "group_by_state" : { "doc_count_error_upper_bound": 20, "sum_other_doc_count": 770, "buckets" : [ { "key" : "ID", "doc_count" : 27 }, { "key" : "TX", "doc_count" : 27 }, { "key" : "AL", "doc_count" : 25 }, { "key" : "MD", "doc_count" : 25 }, { "key" : "TN", "doc_count" : 23 }, { "key" : "MA", "doc_count" : 21 }, { "key" : "NC", "doc_count" : 21 }, { "key" : "ND", "doc_count" : 21 }, { "key" : "ME", "doc_count" : 20 }, { "key" : "MO", "doc_count" : 20 } ] } }}复制代码
咱们能够看到ID(Idaho)有27个账户,其次是TX(Texas)的27个账户,而后是AL(Alabama)的25个账户,依此类推。
注意,咱们将size=0设置为不显示搜索结果,由于咱们只想看到响应中的聚合结果。
基于前面的汇总,本示例按状态计算平均账户余额(一样只针对按count降序排列的前10个状态):
curl -X GET "localhost:9200/bank/_search" -H 'Content-Type: application/json' -d'{ "size": 0, "aggs": { "group_by_state": { "terms": { "field": "state.keyword" }, "aggs": { "average_balance": { "avg": { "field": "balance" } } } } }}'复制代码
注意,咱们如何将average_balance聚合嵌套在group_by_state聚合中。这是全部聚合的常见模式。您能够在聚合中任意嵌套聚合,以从数据中提取所需的结果。
基于以前的聚合,咱们如今按降序对平均余额排序:
curl -X GET "localhost:9200/bank/_search" -H 'Content-Type: application/json' -d'{ "size": 0, "aggs": { "group_by_state": { "terms": { "field": "state.keyword", "order": { "average_balance": "desc" } }, "aggs": { "average_balance": { "avg": { "field": "balance" } } } } }}'复制代码
这个例子展现了咱们如何按照年龄等级(20-29岁,30-39岁,40-49岁)分组,而后按性别分组,最后获得每一个年龄等级,每一个性别的平均帐户余额:
curl -X GET "localhost:9200/bank/_search" -H 'Content-Type: application/json' -d'{ "size": 0, "aggs": { "group_by_age": { "range": { "field": "age", "ranges": [ { "from": 20, "to": 30 }, { "from": 30, "to": 40 }, { "from": 40, "to": 50 } ] }, "aggs": { "group_by_gender": { "terms": { "field": "gender.keyword" }, "aggs": { "average_balance": { "avg": { "field": "balance" } } } } } } }}'复制代码
还有许多其余聚合功能,咱们在这里不会详细讨论。若是您想作进一步的实验,那么聚合参考指南是一个很好的开始。
弹性搜索既是一个简单的产品,也是一个复杂的产品。到目前为止,咱们已经了解了它是什么、如何查看它的内部以及如何使用一些RESTapi来使用它。但愿本教程能让您更好地理解Elasticsearch是什么,更重要的是,它激发了您进一步试验它的其余优秀特性!