Elasticsearch入门之HTTP基础操作

RESTful

REST 指的是一组架构约束条件和原则。满足这些约束条件和原则的应用程序或设计就是 RESTful。Web 应用程序最重要的 REST 原则是，客户端和服务器之间的交互在请求之间是无状态的。从客户端到服务器的每个请求都必须包含理解请求所必需的信息。如果服务器在请求之间的任何时间点重启，客户端不会得到通知。此外，无状态请求可以由任何可用服务器回答，这十分适合云计算之类的环境。客户端可以缓存数据以改进性能。

在服务器端，应用程序状态和功能可以分为各种资源。资源是一个有趣的概念实体，它向客户端公开。资源的例子有：应用程序对象、数据库记录、算法等等。每个资源都使用 URI (Universal Resource Identifier) 得到一个唯一的地址。所有资源都共享统一的接口，以便在客户端和服务器之间传输状态。使用的是标准的 HTTP 方法，比如 GET、PUT、POST 和DELETE。

在 REST 样式的 Web 服务中，每个资源都有一个地址。资源本身都是方法调用的目标，方法列表对所有资源都是一样的。这些方法都是标准方法，包括 HTTP GET、POST、PUT、DELETE，还可能包括 HEAD 和 OPTIONS。简单的理解就是，如果想要访问互联网上的资源，就必须向资源所在的服务器发出请求，请求体中必须包含资源的网络路径，以及对资源进行的操作(增删改查)。

客户端安装

如果直接通过浏览器向 Elasticsearch 服务器发请求，那么需要在发送的请求中包含HTTP 标准的方法，而 HTTP 的大部分特性且仅支持 GET 和 POST 方法。所以为了能方便地进行客户端的访问，可以使用 Postman 软件。

Postman 是一款强大的网页调试工具，提供功能强大的 Web API 和 HTTP 请求调试。软件功能强大，界面简洁明晰、操作方便快捷，设计得很人性化。Postman 中文版能够发送任何类型的 HTTP 请求 (GET, HEAD, POST, PUT...)，不仅能够表单提交，且可以附带任意类型请求体。

Postman 官网：https://www.getpostman.com

Postman 下载：https://www.getpostman.com/apps

详细postman基础操作可以参考这篇博客。

数据格式

Elasticsearch 是面向文档型数据库，一条数据在这里就是一个文档。为了方便大家理解，我们将 Elasticsearch 里存储文档数据和关系型数据库 MySQL 存储数据的概念进行一个类比：

ES 里的 Index 可以看做一个库，而 Types 相当于表，Documents 则相当于表的行。这里 Types 的概念已经被逐渐弱化，Elasticsearch 6.X 中，一个 index 下已经只能包含一个type，Elasticsearch 7.X 中, Type 的概念已经被删除了。

所以注意了，Elasticsearch 7.X之后，索引就相当于是表了。新手此时就不要有任何库的概念了，也不要有type的概念了。

因此我们的对比图真实的情况变成：

有的人可能还会继续执着数据库去哪了？mysql是有数据库的啊，你非要完全对比，就把es集群类比未mysql数据库吧。

HTTP操作

也就是所有对"表"，"字段"的操作都是通过发送一些http协议进行的。

索引操作（"表"）

1. 创建索引

对比关系型数据库，创建索引就等同于创建表，比如要我们创建一个shopping索引：

在 Postman 中，向 ES 服务器发 PUT 请求 ：http://127.0.0.1:9200/shopping

请求后，服务器返回响应

{
 "acknowledged"【响应结果】: true, # true 操作成功
 "shards_acknowledged"【分片结果】: true, # 分片操作成功
 "index"【索引名称】: "shopping"
}
# 注意：创建索引库的分片数默认 1 片，在 7.0.0 之前的 Elasticsearch 版本中，默认 5 片

如果重复添加索引，会返回错误信息，这个也能理解，就像你重复创建相同的mysql表一样，也是不被允许的。

2. 查看所有索引

这就像我们经常要看看mysql中有哪些数据库show tables一样，有时候也得看看es中究竟有哪些索引。

在 Postman 中，向 ES 服务器发 GET 请求 ：http://127.0.0.1:9200/_cat/indices?v

这里请求路径中的_cat 表示查看的意思，indices 表示索引，所以整体含义就是查看当前 ES服务器中的所有索引。

3. 查看单个索引

在 Postman 中，向 ES 服务器发 GET 请求 ：http://127.0.0.1:9200/shopping

查看索引向 ES 服务器发送的请求路径和创建索引是一致的。但是 HTTP 方法不一致。这里

可以体会一下 RESTful 的意义，

请求后，服务器响应结果如下：

{
 "shopping"【索引名】: { 
 "aliases"【别名】: {},
 "mappings"【映射】: {},
 "settings"【设置】: {
 "index"【设置 - 索引】: {
 "creation_date"【设置 - 索引 - 创建时间】: "1614265373911",
 "number_of_shards"【设置 - 索引 - 主分片数量】: "1",
 "number_of_replicas"【设置 - 索引 - 副分片数量】: "1",
 "uuid"【设置 - 索引 - 唯一标识】: "eI5wemRERTumxGCc1bAk2A",
 "version"【设置 - 索引 - 版本】: {
 "created": "7080099"
 },
 "provided_name"【设置 - 索引 - 名称】: "shopping"
 }
 }
 }
}

初学者姑且理解成这玩意就是看看某个表到底存不存在。

4. 删除索引

我们mysql中有创建表，肯定就得有删除表的操作，es也是如此。

在 Postman 中，向 ES 服务器发 DELETE 请求 ：http://127.0.0.1:9200/shopping

重新访问索引时，服务器返回响应：索引不存在，你都把"表"删了，肯定不存在了。

文档操作（对数据库的行操作）

1. 创建文档（往表中插入数据）

索引已经创建好了，接下来我们来创建文档，并添加数据。这里的文档可以类比为关系型数据库中的表数据，添加的数据格式为 JSON 格式，先记得把刚才删除shopping索引重新建好。

在 Postman 中，向 ES 服务器发 POST 请求 ：http://127.0.0.1:9200/shopping/_doc

此处发送请求的方式必须为 POST，不能是 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
}

上面的数据创建后，由于没有指定数据唯一性标识（ID），默认情况下，ES 服务器会随机生成 一个，我们mysql一般都是自增id。

如果想要自定义唯一性标识 ，需要在创建时指定：http://127.0.0.1:9200/shopping/_doc/1

此处需要注意：如果增加数据时明确数据主键，那么请求方式也可以为 PUT。

还需要注意：如果写入重复的id，则会覆盖之前的数据。

2. 查看文档（这里演示的是根据唯一标识查询查看对应的一行数据）

查看文档时，可以根据文档的唯一性标识来查看对应的唯一的一条数据，类似于 MySQL 中数据的主键查询（select * from tb where id = 1）

在 Postman 中，向 ES 服务器发 GET 请求 ：http://127.0.0.1:9200/shopping/_doc/1

查询成功后，服务器响应结果：

当然，我们真实查一张mysql表不见得非得根据主键id去查，还有各种查询方式，这个我们后面会讲到，这里演示的就是根据主键查询对应的那一行数据。

{
 "_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
 }
}

这里需要注意，_type文档类型默认就是_doc，甚至在高版本的es中文档类型只能是_doc，也就是我们可以完全忽略这个属性。这样使用起来更加简单方便了。

3. 修改文档（这里演示的是根据唯一标识更新一行所有字段的数据）

和新增文档一样，输入相同的 URL 地址请求，如果请求体变化，会将原有的数据内容覆盖

在 Postman 中，向 ES 服务器发 POST 请求 ：http://127.0.0.1:9200/shopping/_doc/1

请求体内容为:

{
 "title":"华为手机",
 "category":"华为",
 "images":"http://www.gulixueyuan.com/hw.jpg",
 "price":4999.00
}

修改成功后，服务器响应结果：

{
 "_index": "shopping",
 "_type": "_doc",
 "_id": "1",
 "_version"【版本】: 2,
 "result"【结果】: "updated", # updated 表示数据被更新
 "_shards": {
 "total": 2,
 "successful": 1,
 "failed": 0
 },
 "_seq_no": 2,
 "_primary_term": 2
}

上面的操作类似于mysql：

upate table set title = '华为' , category='华为手机', images='http://www.gulixueyuan.com/hw.jpg',
 'price'=4999.00 where id = 1

4. 修改字段（这里演示的是根据唯一标识更新一行指定字段的数据）

修改数据时，也可以只修改某一给条数据的局部信息

在 Postman 中，向 ES 服务器发 POST 请求 ：http://127.0.0.1:9200/shopping/_update/1

请求体内容为：

{ 
 "doc": {
 "price":3000.00
 } 
}

修改成功后，服务器响应结果：

根据唯一性标识，查询文档数据，文档数据已经更新

5. 删除文档（这里演示的是根据唯一标识删除一行数据）

删除一个文档不会立即从磁盘上移除，它只是被标记成已删除（逻辑删除）。

在 Postman 中，向 ES 服务器发 DELETE 请求 ：http://127.0.0.1:9200/shopping/_doc/1

{
 "_index": "shopping",
 "_type": "_doc",
 "_id": "1",
 "_version"【版本】: 4, #对数据的操作，都会更新版本
 "result"【结果】: "deleted", # deleted 表示数据被标记为删除
 "_shards": {
 "total": 2,
 "successful": 1,
 "failed": 0
 },
 "_seq_no": 4,
 "_primary_term": 2
}

删除后再查询当前文档信息

如果删除一个并不存在的文档

{
 "_index": "shopping",
 "_type": "_doc",
 "_id": "1",
 "_version": 1,
 "result"【结果】: "not_found", # not_found 表示未查找到
 "_shards": {
 "total": 2,
 "successful": 1,
 "failed": 0
 },
 "_seq_no": 5,
 "_primary_term": 2
}

6. 条件删除文档

一般删除数据都是根据文档的唯一性标识进行删除，实际操作时，也可以根据条件对多条数据进行删除

首先分别增加多条数据:

{
 "title":"小米手机",
 "category":"小米",
 "images":"http://www.gulixueyuan.com/xm.jpg",
 "price":4000.00
}
{
 "title":"华为手机",
 "category":"华为",
 "images":"http://www.gulixueyuan.com/hw.jpg",
 "price":4000.00
}

向 ES 服务器发 POST 请求 ：http://127.0.0.1:9200/shopping/_delete_by_query

请求体内容为：

{
 "query":{
 "match":{
 "price":4000.00
 }
 }
}

删除成功后，服务器响应结果：

{
 "took"【耗时】: 175,
 "timed_out"【是否超时】: false,
 "total"【总数】: 2,
 "deleted"【删除数量】: 2,
 "batches": 1,
 "version_conflicts": 0,
 "noops": 0,
 "retries": {
 "bulk": 0,
 "search": 0
 },
 "throttled_millis": 0,
 "requests_per_second": -1.0,
 "throttled_until_millis": 0,
 "failures": []
}

映射操作 （相当于mysql的表结构）

有了索引库，等于有了mysql的表了。接下来就需要建索引库(index)中的映射了，类似于数据表（table）中的表结构(schema)。创建数据库表需要设置字段名称，类型，长度，约束等；索引库也一样，需要知道这个类型下有哪些字段，每个字段有哪些约束信息，这就叫做映射(mapping)。

经过上面的练习之后，我们到这可能会有困惑，什么鬼，mysql我需要用create table语句创建表，然后设定字段和类型，es上面我也没有设置这些东西啊，直接创建索引，插入文档不就行了，哪有什么映射啊？这里就得了解一些es的动态映射（这里只需简单了解即可）

Elasticsearch 允许在没有预先定义映射的情况下直接创建索引并插入文档，这是因为 Elasticsearch 支持动态映射（Dynamic Mapping）。当 Elasticsearch 接收到一个新文档时，它会自动检测文档中的字段，并根据内置的规则为这些字段创建映射。这种机制使得数据摄入变得非常灵活和便捷。

（1）动态映射的工作原理

• 自动检测字段类型：当你首次索引一个文档时，Elasticsearch 会检查文档中每个字段的内容，并尝试推断其类型。例如，数字会被识别为 long 或 double，字符串则可能被识别为 text 或 keyword，具体取决于内容。

内置类型检测规则

Elasticsearch 使用内置的类型检测规则来确定每个字段的数据类型。这些规则基于字段内容的格式、结构以及值的范围等信息。
数值型 ：如果字段值为整数或浮点数，Elasticsearch 会将其识别为 long 或 double 类型。例如，42 会被视为 long，而 3.14 则是 double。
布尔型 ：如果字段值为 true 或 false，则该字段被识别为 boolean 类型。
日期型 ：Elasticsearch 尝试将字段值解析为多种常见的日期格式（如 ISO8601）。如果成功，则该字段被识别为 date 类型。你可以配置日期检测器以支持更多自定义格式。
文本型 ：对于字符串，Elasticsearch 默认会创建一个 text 类型，并启用全文搜索分析。此外，还会创建一个子字段作为 keyword 类型 ，用于精确匹配、排序和聚合操作。（文章末尾会用通俗易懂的案例讲解这句话）
对象和数组：当遇到嵌套 JSON 对象或数组时，Elasticsearch 会相应地创建 object 或 nested 类型（取决于配置）以及处理数组中的元素。

• 应用默认配置：对于每个新字段，Elasticsearch 使用默认设置来创建映射。例如，默认情况下，文本字段会被视为 text 类型，并且会被分析（即分词），以便用于全文搜索。如果你希望某些文本字段不被分析（例如用于聚合或排序），你可以稍后将它们更改为 keyword 类型。
• 支持复杂结构：Elasticsearch 还能处理嵌套对象和数组等复杂数据结构，并相应地创建映射。
• 允许后续修改：虽然动态映射可以自动创建，但你可以在任何时候手动更新映射以更好地适应你的需求。不过需要注意的是，一旦某个字段已经被使用，它的映射就不能再更改了（除非重新创建索引）。

（2）动态映射的优点

• 灵活性：无需提前定义所有字段及其类型，即可开始索引数据。
• 快速上手：对于原型开发或小规模项目，动态映射可以显著减少前期配置工作。
• 适应性强：能够自动适应不断变化的数据模式，特别适合于日志分析、监控等应用场景，其中数据格式可能会随时间而演变。

（3）注意事项

尽管动态映射提供了极大的便利性，但也有一些潜在的风险：

• 性能影响：如果映射变得过于复杂或包含大量字段，这可能会影响索引和查询性能。
• 不可预见的行为：自动推断的字段类型可能不符合预期，导致查询结果不如人意。
• 难以管理：随着时间推移，自动生成的映射可能会变得难以理解和维护。
  因此，在生产环境中，建议显式定义映射，特别是对于关键字段，以确保最佳性能和可预测性。通过这种方式，你可以控制哪些字段应该被索引、如何分析文本字段以及是否启用特定功能（如多字段支持）。此外，明确的映射有助于优化存储空间和查询效率。

总之，Elasticsearch 的动态映射特性使得在没有预先定义映射的情况下也能轻松开始索引文档，但它更适合于探索性和临时性的数据分析任务。对于需要稳定性和高性能的应用场景，则推荐采用静态映射。

1. 创建映射

我们先创建一个student索引，然后再创建对应的映射。

在 Postman 中，向 ES 服务器发 PUT 请求 ：http://127.0.0.1:9200/student/_mapping

请求体内容为：

{
 "properties": {
 "name":{
 "type": "text",
 "index": true
 },
 "sex":{
 "type": "text",
 "index": false
 },
 "age":{
 "type": "long",
 "index": false
 }
 }
}

映射数据说明：

• 字段名：任意填写，下面指定许多属性，例如：title、subtitle、images、price
• type：类型，Elasticsearch 中支持的数据类型非常丰富，说几个关键的：
• String 类型，又分两种：
  text：可分词
  keyword：不可分词，数据会作为完整字段进行匹配
• Numerical：数值类型，分两类
  基本数据类型：long、integer、short、byte、double、float、half_float
  浮点数的高精度类型：scaled_float
• Date：日期类型
• Array：数组类型
• Object：对象
• index：是否索引，默认为 true，也就是说你不进行任何配置，所有字段都会被索引。
  true：字段会被索引，则可以用来进行搜索
  false：字段不会被索引，不能用来搜索
• store：是否将数据进行独立存储，默认为 false
  原始的文本会存储在_source 里面，默认情况下其他提取出来的字段都不是独立存储
  的，是从_source 里面提取出来的。当然你也可以独立的存储某个字段，只要设置
  "store": true 即可，获取独立存储的字段要比从_source 中解析快得多，但是也会占用
  更多的空间，所以要根据实际业务需求来设置。
• analyzer：分词器，这里的 ik_max_word 即使用 ik 分词器,后面会有专门的章节学习

2. 查看映射

在 Postman 中，向 ES 服务器发 GET 请求 ：http://127.0.0.1:9200/student/_mapping

我们可以看到这样就可以给指定的索引关联上特定的映射了，后续插入文档都需要遵循这个映射结构。

通俗案例理解动态映射文本类型

当然可以，我来举个更通俗的例子来帮助理解 title.keyword 的用途。

场景：图书馆管理系统

假设你正在开发一个图书馆管理系统的搜索功能，其中有一个 books 索引，每个文档代表一本书，并包含以下字段：

• id: 图书的唯一标识符。
• title: 书名，类型为 text，并且默认包含一个 keyword 子字段 title.keyword。

示例数据

id	title
1	Elasticsearch Guide
2	Learning Elasticsearch
3	Mastering Elasticsearch
4	Elasticsearch Basics

使用场景

1. 全文搜索（使用 title 字段）

当你在搜索框中输入"elasticsearch"，你希望找到所有与 Elasticsearch 相关的书籍。这时你会使用 title 字段进行全文搜索：

GET /books/_search
{
  "query": {
    "match": {
      "title": "elasticsearch"
    }
  }
}

这将返回所有标题中含有"elasticsearch"的书籍，比如"Elasticsearch Guide"、"Learning Elasticsearch"等。

2. 精确匹配、排序和聚合（使用 title.keyword 子字段）

精确匹配

如果你想查找完全匹配特定标题的书籍，例如只想要找到标题正好是"Elasticsearch Guide"的那本书，你应该使用 title.keyword：

GET /books/_search
{
  "query": {
    "match_phrase": {
      "title.keyword": "Elasticsearch Guide"
    }
  }
}

这条查询只会返回 id 为 1 的那一本书，因为它完全匹配了给定的字符串。

排序

如果你想要按照书名的字母顺序对书籍进行排序，你可以使用 title.keyword：

GET /books/_search
{
  "sort": [
    {
      "title.keyword": {
        "order": "asc"
      }
    }
  ]
}

结果会按照书名的字母顺序升序排列，比如：

1. Elasticsearch Basics
2. Elasticsearch Guide
3. Learning Elasticsearch
4. Mastering Elasticsearch

聚合

如果你想统计有多少本书的标题恰好是"Elasticsearch Guide"，你可以使用 title.keyword 进行聚合：

GET /books/_search
{
  "size": 0,
  "aggs": {
    "titles_count": {
      "terms": {
        "field": "title.keyword"
      }
    }
  }
}

这将返回一个桶列表，每个桶表示一个唯一的标题及其出现次数。对于这个例子，"Elasticsearch Guide"应该只有一个条目，因为只有 id 为 1 的书有这个标题。

总结

• title (text)：适合用于全文搜索，能够根据部分关键词匹配到相关文档。
• title.keyword (keyword)：适合用于精确匹配、排序和聚合操作。它确保了原始字符串不被分析，从而支持精确查询、按字母顺序排序以及统计不同值的数量等功能。

通过这种方式，Elasticsearch 提供了灵活的数据处理能力，既支持复杂的全文搜索，又支持基于关键字的精确操作。希望这个例子能帮助你更好地理解 title.keyword 的实际应用。

总结

由于篇幅原因，本篇博客先总结了下面计个http操作：

1. 创建索引（创建表 create table）
2. 查看索引（查看表show tables）
3. 查看单个索引（查看单个表show create table）
4. 删除索引（删除表）
5. 创建文档（插入数据）
6. 根据唯一标识查看文档（根据主键查看一条数据）
7. 根据唯一标识修改文档所有字段值（根据主键修改一条数据）
8. 根据唯一标识修改文档指定字段值（根据主键修改指定字段的值）
9. 根据唯一标识删除文档（根据主键删除对应的一条数据）
10. 条件删除文档（根据条件删除数据）
11. 创建映射（mysql中一般就是创建表，只不过es可以动态生成映射）
12. 查看映射（查看表结构）