CYK_byte的博客

因此，一般会将需要进行模糊查询的字段存 Document 中（es 就擅长这个），而其他数据则可以在 Document 中以 id 的形式进行存储. 这样就既可以借助 es 高效的模糊查询能力，也能减少为保证一致性而带来的系统开销. 从 es 中查到数据后，再通过其他表的 id 从数据库中拿数据即可（这点开销，相对于从大量数据的数据库中进行 like 查询，几乎可以忽略）.a）CriteriaQuery：允许创建查询来搜索数据，而不需要了解 Elasticsearch 查询的语法或基础知识。

这个东西就跟 JPA 的使用方式一样，只不过高版本的 SpringData Elasticsearch 没有给 ElasticsearchRepository 接口提供复杂搜索查询，建议还是使用 ElasticsearchTemplate。

微服务 架构的项目上，不同的业务往往会在不同的微服务上，比如 “商品数据管理业务” 和 “商品数据搜索业务” 肯定会在两个不同的微服务上，那么跨微服务的项目就没办法直接操作了.

百度、搜狗、淘宝搜索框自动补全如何实现？从 0 到 1 逐层解析实现！

聚合（aggregations），就是用来对文档数据的统计分析和运算. 就像之前我们学习过的 mysql，也是有聚合功能，比如可以使用 avg 求平均值，max 求最大值等等，并且需要搭配着 group by 分组使用，而 es 也具备类似这些功能，并且更加丰富.比如对酒店数据按照品牌进行一个分组，也就是 bucket 聚合，接着算算不同品牌酒店的价格平均值怎么样，这个时候就需要使用到 度量聚合 了，之后如果还需要按照不同品牌价格的平均值进行排序，那么就需要对度量结果再次聚合了.

在搜索框中输入 “如家酒店”，之后点击搜索，可以看到发送了如下请求，参数如下调到请求头可以看到，请求的格式为 JSON，如下图那么需求就是当用户点击搜索框后，后端进行处理，然后返回搜索到的数据总数，以及酒店数据列表（返回格式为 JSON）.定义实体类，用于接收前端请求以及返回响应.请求实体类如下：响应实体类如下：Controller 这边负责接收前端传入的 JSON 参数，然后调用接口 IHotelService 的 search 方法.IHotelService 接口如下： 将 E

全文检索的 match 和 multi_match 查询和前面演示的 match_all 调用的 API 基本一致，差别就是查询条件，也就是 query 部分（通过 QueryBuilders 构建的条件不一样）.DSL 语句的构建是通过 HighLevelRestClient 中的 Resource 实现的，其中包含了 查询、排序】分页、高亮等所有功能.其中 query 表示查询的意思，他的查询条件的是由 QueryBuilders 的工具类提供的，包含了各种查询方法.range 查询也是如此.

你在淘宝里买东西的时候，要通过一些信息进行筛选，比如 销量、信誉、价格升序... 这些词一般都是固定一个按钮，点击就会帮你做筛选.

这里我将以一个 酒店 demo 工程来演示 JavaRestClient 的操作.`id` bigint(20) NOT NULL COMMENT '酒店id',`name` varchar(255) NOT NULL COMMENT '酒店名称；例：7天酒店',`address` varchar(255) NOT NULL COMMENT '酒店地址；例：航头路',`price` int(10) NOT NULL COMMENT '酒店价格；例：329',

如果是 PUT 的是存在的字段呢，比如 age，将 type 改为 keyword，他就会告诉你 mapper 中 integer 类型不可以修改成 keyword.ES 中通过 Restful 请求操作索引库、文档. 请求的内容用 DSL 语句来表示.实际上，这里 es 的处理方式，就是按照 “删除旧文档，新增新文档” 的操作来修改文档的.这里就类似于 mysql 中向表中添加数据一样，需要先创建表，后向添加数据.文档操作也是如此，需要先创建索引库，然后才能添加文档.修改 info 字段的值，如下。

这里为了 es 和 将来要下载的 kibana 进行互联，因此需要我们去创建一个网络.Ps：这里也可以使用 docker-compose 一键互联，但是考虑到未来可能不会使用 kibana（可替代组件，前面的章节讲过），只需要 es，所以这里我们还是单独部署.

比如我们的用户做一个商品订单的搜索，因为 es 的搜索能力更强，所以这里使用 es 进行搜索，那么也意味着，es 这边也要有数据，那怎么确保两边都有数据呢？elasticsearch 是面向文档存储的，可以是数据库中的一条商品数据，也可以是订单数据... 这些东西都会被序列化成 json 的格式，存储在 es 中.这里的映射就是对文档字段的约束，比如你的字段名字是什么，数据类型是字符串，还是数字啊. 这就类似于 mysql 中的约束一样.这就相当于是 MySQL 中的表一样，而文档就是表中的每一行数据.

第一次是根据用户输入的内容的词条，去找到对应的文档 id.第二次是拿着文档 id 来找文档.这样的查询效率，相比于正向索引中搜索 包含手机关键字的 数据，一行一行去查找就要快的多了.倒那么这里也能够看出，排索索引为什么是倒排了，因为正向索引中，得一行一行找，找到匹配的放到结果集中，而倒排索引就是反过来，基于词条创建索引，搜多的时候，就是根据词找到对应的文档（正向索引就是根据文档来找词）.