ElasticSearch与非关系型数据库

数据库差异

ElasticSearch是一个基于Lucene的搜索服务器，提供了一个分布式多用户能力的全文搜索引擎，基于RESTful web接口。它使用Java开发，并作为Apache许可条款下的开源发布，是当前流行的企业级搜索引擎。

—— 摘自百度百科

对于非关系型数据库不熟悉的，可以了解一下：
【知乎好文】MongoDB 等 NoSQL 与关系型数据库相比，有什么优缺点及适用场景？https://www.zhihu.com/question/20059632

与关系型数据库中表结构不同，文档中可以嵌入数组和子文档，就像程序中的数组和成员变量一样。这是关系型数据库三范式不允许的。但实际中我们经常看到一对多和一对一的数据。比如，一篇博客文章的 Tag 列表作为文章的一部分非常直观，而把 Tag 与文章的从属关系单独放一张表里就不那么自然。再比如，一个订单下面的收货地址，包括省、市、区、街道和门牌，作为一个子文档，与订单的信用卡地址很容易区分开。更方便的是，嵌入的数组和子文档之上可以直接建立索引，比如我可以很快找到所有 Tag 包含 MongoDB 的文章。

其实，我挺喜欢关系型数据库那些理论的，SQL 语言可以很精确地形式化，赏心悦目。然而，三范式强调的「数据没有任何冗余」并不是今天程序员们最关心的问题。他们用着方便不方便才是更重要的问题。

类比关系型数据库

手册上简单的对比图：
Relational DB > Database > Table > Row > Column
Elasticsearch > Index > Type > Document > Field

但其实ES与关系型数据库的设计理念不同，所以与关系型数据库不存在一一对应的关系，阮一峰老师的博客中对ES的基本概念解释的比较清晰：

Index（索引）里面的单条记录称为Document（文档），使用JSON格式表示。同一个Index里面的Document，不要求有相同的结构，但最好保持相同，有利于提高搜索效率。
Document可以分组（Type），比如weather这个Index里面，可以按照城市分组（背景和上海），也可以按气候分组（晴天和雨天）。这种分组就叫做Type，它是虚拟的逻辑分组，用来过滤Document。
⚠️不同的Type应该有相似的结构（schema），举例来说，id字段不能在这个组是字符串，在另一个组是数值。这是与关系型数据库的表的一个区别。性质完全不同的数据（比如products和logs）应该存成两个Index，而不是一个Index里面的两个Type（虽然可以做到）。
– 根据规划，Elastic 6.x版只允许每个Index包含一个Type，7.x版将会彻底移除Type。
https://www.elastic.co/cn/blog/index-type-parent-child-join-now-future-in-elasticsearch

查询DSL

Elasticsearch提供基于JSON的完整查询DSL（域特定语言）来定义查询。将Query DSL视为查询的AST（抽象语法树），由两种类型的子句组成：
叶子查询从句：match、term、range
复合查询从句：bool、dis_max

match

GET /_search
{
   
	"query":{
   
		"match": {
   
			"message": "this that"
		}
	}
}

⚠️这种写法会查询所有message包含this或that的文档，查询辅助还可以添加operator（or/and）、analyzer、lenient（是否忽略错误data-type）
https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-match-query.html
当message的查询词是QUICK！时：
将查询的字符串 QUICK! 传入标准分析器中，输出的结果是单个项 quick 。因为只有一个单词项，所以 match 查询执行的是单个底层 term 查询。
用 term 查询计算每个文档相关度评分 _score ，这是种将 词频（term frequency，即词 quick 在相关文档的 title 字段中出现的频率）和反向文档频率（inverse document frequency，即词 quick 在所有文档的 title 字段中出现的频率），以及字段的长度（即字段越短相关度越高）相结合的计算方式。参见 相关性的介绍 。
https://www