Elasticsearch - 搜索引擎入门

Elasticsearch是一个分布式可扩展的实时搜索和分析引擎。它能帮助你搜索、分析和浏览数据，而往往大家并没有在某个项目一开始就预料到需要这些功能。Elasticsearch之所以出现就是为了重新赋予硬盘中看似无用的原始数据新的活力。

Elasticsearch每一个独立的部分都不是新创的。比如全文搜索早就已经被实现，统计系统和分布式数据库也早已存在。但是革命之处在于能将这些

独立的功能结合成一个连贯、实时处理的整体。对于新用户，它的门槛也很低，当然他也会因为你的强大而变得更强大。

很不幸的是，目前的大部分数据库在提取数据方面都是非常的薄弱的。虽然它们可以通过精准的时间戳或者确切的数值来进行内容的筛选，但是它们可

以在全文搜索时做到同义词或者相关性搜索吗？他们可以汇总相同内容数据吗？最重要的是，每对如此巨大的数据量，它们能做到实时处理吗？

在Elasticsearch中，每一个字段都会默认被建立索引。也就是说，每一个字段都会有一个反向索引以便快速搜索。而且，与大多数其他数据库不同的是

ES可以在同一个查询中使用所有的反向索引，以惊人的速度返回查询结果。这便是Elasticsearch如此突出的理由：Elasticsearch可以帮助你浏览并利用已经快

要烂在数据库里的那些极难查询的数据。

了解搜索

Elasticsearch是一个建立在全文搜索引擎Apache Lucene(TM)基础上的搜索引擎，可以说Lucene是当今最先进，最高效的全功能开源搜索引擎框架。但是Lucene只是一个框架，要充分利用它的功能，你需要使用JAVA，并且在你的程序中集成Lucene。更糟的是，你需要做很多的学习了解，才能明白它是如何运行的，Lucene确实非常复杂。

Elasticsearch使用Lucene作为内部引擎，但是在你使用它做全文搜索时，只需要使用统一开发好的API即可，而不需要了解其背后复杂的Lucene的运行原理。当然Elasticsearch并不仅仅是Lucene这么简单，它不但包括了全文搜索功能，还可以进行以下工作：
分布式实时文件存储，并将每一个字段都编入索引，使其可以被搜索。
实时分析的分布式搜索引擎。
可以扩展到上百台服务器，处理PB级别的结构化或非结构化数据。

这么多的功能被集成到一台服务器上，你可以轻松地通过客户端或者任何你喜欢的程序语言与ES的RESTful API进行交流，默认端口为9200，可以在配置文件中修改。

面向文档

程序中的对象很少是单纯的键值与数值的列表。更多的时候它拥有一个复杂的结构，比如包含了日期、地理位置、对象、数组等。
迟早你会把这些对象存储在数据库中。你会试图将这些丰富而又庞大的数据都放到一个由行与列组成的关系数据库中，然后你不得不根据每个字段的格式来调整数据，然后每次重建它你都要检索一遍数据。

Elasticsearch是面向文档型数据库，这意味着它存储的是整个对象或者文档，它不但会存储它们，还会为他们建立索引，这样你就可以搜索他们了。你可以在Elasticsearch中索引、搜索、排序和过滤这些文档。不需要成行成列的数据。这将会是完全不同的一种面对数据的思考方式，这也是为什么Elasticsearch可以执行复杂的全文搜索的原因。

Elasticsearch使用JSON (或称作JavaScript Object Notation )作为文档序列化的格式。JSON已经被大多数语言支持，也成为NoSQL领域的一个标准格式。它简单、简洁、易于阅读。在Elasticsearch中，将对象转换为JSON并作为索引要比在表结构中做相同的事情简单多了。

     ES可以通过curl以get post delete等方式进行数据操作，或者通过match匹配、filter过滤器、range范围查询、布尔查询、aggregations（取代facet）聚合等方式，官方网站（https://www.elastic.co/guide/index.html）有丰富的查询示例。同样，它支持bulk api批量查询，减少网络往返。

Elasticsearch中涉及到的重要概念

Elasticsearch有几个核心概念。从一开始理解这些概念会对整个学习过程有莫大的帮助。

（1） 接近实时（NRT） 
Elasticsearch是一个接近实时的搜索平台。这意味着，从索引一个文档直到这个文档能够被搜索到有一个轻微的延迟（通常是1秒）。

（2） 集群（cluster） 
一个集群就是由一个或多个节点组织在一起，它们共同持有你整个的数据，并一起提供索引和搜索功能。一个集群由一个唯一的名字标识，这个名字默认就是“elasticsearch”。这个名字是重要的，因为一个节点只能通过指定某个集群的名字，来加入这个集群。在产品环境中显式地设定这个名字是一个好习惯，但是使用默认值来进行测试/开发也是不错的。

（3） 节点（node） 
一个节点是你集群中的一个服务器，作为集群的一部分，它存储你的数据，参与集群的索引和搜索功能。和集群类似，一个节点也是由一个名字来标识的，默认情况下，这个名字是一个随机的漫威漫画角色的名字，这个名字会在启动的时候赋予节点。这个名字对于管理工作来说挺重要的，因为在这个管理过程中，你会去确定网络中的哪些服务器对应于Elasticsearch集群中的哪些节点。

一个节点可以通过配置集群名称的方式来加入一个指定的集群。默认情况下，每个节点都会被安排加入到一个叫做“elasticsearch”的集群中，这意味着，如果你在你的网络中启动了若干个节点，并假定它们能够相互发现彼此，它们将会自动地形成并加入到一个叫做“elasticsearch”的集群中。

在一个集群里，只要你想，可以拥有任意多个节点。而且，如果当前你的网络中没有运行任何Elasticsearch节点，这时启动一个节点，会默认创建并加入一个叫做“elasticsearch”的集群。

（4） 索引（index） 
一个索引就是一个拥有几分相似特征的文档的集合。比如说，你可以有一个客户数据的索引，另一个产品目录的索引，还有一个订单数据的索引。一个索引由一个名字来标识（必须全部是小写字母的），并且当我们要对对应于这个索引中的文档进行索引、搜索、更新和删除的时候，都要使用到这个名字。索引类似于关系型数据库中Database的概念。在一个集群中，如果你想，可以定义任意多的索引。

（5） 类型（type） 
在一个索引中，你可以定义一种或多种类型。一个类型是你的索引的一个逻辑上的分类/分区，其语义完全由你来定。通常，会为具有一组共同字段的文档定义一个类型。比如说，我们假设你运营一个博客平台并且将你所有的数据存储到一个索引中。在这个索引中，你可以为用户数据定义一个类型，为博客数据定义另一个类型，当然，也可以为评论数据定义另一个类型。类型类似于关系型数据库中Table的概念。

（6）文档（document） 
一个文档是一个可被索引的基础信息单元。比如，你可以拥有某一个客户的文档，某一个产品的一个文档，当然，也可以拥有某个订单的一个文档。文档以JSON（Javascript Object Notation）格式来表示，而JSON是一个到处存在的互联网数据交互格式。 
在一个index/type里面，只要你想，你可以存储任意多的文档。注意，尽管一个文档，物理上存在于一个索引之中，文档必须被索引/赋予一个索引的type。文档类似于关系型数据库中Record的概念。实际上一个文档除了用户定义的数据外，还包括_index、_type和_id字段。

（7） 分片和复制（shards & replicas） 
一个索引可以存储超出单个结点硬件限制的大量数据。比如，一个具有10亿文档的索引占据1TB的磁盘空间，而任一节点都没有这样大的磁盘空间；或者单个节点处理搜索请求，响应太慢。

为了解决这个问题，Elasticsearch提供了将索引划分成多份的能力，这些份就叫做分片。当你创建一个索引的时候，你可以指定你想要的分片的数量。每个分片本身也是一个功能完善并且独立的“索引”，这个“索引”可以被放置到集群中的任何节点上。 
分片之所以重要，主要有两方面的原因：

• 允许你水平分割/扩展你的内容容量
• 允许你在分片（潜在地，位于多个节点上）之上进行分布式的、并行的操作，进而提高性能/吞吐量

至于一个分片怎样分布，它的文档怎样聚合回搜索请求，是完全由Elasticsearch管理的，对于作为用户的你来说，这些都是透明的。

在一个网络/云的环境里，失败随时都可能发生，在某个分片/节点不知怎么的就处于离线状态，或者由于任何原因消失了。这种情况下，有一个故障转移机制是非常有用并且是强烈推荐的。为此目的，Elasticsearch允许你创建分片的一份或多份拷贝，这些拷贝叫做复制分片，或者直接叫复制。复制之所以重要，主要有两方面的原因：

• 在分片/节点失败的情况下，提供了高可用性。因为这个原因，注意到复制分片从不与原/主要（original/primary）分片置于同一节点上是非常重要的。
• 扩展你的搜索量/吞吐量，因为搜索可以在所有的复制上并行运行

基本搜索请求格式

[php]  view plain  copy

1. Method /{index}/{type}/{id}  
2. {  
3. "field": "value",  
4. ...  
5. }  

HEAD方法可以用来检查文档是否存在，加上-i参数获取反馈头文件。另外，在查询字符串中带上pretty参数，Elasticsearch就可以得到优美打印的更加易于识别的JSON结果。 _source 字段不会执行优美打印，它的样子取决于我们录入的样子。

全文搜索

一项在传统数据库很难实现的功能。 我们将会搜索所有喜欢rock climbing的员工：

[php]  view plain  copy

1. GET /megacorp/employee/_search  
2. {  
3.     "query" : {  
4.     "match" : {  
5.     "about" : "rock climbing"  
6.     }  
7.     }  
8. }  

你会发现我们同样使用了 match 查询来搜索 about 字段中的rock climbing。我们会得到两个匹配的文档：

[php]  view plain  copy

1. {  
2. ...  
3. "hits": {  
4. "total": 2,  
5. "max_score": 0.16273327,  
6. "hits": [  
7.     {  
8.     ...  
9.     "_score": 0.16273327, <1>  
10.     "_source": {  
11.     "first_name": "John",  
12.     "last_name": "Smith",  
13.     "age": 25,  
14.     "about": "I love to go rock climbing",  
15.     "interests": [ "sports", "music" ]  
16.     }  
17.     },  
18.     {  
19.     ...  
20.     "_score": 0.016878016, <1>  
21.     "_source": {  
22.     "first_name": "Jane",  
23.     "last_name": "Smith",  
24.     "age": 32,  
25.     "about": "I like to collect rock albums",  
26.     "interests": [ "music" ]  
27.     }  
28.     }  
29.     ]  
30.     }  
31.     }  

相关性评分
通常情况下，Elasticsearch会通过相关性来排列顺序，第一个结果中，John Smith的 about 字段中明确地写到rock climbing。而在Jane Smith的 about 字段中，提及到了rock，但是并没有提及到climbing，所以后者的 _score 就要比前者的低。即所谓的相关性（与指定搜索查询匹配程度的一个相对度量，得分越高，文档越相关）

另外，计算得分会带来一定的性能损耗，当不需要计算得分时，可以使用filter过滤器。这个例子很好地解释了Elasticsearch是如何执行全文搜索的。对于Elasticsearch来说，相关性的感念是很重要的，而这也是它与传统数据库在返回匹配数据时最大的不同之处。

段落搜索

能够找出每个字段中的独立单词固然很好，但是有的时候你可能还需要去匹配精确的短语或者段落。例如，我们只需要查询到 about 字段只包含rock climbing的短语的员工。为了实现这个效果，我们将对 match 查询变为 match_phrase查询进行精确匹配。