1、document数据格式
面向文档的搜索分析引擎
1、应用系统的数据结构都是面向对象的,复杂的
2、对象数据存储到数据库中,只能拆解开来,变为扁平的多张表,每次查询的时候还得还原回对象格式,相当麻烦
3、ES是面向文档的,文档中存储的数据结构,与面向对象的数据结构是一样的,基于这种文档数据结构,es可以提供复杂的索引,全文检索,分析聚合等功能
4、es的document用json数据格式来表达
2、电商网站商品管理案例:背景介绍
有一个电商网站,需要为其基于ES构建一个后台系统,提供以下功能:
1、对商品信息进行CRUD(增删改查)操作
2、执行简单的结构化查询
3、可以执行简单的全文检索,以及复杂的phrase(短语)检索
4、对于全文检索的结果,可以进行高亮显示
5、对数据进行简单的聚合分析
3、简单的集群管理
- 快速检查集群的健康状况
es提供了一套api,叫做cat api,可以查看es中各种各样的数据 GET /_cat/health?v
如何快速了解集群的健康状况?green、yellow、red?
green:每个索引的primary shard和replica shard都是active状态的
yellow:每个索引的primary shard都是active状态的,但是部分replica shard不是active状态,处于不可用的状态
red:不是所有索引的primary shard都是active状态的,部分索引有数据丢失了
为什么现在会处于一个yellow状态?
我们现在就一个笔记本电脑,就启动了一个es进程,相当于就只有一个node。现在es中有一个index,就是kibana自己内置建立的index。由于默认的配置是给每个index分配5个primary shard和5个replica shard,而且primary shard和replica shard不能在同一台机器上(为了容错)。现在kibana自己建立的index是1个primary shard和1个replica shard。当前就一个node,所以只有1个primary shard被分配了和启动了,但是一个replica shard没有第二台机器去启动。
做一个小实验:此时只要启动第二个es进程,就会在es集群中有2个node,然后那1个replica shard就会自动分配过去,然后cluster status就会变成green状态。
- 快速查看集群中有哪些索引
GET _cat/indices?v
- 简单的索引操作
-
创建
查看索引
-
删除
查看索引
-
4、商品的CRUD操作(document CRUD操作)
- 新增商品:新增文档,建立索引
-
格式
PUT /index/type/id { "json数据" }
-
案例 创建
- es会自动建立index和type,不需要提前创建,而且es默认会对document每个field都建立倒排索引,让其可以被搜索
-
案例 检索
- 格式
GET /index/type/id
- 格式
-
案例 修改商品 替换文档
- 替换方式有一个不好,即使必须带上所有的field,才能去进行信息的修改
- 替换方式有一个不好,即使必须带上所有的field,才能去进行信息的修改
-
案例 修改商品 更新文档
-
-
案例 删除商品 删除文档
-