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批量查询，减少网络往返。

基本搜索请求格式

    Method /{index}/{type}/{id}        {        "field": "value",        ...        }  

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

全文搜索

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

    GET /megacorp/employee/_search        {            "query" : {            "match" : {            "about" : "rock climbing"            }            }        }  

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

    {        ...        "hits": {        "total": 2,        "max_score": 0.16273327,        "hits": [            {            ...            "_score": 0.16273327, <1>            "_source": {            "first_name": "John",            "last_name": "Smith",            "age": 25,            "about": "I love to go rock climbing",            "interests": [ "sports", "music" ]            }            },            {            ...            "_score": 0.016878016, <1>            "_source": {            "first_name": "Jane",            "last_name": "Smith",            "age": 32,            "about": "I like to collect rock albums",            "interests": [ "music" ]            }            }            ]            }            }  

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

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

段落搜索

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


来自：http://blog.csdn.net/xifeijian/article/details/49611909