|
|
|
#ElasticSearch 常用概念和名词解释
|
|
|
|
##ES一些概念
|
|
|
|
>Elasticsearch是一个基于Apache Lucene(TM)的开源搜索引擎。无论在开源还是专有领域，Lucene可以被认为是迄今为止最先进、性能最好的、功能最全的搜索引擎库。
|
|
|
|
但是，Lucene只是一个库。想要使用它，你必须使用Java来作为开发语言并将其直接集成到你的应用中，更糟糕的是，Lucene非常复杂，你需要深入了解检索的相关知识来理解它是如何工作的。
|
|
|
|
Elasticsearch也使用Java开发并使用Lucene作为其核心来实现所有索引和搜索的功能，但是它的目的是通过简单的RESTful API来隐藏Lucene的复杂性，从而让全文搜索变得简单。
|
|
|
|
#
|
|
|
|
>Elasticsearch是面向文档(document oriented)的，这意味着它可以存储整个对象或文档(document)。然而它不仅仅是存储，还会索引(index)每个文档的内容使之可以被搜索。在Elasticsearch中，你可以对文档（而非成行成列的数据）进行索引、搜索、排序、过滤。这种理解数据的方式与以往完全不同，这也是Elasticsearch能够执行复杂的全文搜索的原因之一
|
|
|
|
#
|
|
|
|
>
|
|
|
|
与关系型数据库对比</br>
|
|
|
|
Relational DB -> Databases -> Tables -> Rows -> Columns</br>
|
|
|
|
Elasticsearch -> Indices -> Types -> Documents -> Fields</br>
|
|
|
|
Elasticsearch集群可以包含多个索引(indices)（数据库），每一个索引可以包含多个类型(types)（表），每一个类型包含多个文档(documents)（行），然后每个文档包含多个字段(Fields)（列）
|
|
|
|
#
|
|
|
|
>在Elasticsearch中，每一个字段的数据都是默认被索引的。也就是说，每个字段专门有一个反向索引用于快速检索。而且，与其它数据库不同，它可以在同一个查询中利用所有的这些反向索引，以惊人的速度返回结果。
|
|
|
|
#
|
|
|
|
>我们已经学会了如何使用elasticsearch作为一个简单的NoSQL风格的分布式文件存储器——我们可以将一个JSON文档扔给Elasticsearch，也可以根据ID检索它们。但Elasticsearch真正强大之处在于可以从混乱的数据中找出有意义的信息——从大数据到全面的信息。
|
|
|
|
#
|
|
|
|
>为了方便在全文文本字段中进行这些类型的查询，Elasticsearch首先对文本分析(analyzes)，然后使用结果建立一个倒排索引。
|
|
|
|
#
|
|
|
|
>修改在已存在的数据最简单的方法是重新索引：创建一个新配置好的索引，然后将所有的文档从旧的索引复制到新的上。
|
|
|
|
#
|
|
|
|
>在应用中使用别名而不是索引。然后你就可以在任何时候重建索引。别名的开销很小，应当广泛使用。
|
|
|
|
|
|
|
|
##index
|
|
|
|
>为了将数据添加到Elasticsearch，我们需要索引(index)——一个存储关联数据的地方。实际上，索引只是一个用来指向一个或多个分片(shards)的“逻辑命名空间(logical namespace)”
|
|
|
|
|
|
|
|
>「索引」含义的区分
|
|
|
|
|
|
|
|
>你可能已经注意到索引(index)这个词在Elasticsearch中有着不同的含义，所以有必要在此做一下区分:
|
|
|
|
索引（名词） 如上文所述，一个索引(index)就像是传统关系数据库中的数据库，它是相关文档存储的地方，index的复数是indices 或indexes。
|
|
|
|
索引（动词） 「索引一个文档」表示把一个文档存储到索引（名词）里，以便它可以被检索或者查询。这很像SQL中的INSERT关键字，差别是，如果文档已经存在，新的文档将覆盖旧的文档。
|
|
|
|
倒排索引 传统数据库为特定列增加一个索引，例如B-Tree索引来加速检索。Elasticsearch和Lucene使用一种叫做倒排索引(inverted index)的数据结构来达到相同目的。
|
|
|
|
|
|
|
|
|
|
|
|
#type
|
|
|
|
>在应用中，我们使用对象表示一些“事物”，例如一个用户、一篇博客、一个评论，或者一封邮件。每个对象都属于一个类(class)，这个类定义了属性或与对象关联的数据。user类的对象可能包含姓名、性别、年龄和Email地址。
|
|
|
|
在关系型数据库中，我们经常将相同类的对象存储在一个表里，因为它们有着相同的结构。同理，在Elasticsearch中，我们使用相同类型(type)的文档表示相同的“事物”，因为他们的数据结构也是相同的。+
|
|
|
|
|
|
|
|
>每个类型(type)都有自己的映射(mapping)或者结构定义，就像传统数据库表中的列一样。所有类型下的文档被存储在同一个索引下，但是类型的映射(mapping)会告诉Elasticsearch不同的文档如何被索引。 我们将会在《映射》章节探讨如何定义和管理映射，但是现在我们将依赖Elasticsearch去自动处理数据结构。
|
|
|
|
_type的名字可以是大写或小写，不能包含下划线或逗号。我们将使用blog做为类型名。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
##document
|
|
|
|
>在Elasticsearch中，文档(document)这个术语有着特殊含义。它特指最顶层结构或者根对象(root object)序列化成的JSON数据（以唯一ID标识并存储于Elasticsearch中）。
|
|
|
|
#
|
|
|
|
>文档 ID文档唯一标识由四个元数据字段组成：
|
|
|
|
_id：文档的字符串 ID
|
|
|
|
_type：文档的类型名
|
|
|
|
_index：文档所在的索引
|
|
|
|
_uid：_type 和 _id 连接成的 type#id
|
|
|
|
默认情况下，_uid 是被保存（可取回）和索引（可搜索）的。_type 字段被索引但是没有保存，_id 和_index 字段则既没有索引也没有储存，它们并不是真实存在的。
|
|
|
|
|
|
|
|
|
|
|
|
##shard
|
|
|
|
>一个分片(shard)是一个最小级别“工作单元(worker unit)”现在我们只要知道分片就是一个Lucene实例，并且它本身就是一个完整的搜索引擎。我们的文档存储在分片中，并且在分片中被索引，但是我们的应用程序不会直接与它们通信，取而代之的是，直接与索引通信。</br>
|
|
|
|
>复制分片只是主分片的一个副本，它可以防止硬件故障导致的数据丢失，同时可以提供读请求，比如搜索或者从别的shard取回文档。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
##query
|
|
|
|
>简单搜索
|
|
|
|
>使用DSL语句查询
|
|
|
|
>查询子句就像是搭积木一样，可以合并简单的子句为一个复杂的查询语句，比如：
|
|
|
|
叶子子句(leaf clauses)(比如match子句)用以在将查询字符串与一个字段(或多字段)进行比较
|
|
|
|
复合子句(compound)用以合并其他的子句。例如，bool子句允许你合并其他的合法子句，must，must_not或者should
|
|
|
|
|
|
|
|
|
|
|
|
##Mapping
|
|
|
|
>数据在每个字段中的解释说明<br/>
|
|
|
|
映射(mapping)机制用于进行字段类型确认，将每个字段匹配为一种确定的数据类型(string, number, booleans, date等)。
|
|
|
|
##Analysis
|
|
|
|
>全文是如何处理的可以被搜索的<br/>
|
|
|
|
分析(analysis)机制用于进行全文文本(Full Text)的分词，以建立供搜索用的反向索引。
|
|
|
|
|
|
|
|
##aggregations
|
|
|
|
>Elasticsearch有一个功能叫做聚合(aggregations)，它允许你在数据上生成复杂的分析统计。它很像SQL中的GROUP BY但是功能更强大。
|
|
|
|
|
|
|
|
##match
|
|
|
|
>match 查询
|
|
|
|
match查询是一个标准查询，不管你需要全文本查询还是精确查询基本上都要用到它。
|
|
|
|
如果你使用 match 查询一个全文本字段，它会在真正查询之前用分析器先分析match一下查询字符：
|
|
|
|
{
|
|
|
|
"match": {
|
|
|
|
"tweet": "About Search"
|
|
|
|
}
|
|
|
|
}
|
|
|
|
如果用match下指定了一个确切值，在遇到数字，日期，布尔值或者not_analyzed 的字符串时，它将为你搜索你给定的值：
|
|
|
|
{ "match": { "age": 26 }}
|
|
|
|
{ "match": { "date": "2014-09-01" }}
|
|
|
|
{ "match": { "public": true }}
|
|
|
|
{ "match": { "tag": "full_text" }}
|
|
|
|
提示： 做精确匹配搜索时，你最好用过滤语句，因为过滤语句可以缓存数据。
|
|
|
|
不像我们在《简单搜索》中介绍的字符查询，match查询不可以用类似"+usid:2 +tweet:search"这样的语句。 它只能就指定某个确切字段某个确切的值进行搜索，而你要做的就是为它指定正确的字段名以避免语法错误。
|
|
|
|
|
|
|
|
>multi_match 查询
|
|
|
|
multi_match查询允许你做match查询的基础上同时搜索多个字段：
|
|
|
|
{
|
|
|
|
"multi_match": {
|
|
|
|
"query": "full text search",
|
|
|
|
"fields": [ "title", "body" ]
|
|
|
|
}
|
|
|
|
}
|
|
|
|
。
|
|
|
|
空查询 - {} - 在功能上等同于使用match_all查询子句，正如其名字一样，匹配所有的文档：
|
|
|
|
GET /_search
|
|
|
|
{
|
|
|
|
"query": {
|
|
|
|
"match_all": {}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
例如，你可以使用match查询子句用来找寻在tweet字段中找寻包含elasticsearch的成员：
|
|
|
|
{
|
|
|
|
"match": {
|
|
|
|
"tweet": "elasticsearch"
|
|
|
|
}
|
|
|
|
}
|
|
|
|
完整的查询请求会是这样：
|
|
|
|
GET /_search
|
|
|
|
{
|
|
|
|
"query": {
|
|
|
|
"match": {
|
|
|
|
"tweet": "elasticsearch"
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
>match_all 查询
|
|
|
|
使用match_all 可以查询到所有文档，是没有查询条件下的默认语句。
|
|
|
|
{
|
|
|
|
"match_all": {}
|
|
|
|
}
|
|
|
|
此查询常用于合并过滤条件。 比如说你需要检索所有的邮箱,所有的文档相关性都是相同的，所以得到的_score为1
|
|
|
|
##highlight
|
|
|
|
>很多应用喜欢从每个搜索结果中高亮(highlight)匹配到的关键字，这样用户可以知道为什么这些文档和查询相匹配。
|
|
|
|
|
|
|
|
|
|
|
|
##query和filter的区别
|
|
|
|
>事实上我们可以使用两种结构化语句： 结构化查询（Query DSL）和结构化过滤（Filter DSL）。 查询与过滤语句非常相似，但是它们由于使用目的不同而稍有差异。一条过滤语句会询问每个文档的字段值是否包含着特定值：
|
|
|
|
|
|
|
|
* created 的日期范围是否在 2013 到 2014 ?
|
|
|
|
|
|
|
|
* status 字段中是否包含单词 "published" ?
|
|
|
|
|
|
|
|
* lat_lon 字段中的地理位置与目标点相距是否不超过10km ?
|
|
|
|
|
|
|
|
|
|
|
|
>一条查询语句与过滤语句相似，但问法不同：
|
|
|
|
查询语句会询问每个文档的字段值与特定值的匹配程度如何？
|
|
|
|
查询语句的典型用法是为了找到文档：
|
|
|
|
|
|
|
|
* 查找与 full text search 这个词语最佳匹配的文档
|
|
|
|
|
|
|
|
* 查找包含单词 run ，但是也包含runs, running, jog 或 sprint的文档
|
|
|
|
|
|
|
|
* 同时包含着 quick, brown 和 fox --- 单词间离得越近，该文档的相关性越高
|
|
|
|
|
|
|
|
* 标识着 lucene, search 或 java --- 标识词越多，该文档的相关性越高
|
|
|
|
|
|
|
|
>一条查询语句会计算每个文档与查询语句的相关性，会给出一个相关性评分 _score，并且 按照相关性对匹配到的文档进行排序。 这种评分方式非常适用于一个没有完全配置结果的全文本搜索。
|
|
|
|
性能差异使用过滤语句得到的结果集 -- 一个简单的文档列表，快速匹配运算并存入内存是十分方便的， 每个文档仅需要1个字节。这些缓存的过滤结果集与后续请求的结合使用是非常高效的。
|
|
|
|
1
|
|
|
|
查询语句不仅要查找相匹配的文档，还需要计算每个文档的相关性，所以一般来说查询语句要比 过滤语句更耗时，并且查询结果也不可缓存。
|
|
|
|
幸亏有了倒排索引，一个只匹配少量文档的简单查询语句在百万级文档中的查询效率会与一条经过缓存 的过滤语句旗鼓相当，甚至略占上风。 但是一般情况下，一条经过缓存的过滤查询要远胜一条查询语句的执行效率。
|
|
|
|
过滤语句的目的就是缩小匹配的文档结果集，所以需要仔细检查过滤条件。
|
|
|
|
1
|
|
|
|
什么情况下使用原则上来说，使用查询语句做全文本搜索或其他需要进行相关性评分的时候，剩下的全部用过滤语句
|
|
|
|
|
|
|
|
##sort
|
|
|
|
>当你对一个字段进行排序时，ElasticSearch 需要进入每个匹配到的文档得到相关的值。 倒排索引在用于搜索时是非常卓越的，但却不是理想的排序结构。
|
|
|
|
|
|
|
|
* 当搜索的时候，我们需要用检索词去遍历所有的文档。
|
|
|
|
|
|
|
|
* 当排序的时候，我们需要遍历文档中所有的值，我们需要做反倒序排列操作。
|
|
|
|
>为了提高排序效率，ElasticSearch 会将所有字段的值加载到内存中，这就叫做"数据字段"。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
##bool
|
|
|
|
|
|
|
|
>bool 查询与 bool 过滤相似，用于合并多个查询子句。不同的是，bool 过滤可以直接给出是否匹配成功， 而bool 查询要计算每一个查询子句的 _score （相关性分值）。
|
|
|
|
must:: 查询指定文档一定要被包含。
|
|
|
|
must_not:: 查询指定文档一定不要被包含。
|
|
|
|
should:: 查询指定文档，有则可以为文档相关性加分。
|
|
|
|
以下查询将会找到 title 字段中包含 "how to make millions"，并且 "tag" 字段没有被标为 spam。 如果有标识为 "starred" 或者发布日期为2014年之前，那么这些匹配的文档将比同类网站等级高：
|
|
|
|
{
|
|
|
|
"bool": {
|
|
|
|
"must": { "match": { "title": "how to make millions" }},
|
|
|
|
"must_not": { "match": { "tag": "spam" }},
|
|
|
|
"should": [
|
|
|
|
{ "match": { "tag": "starred" }},
|
|
|
|
{ "range": { "date": { "gte": "2014-01-01" }}}
|
|
|
|
]
|
|
|
|
}
|
|
|
|
}
|
|
|
|
提示： 如果bool 查询下没有must子句，那至少应该有一个should子句。但是 如果有must子句，那么没有should子句也可以进行查询
|
|
|
|
>bool 过滤可以用来合并多个过滤条件查询结果的布尔逻辑，它包含一下操作符：
|
|
|
|
1
|
|
|
|
must :: 多个查询条件的完全匹配,相当于 and。
|
|
|
|
must_not :: 多个查询条件的相反匹配，相当于 not。
|
|
|
|
should :: 至少有一个查询条件匹配, 相当于 or。
|
|
|
|
这些参数可以分别继承一个过滤条件或者一个过滤条件
|
|
|
|
|
|
|
|
##analysis
|
|
|
|
|
|
|
|
>分析(analysis)是这样一个过程：
|
|
|
|
首先，标记化一个文本块为适用于倒排索引单独的词(term)
|
|
|
|
然后标准化这些词为标准形式，提高它们的“可搜索性”或“查全率”
|
|
|
|
##term
|
|
|
|
>term主要用于精确匹配哪些值，比如数字，日期，布尔值或 not_analyzed的字符串(未经分析的文本数据类型)：
|
|
|
|
{ "term": { "age": 26 }}
|
|
|
|
{ "term": { "date": "2014-09-01" }}
|
|
|
|
{ "term": { "public": true }}
|
|
|
|
{ "term": { "tag": "full_text" }}
|
|
|
|
##terms
|
|
|
|
>terms 跟 term 有点类似，但 terms 允许指定多个匹配条件。 如果某个字段指定了多个值，那么文档需要一起去做匹配：
|
|
|
|
{
|
|
|
|
"terms": {
|
|
|
|
"tag": [ "search", "full_text", "nosql" ]
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
##range
|
|
|
|
>range过滤允许我们按照指定范围查找一批数据：
|
|
|
|
{
|
|
|
|
"range": {
|
|
|
|
"age": {
|
|
|
|
"gte": 20,
|
|
|
|
"lt": 30
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
范围操作符包含：
|
|
|
|
gt :: 大于
|
|
|
|
gte:: 大于等于
|
|
|
|
lt :: 小于
|
|
|
|
lte:: 小于等于
|
|
|
|
##hits
|
|
|
|
>响应中最重要的部分是hits，它包含了total字段来表示匹配到的文档总数，hits数组还包含了匹配到的前10条数据。
|
|
|
|
hits数组中的每个结果都包含_index、_type和文档的_id字段，被加入到_source字段中这意味着在搜索结果中我们将可以直接使用全部文档。这不像其他搜索引擎只返回文档ID，需要你单独去获取文档。
|
|
|
|
每个节点都有一个_score字段，这是相关性得分(relevance score)，它衡量了文档与查询的匹配程度。默认的，返回的结果中关联性最大的文档排在首位；这意味着，它是按照_score降序排列的。这种情况下，我们没有指定任何查询，所以所有文档的相关性是一样的，因此所有结果的_score都是取得一个中间值1
|
|
|
|
max_score指的是所有文档匹配查询中_score的最大值。
|
|
|
|
##fresh
|
|
|
|
>在Elesticsearch中，这种写入打开一个新段的轻量级过程，叫做refresh。默认情况下，每个分片每秒自动刷新一次。这就是为什么说Elasticsearch是近实时的搜索了：文档的改动不会立即被搜索，但是会在一秒内可见。 |
...
|
...
|
|
