不忘初心，好好沉淀

分布式搜索本文翻译自Elasticsearch官方指南的Distributed Search Execution一章。在继续之前，我们将绕一段路来谈谈在分布式环境中，搜索是如何执行的。和在分布式文档存储(Distributed Document Store)中讨论的基本CRUD操作相比，这个过程会更加复杂一些。一个CRUD操作会处理一个文档，该文档有唯一的_index，_t

本文翻译自Elasticsearch官方指南的Proximity Matching一章。邻近匹配(Proximity Matching)使用了TF/IDF的标准全文搜索将文档，或者至少文档中的每个字段，视作"一大袋的单词"(Big bag of Words)。match查询能够告诉我们这个袋子中是否包含了我们的搜索词条，但是这只是一个方面。它不能告诉我们关于单词间关

自定义_all字段在元数据：_all字段中，我们解释了特殊的_all字段会将其它所有字段中的值作为一个大字符串进行索引。尽管将所有字段的值作为一个字段进行索引并不是非常灵活。如果有一个自定义的_all字段用来索引人名，另外一个自定义的_all字段用来索引地址就更好了。ES通过字段映射中的copy_to参数向我们提供了这一功能：PUT /my_index{ "m

本章翻译自Elasticsearch官方指南的Controlling Relevance一章。根据过滤子集来提升(Boosting Filtered Subsets)回到在忽略TF/IDF(Ignoring TF/IDF)中处理的那个问题，我们需要根据每个度假酒店拥有的卖点数量来对它们的相关度分值进行计算。我们希望利用缓存的过滤器来影响分值，而function_

本章翻译自Elasticsearch官方指南的Controlling Relevance一章。function_score查询function_score查询是处理分值计算过程的终极工具。它让你能够对所有匹配了主查询的每份文档调用一个函数来调整甚至是完全替换原来的_score。实际上，你可以通过设置过滤器来将查询得到的结果分成若干个子集，然后对每个子集使

跨字段实体搜索(Cross-fields Entity Search)现在让我们看看一个常见的模式：跨字段实体搜索。类似person，product或者address这样的实体，它们的信息会分散到多个字段中。我们或许有一个person实体被索引如下：{ "firstname": "Peter", "lastname": "Smith"}而addr

以字段为中心的查询(Field-centric Queries)上述提到的三个问题都来源于most_fields是以字段为中心(Field-centric)，而不是以词条为中心(Term-centric)：它会查询最多匹配的字段(Most matching fields)，而我们真正感兴趣的最匹配的词条(Most matching terms)。NOTEbest_fields同

本章翻译自Elasticsearch官方指南的Filtering Queries and Aggregations一章。过滤查询以及聚合A natural extension to aggregation scoping is filtering. Because the aggregation operates in the context of the quer

本章翻译自Elasticsearch官方指南的Controlling Relevance一章。忽略TF/IDF有时我们不需要TF/IDF。我们想知道的只是一个特定的单词是否出现在了字段中。比如我们正在搜索度假酒店，希望它拥有的卖点越多越好：WiFi花园(Garden)泳池(Pool)而关于度假酒店的文档类似下面这样：{ "descript

multi_match查询multi_match查询提供了一个简便的方法用来对多个字段执行相同的查询。NOTE存在几种类型的multi_match查询，其中的3种正好和在"了解你的数据"一节中提到的几种类型相同：best_fields，most_fields以及cross_fields。默认情况下，该查询以best_fields类型执行，它会为每个字段生成一

本章翻译自Elasticsearch官方指南的Aggregation Test-Drive一章。聚合的测试数据(Aggregation Test-Drive)我们将学习各种聚合以及它们的语法，但是最好的学习方法还是通过例子。一旦你了解了如何思考聚合以及如何对它们进行合适的嵌套，那么语法本身是不难的。让我们从一个例子开始。我们会建立一个也许对汽车交易商有所用处

本章翻译自Elasticsearch官方指南的Aggregations-High-level Concepts一章。高层概念(High-Level Concepts)和查询DSL一样，聚合(Aggregations)也拥有一种可组合(Composable)的语法：独立的功能单元可以被混合在一起来满足你的需求。这意味着需要学习的基本概念虽然不多，但是它们的组合方式是几

本文翻译自Elasticsearch官方指南的distributed document store一章。分布式文档存储在上一章中，我们一直在介绍索引数据和获取数据的方法。但是我们省略了很多关于数据是如何在集群中被分布(Distributed)和获取(Fetched)的技术细节。这实际上是有意为之 - 你真的不需要了解数据在ES中是如何被分布的。它能工作就足够了。在本章中，我

本文翻译自Elasticsearch官方指南的life inside a cluster一章。增加故障转移(Failover)功能只运行一个节点意味着可能存在着单点失败(Single point of failure)的问题 - 因为没有冗余。幸运的是，解决这个问题我们只需要启动另一个节点。启动第二个节点为了试验当你添加第二节点时会发生什么，你需

本文翻译自Elasticsearch官方指南的life inside a cluster一章。ES就是为高可用和可扩展而生的。扩展可以通过购置性能更强的服务器(垂直扩展或者向上扩展，Vertical Scale/Scaling Up)，亦或是通过购置更多的服务器(水平扩展或者向外扩展，Horizontal Scale/Scaling Out)来完成。尽管ES能够利用更强劲的

为了方便大家能够更加快速地找到自己需要参考的那部分，对已经翻译完成的部分根据权威指南的目录做了相应目录，希望能够有所帮助。起步(Getting Started)1. 你懂的，为了搜索英文原文链接：You Know, for Search2. 集群中的生活译文链接： [Elasticsearch] 集群的工作原理 - 第一部分 [Elasticsearch] 集群的工作原理 - 第二部分英文原文链

1. 取得某个索引中某个字段中的所有出现过的值这种操作类似于使用SQL的SELECT UNIQUE语句。当需要获取某个字段上的所有可用值时，可以使用terms聚合查询完成：GET /index_streets/_search?search_type=count{ "aggs": { "uniq_streets": { "terms": { "field": "nam

数据建模(Modeling Your Data)ES是一头不同寻常的野兽，尤其是当你来自SQL的世界时。它拥有很多优势：性能，可扩展性，准实时的搜索，以及对大数据的分析能力。并且，它很容易上手！只需要下载就能够开始使用它了。但是它也不是魔法。为了更好的利用ES，你需要了解它从而让它能够满足你的需求。在ES中，处理实体之间的关系并不像关系型存储那样明显。在关系数据库中的黄金准则 - 数据规范化，在ES

字段折叠(Field Collapsing)一个常见的需求是通过对某个特定的字段分组来展现搜索结果。我们或许希望通过对用户名分组来返回最相关的博文。对用户名分组意味着我们需要使用到terms聚合。为了对用户的全名进行分组，name字段需要有not_analyzed的原始值，如聚合和分析中解释的那样。PUT /my_index/_mapping/blogpost{ "properties": {

问题描述随着应用的不断升级，索引中的类型也会越来越多，新增加的类型中势必会使用到一些自定义的Analyzer。但是通过_settings端点的更新API不能直接在已经存在的索引上使用。在sense中进行更新时会抛出异常：PUT /symbol{ "settings": { "analysis": { "filter": { "edgengram": {

多值字段(Multivalue Fields)在多值字段上使用短语匹配会产生古怪的行为：PUT /my_index/groups/1{ "names": [ "John Abraham", "Lincoln Smith"]}运行一个针对Abraham Lincoln的短语查询：GET /my_index/groups/_search{ "q

本章翻译自Elasticsearch官方指南的Controlling Relevance一章。通过查询结构调整相关度ES提供的查询DSL是相当灵活的。你可以通过将单独的查询子句在查询层次中上下移动来让它更重要/更不重要。比如，下面的查询：quick OR brown OR red OR fox我们可以使用一个bool查询，对所有词条一视同仁：

聚合作用域(Scoping Aggregations)到现在给出的聚合例子中，你可能已经发现了在搜索请求中我们省略了query子句。整个请求只是一个简单的聚合。聚合可以和搜索请求一起运行，但是你需要理解一个新概念：作用域(Scope)。默认情况下，聚合和查询使用相同的作用域。换句话说，聚合作于匹配了查询的文档集。让我们看看之前的一个聚合例子：GET /cars/tr

翻译自官方指南的全文搜索一章。全文搜索(Full Text Search)现在我们已经讨论了搜索结构化数据的一些简单用例，是时候开始探索全文搜索了 - 如何在全文字段中搜索来找到最相关的文档。对于全文搜索而言，最重要的两个方面是：相关度(Relevance)查询的结果按照它们对查询本身的相关度进行排序的能力，相关度可以通过TF/IDF，参见什么是相关

创建条形图(Building Bar Charts)聚合的一个令人激动的性质是它能够很容易地被转换为图表和图形。在本章中，我们会使用前面的样本数据集来创建出各种分析案例。我们也会展示聚合能够支持的种类。柱状图桶(Histogram Bucket)非常有用。柱状图在本质上就是条形图，如果你创建过一份报告或者分析面板(Analytics Dashboard)，毫无疑问其中会有一些条形图

部分匹配(Partial Matching)敏锐的读者可能已经发现到目前为止，介绍的查询都是在整个词条层面进行操作的。匹配的最小单元必须是一个词条。你只能找到存在于倒排索引(Inverted Index)中的词条。但是如果你想匹配词条的一部分，而不是整个词条呢？部分匹配(Partial Matching)允许用户指定词条的一部分然后找到含有该部分的任何单词。匹配词条一部分这

提高性能短语和邻近度查询比简单的match查询在性能上更昂贵。match查询只是查看词条是否存在于倒排索引(Inverted Index)中，而match_phrase查询则需要计算和比较多个可能重复词条(Multiple possibly repeated)的位置。在Lucene Nightly Benchmarks中，显示了一个简单的term查询比一个短语查询快大概10倍，比一

使用AngularJS为Elasticsearch创建一个前端如果使用Elasticsearch使用应用的数据源，我们可以很方便的使用AngularJS结合Elasticsearch提供的相关模块为它创建一个前端。以创建一个简单的员工信息花名册为例。准备工作准备工作分为以下两个方面：添加前端依赖安装Bower在bower.json中添加对于Angul

索引管理本文翻译自Elasticsearch官方指南的索引管理(Index Management)一章我们已经了解了ES是如何在不需要任何复杂的计划和安装就能让我们很容易地开始开发一个新的应用的。但是，用不了多久你就会想要仔细调整索引和搜索过程来更好的适配你的用例。几乎所有的定制都和索引(Index)以及其中的类型(Type)相关。本章我们就来讨论用于管理索引和类型映射的A

动态映射(Dynamic Mapping)当ES在文档中碰到一个以前没见过的字段时，它会利用动态映射来决定该字段的类型，并自动地对该字段添加映射。有时这正是需要的行为，但有时不是。你或许不知道在以后你的文档中会添加哪些字段，但是你想要它们能够被自动地索引。或许你只是想要忽略它们。或者 - 尤其当你将ES当做主要的数据存储使用时 - 大概你会希望这些未知的字段会抛出异常来提醒你注

默认映射(Default Mapping)一般情况下，索引中的所有类型都会有相似的字段和设置。因此将这些常用设置在_default映射中指定会更加方便，这样就不需要在每次创建新类型的时候都重复设置。_default映射的角色是新类型的模板。所有在_default映射之后创建的类型都会包含所有的默认设置，除非显式地在类型映射中进行覆盖。比如，我们使用_default映射对所有类型禁用

根对象(Root Object)映射的最顶层被称为根对象。它包含了：属性区域(Properties Section)，列举了文档中包含的每个字段的映射信息。各种元数据(Metadata)字段，它们都以_开头，比如_type，_id，_source。控制用于新字段的动态探测(Dynamic Detection)的设置，如analyzer，dynamic_date_formats和dy

通配符和正则表达式查询wildcard查询和prefix查询类似，也是一个基于词条的低级别查询。但是它能够让你指定一个模式(Pattern)，而不是一个前缀(Prefix)。它使用标准的shell通配符：?用来匹配任意字符，*用来匹配零个或者多个字符。以下查询能够匹配包含W1F 7HW和W2F 8HW的文档：GET /my_index/address/_search{

本章翻译自Elasticsearch官方指南的Partial Matching一章。查询期间的即时搜索(Query-time Search-as-you-type)现在让我们来看看前缀匹配能够如何帮助全文搜索。用户已经习惯于在完成输入之前就看到搜索结果了 - 这被称为即时搜索(Instant Search, 或者Search-as-you-type)。这不仅让用户能

本章翻译自Elasticsearch官方指南的Controlling Relevance一章。Lucene中的Practical Scoring Function对于多词条查询(Multiterm Queries)，Lucene使用的是布尔模型(Boolean Model)，TF/IDF以及向量空间模型(Vector Space Model)来将它们结合

最佳字段(Best Fields)假设我们有一个让用户搜索博客文章的网站，就像这两份文档一样：PUT /my_index/my_type/1{ "title": "Quick brown rabbits", "body": "Brown rabbits are commonly seen."}PUT /my_index/my_type/2{

本章翻译自Elasticsearch官方指南的Controlling Relevance一章。控制相关度(Controlling Relevance)对于仅处理结构化数据(比如日期，数值和字符枚举值)的数据库，它们只需要检查一份文档(在关系数据库中是一行)是否匹配查询即可。尽管布尔类型的YES|NO匹配也是全文搜索的一个必要组成，它们本身是不够的。我们还需要

多字段搜索(Multifield Search)本文翻译自官方指南的Multifield Search一章。查询很少是只拥有一个match查询子句的查询。我们经常需要对一个或者多个字段使用相同或者不同的查询字符串进行搜索，这意味着我们需要将多个查询子句和它们得到的相关度分值以一种有意义的方式进行合并。也许我们正在寻找一本名为战争与和平的书，它的作者是Leo Tolstoy。

控制分析(Controlling Analysis)查询只能摘到真实存在于倒排索引(Inverted Index)中的词条(Term)，因此确保相同的分析过程会被适用于文档的索引阶段和搜索阶段的查询字符串是很重要的，这样才能够让查询中的词条能够和倒排索引中的词条匹配。尽管我们说的是文档(Document)，解析器(Analyzer)是因字段而异的(Determined per Fi

match查询是如何使用bool查询的现在，你也许意识到了使用了match查询的多词查询只是简单地将生成的term查询包含在了一个bool查询中。通过默认的or操作符，每个term查询都以一个k语句被添加，所以至少一个should语句需要被匹配。以下两个查询是等价的：{ "match": { "title": "brown fox"}}{ "bool": {