豆豆不在了

自定义动态映射如果你想在运行时增加新的字段，你可能会启用动态映射。然而，有时候，动态映射 规则 可能不太智能。幸运的是，我们可以通过设置去自定义这些规则，以便更好的适用于你的数据。日期检测当 Elasticsearch 遇到一个新的字符串字段时，它会检测这个字段是否包含一个可识别的日期，比如 2014-01-01 。如果它像日期，这个字段就会被作为date 类型添加

混合起来精确短语匹配 或许是过于严格了。也许我们想要包含 quick brown fox'' 的文档也能够匹配 quick fox,'' ， 尽管情形不完全相同。我们能够通过使用 slop 参数将灵活度引入短语匹配中：GET /my_index/my_type/_search{ "query": { "match_phrase"

多值字段对多值字段使用短语匹配时会发生奇怪的事。 想象一下你索引这个文档:PUT /my_index/groups/1{ "names": [ "John Abraham", "Lincoln Smith"]}然后运行一个对 Abraham Lincoln 的短语查询:GET /my_index/groups/_sea

虽然 Elastidsearch 自带了很多的查询，但经常用到的也就那么几个。我们将在 [search-in-depth] 章节详细讨论那些查询的细节，接下来我们对最重要的几个查询进行简单介绍。match_all 查询match_all 查询简单的匹配所有文档。在没有指定查询方式时，它是默认的查询：{ "match_all": {}}

组合多查询现实的查询需求从来都没有那么简单；它们需要在多个字段上查询多种多样的文本，并且根据一系列的标准来过滤。为了构建类似的高级查询，你需要一种能够将多查询组合成单一查询的查询方法。你可以用 bool 查询来实现你的需求。这种查询将多查询组合在一起，成为用户自己想要的布尔查询。它接收以下参数：must文档 必须 匹配这些条件才能被包含进来。must

验证查询查询可以变得非常的复杂，尤其和不同的分析器与不同的字段映射结合时，理解起来就有点困难了。不过 validate-query API 可以用来验证查询是否合法。GET /gb/tweet/_validate/query{ "query": { "tweet" : { "match" : "really powerful"

排序与相关性默认情况下，返回的结果是按照 相关性 进行排序的——最相关的文档排在最前。 在本章的后面部分，我们会解释 相关性 意味着什么以及它是如何计算的， 不过让我们首先看看 sort 参数以及如何使用它。排序为了按照相关性来排序，需要将相关性表示为一个数值。在 Elasticsearch 中， 相关性得分 由一个浮点数进行表示，并在搜索结果中通过 _scor

elasticsearch系列文档提前说明：本系列文档，非笔者原创文档，来自于官方文档摘录。本系列文档，笔者只是当做一个阅读笔记，以便以后本人温习学习之用，其他好友要转载也请注明原出处。原文档访问地址：https://github.com/elasticsearch-cn/elasticsearch-definitive-guide/

字符串排序与多字段被解析的字符串字段也是多值字段， 但是很少会按照你想要的方式进行排序。如果你想分析一个字符串，如 fine old art ， 这包含 3 项。我们很可能想要按第一项的字母排序，然后按第二项的字母排序，诸如此类，但是 Elasticsearch 在排序过程中没有这样的信息。你可以使用 min 和 max 排序模式（默认是 min ），但是这会导致排序以 a

查询阶段在初始 查询阶段 时， 查询会广播到索引中每一个分片拷贝（主分片或者副本分片）。 每个分片在本地执行搜索并构建一个匹配文档的 优先队列。优先队列一个 优先队列 仅仅是一个存有 top-n 匹配文档的有序列表。优先队列的大小取决于分页参数 from 和 size 。例如，如下搜索请求将需要足够大的优先队列来放入100条文档。GET /_se

搜索选项有几个 查询参数可以影响搜索过程。偏好偏好这个参数 preference 允许 用来控制由哪些分片或节点来处理搜索请求。 它接受像 _primary, _primary_first, _local, _only_node:xyz, _prefer_node:xyz, 和 _shards:2,3 这样的值, 这些值在 {ref}/search-reques

游标查询 'Scroll'scroll 查询 可以用来对 Elasticsearch 有效地执行大批量的文档查询，而又不用付出深度分页那种代价。游标查询允许我们 先做查询初始化，然后再批量地拉取结果。 这有点儿像传统数据库中的 cursor 。游标查询会取某个时间点的快照数据。 查询初始化之后索引上的任何变化会被它忽略。 它通过保存旧的数据文件来实现这个特性，结果就

创建一个索引到目前为止, 我们已经通过索引一篇文档创建了一个新的索引 。这个索引采用的是默认的配置，新的字段通过动态映射的方式被添加到类型映射。现在我们需要对这个建立索引的过程做更多的控制：我们想要确保这个索引有数量适中的主分片，并且在我们索引任何数据 之前 ，分析器和映射已经被建立好。为了达到这个目的，我们需要手动创建索引，在请求体里面传入设置或类型映射，如下所示：

索引设置你可以通过修改配置来自定义索引行为，详细配置参照 {ref}/index-modules.html[索引模块]TipElasticsearch 提供了优化好的默认配置。 除非你理解这些配置的作用并且知道为什么要去修改，否则不要随意修改。下面是两个 最重要的设置：number_of_shards每个索引的

假设将邮编作为 not_analyzed 的精确值字段索引，所以可以为其创建索引，如下：PUT /my_index{ "mappings": { "address": { "properties": { "postcode": { "type": "str

通配符与正则表达式查询假设将邮编作为 not_analyzed 的精确值字段索引，所以可以为其创建索引，如下：PUT /my_index{ "mappings": { "address": { "properties": { "postcode": {

短语匹配就像 match 查询对于标准全文检索是一种最常用的查询一样，当你想找到彼此邻近搜索词的查询方法时，就会想到 match_phrase 查询。GET /my_index/my_type/_search{ "query": { "match_phrase": { "title": "quick brown fox"

倒排索引Elasticsearch 使用一种称为 倒排索引 的结构，它适用于快速的全文搜索。一个倒排索引由文档中所有不重复词的列表构成，对于其中每个词，有一个包含它的文档列表。例如，假设我们有两个文档，每个文档的 content 域包含如下内容：The quick brown fox jumped over the lazy dogQuick bro

缺省映射通常，一个索引中的所有类型共享相同的字段和设置。 default 映射更加方便地指定通用设置，而不是每次创建新类型时都要重复设置。default 映射是新类型的模板。在设置 default 映射之后创建的所有类型都将应用这些缺省的设置，除非类型在自己的映射中明确覆盖这些设置。例如，我们可以使用 default 映射为所有的类型禁用 _all 字段， 而只在 bl

重新索引你的数据尽管可以增加新的类型到索引中，或者增加新的字段到类型中，但是不能添加新的分析器或者对现有的字段做改动。 如果你那么做的话，结果就是那些已经被索引的数据就不正确，搜索也不能正常工作。对现有数据的这类改变最简单的办法就是重新索引：用新的设置创建新的索引并把文档从旧的索引复制到新的索引。字段 _source 的一个优点是在Elasticsearch中已经有

在数据库领域中，有两种方法通常被用来确保并发更新时变更不会丢失：悲观并发控制 这种方法被关系型数据库广泛使用，它假定有变更冲突可能发生，因此阻塞访问资源以防止冲突。一个典型的例子是读取一行数据之前先将其锁住，确保只有放置锁的线程能够对这行数据进行修改。乐观并发控制 Elasticsearch 中使用的这种方法假定冲突是不可能发生的，并且不会阻塞正在尝试的操作。然而，如果源数

文档的部分更新在 [update-doc] , 我们已经介绍过更新一个文档的方法是检索并修改它，然后重新索引整个文档，这的确如此。然而，使用 update API 我们还可以部分更新文档，例如在某个请求时对计数器进行累加。我们也介绍过文档是不可变的：他们不能被修改，只能被替换。 update API 必须遵循同样的规则。从外部来看，我们在一个文档的某个位置进行部分更新。然而

取回多个文档Elasticsearch 的速度已经很快了，但甚至能更快。将多个请求合并成一个，避免单独处理每个请求花费的网络时延和开销。如果你需要从 Elasticsearch 检索很多文档，那么使用multi-get 或者 mget API来将这些检索请求放在一个请求中，将比逐个文档请求更快地检索到全部文档。mget API 要求有一个 docs 数组作为参数，每个元素包

代价较小的批量操作与 mget 可以使我们一次取回多个文档同样的方式，bulk API 允许在单个步骤中进行多次 create 、 index 、 update 或 delete 请求。如果你需要索引一个数据流比如日志事件，它可以排队和索引数百或数千批次。bulk 与其他的请求体格式稍有不同，如下所示：{ action: { metadata }}\n

添加索引我们往 Elasticsearch 添加数据时需要用到 索引 —— 保存相关数据的地方。索引实际上是指向一个或者多个物理 分片 的逻辑命名空间 。一个 分片 是一个底层的 工作单元 ，它仅保存了全部数据中的一部分。在分片内部机制中，我们将详细介绍分片是如何工作的，而现在我们只需知道一个分片是一个 Lucene 的实例，以及它本身就是一个完整的搜索引擎。我们的文档

分页在之前的 空搜索 中说明了集群中有 14 个文档匹配了（empty）query 。但是在 hits 数组中只有 10 个文档。如何才能看到其他的文档？和 SQL 使用 LIMIT 关键字返回单个 page 结果的方法相同，Elasticsearch 接受from 和 size 参数：size显示应该返回的结果数量，默认是 10from显示应该

_all 字段这个简单搜索返回包含 mary 的所有文档：GET /_search?q=mary之前的例子中，我们在 tweet 和 name 字段中搜索内容。然而，这个查询的结果在三个地方提到了 mary ：有一个用户叫做 Mary6条微博发自 Mary一条微博直接 @maryElastics

动态映射当 Elasticsearch 遇到文档中以前 未遇到的字段，它用 dynamic mapping 来确定字段的数据类型并自动把新的字段添加到类型映射。有时这是想要的行为有时又不希望这样。通常没有人知道以后会有什么新字段加到文档，但是又希望这些字段被自动的索引。也许你只想忽略它们。如果Elasticsearch是作为重要的数据存储，可能就会期望遇到新字段就会抛出异常

索引设置你可以通过修改配置来自定义索引行为，详细配置参照{ref}/index-modules.html[索引模块]TipElasticsearch 提供了优化好的默认配置。 除非你理解这些配置的作用并且知道为什么要去修改，否则不要随意修改。下面是两个 最重要的设置：number_of_shards每个索引的主分片

自定义分析器虽然Elasticsearch带有一些现成的分析器，然而在分析器上Elasticsearch真正的强大之处在于，你可以通过在一个适合你的特定数据的设置之中组合字符过滤器、分词器、词汇单元过滤器来创建自定义的分析器。在 [analysis-intro] 我们说过，一个 分析器 就是在一个包里面组合了三种函数的一个包装器， 三种函数按照顺序被执行:字符过

元数据: _all 字段在 [search-lite] 中，我们介绍了 _all 字段：一个把其它字段值当作一个大字符串来索引的特殊字段。 query_string 查询子句(搜索?q=john )在没有指定字段时默认使用 _all 字段。_all 字段在新应用的探索阶段，当你还不清楚文档的最终结构时是比较有用的。你可以使用这个字段来做任何查询，并且有很大可能找到需要的

动态映射当 Elasticsearch 遇到文档中以前 未遇到的字段，它用 dynamic mapping 来确定字段的数据类型并自动把新的字段添加到类型映射。有时这是想要的行为有时又不希望这样。通常没有人知道以后会有什么新字段加到文档，但是又希望这些字段被自动的索引。也许你只想忽略它们。如果Elasticsearch是作为重要的数据存储，可能就会期望遇到新字段就会抛出异常

重新索引你的数据尽管可以增加新的类型到索引中，或者增加新的字段到类型中，但是不能添加新的分析器或者对现有的字段做改动。 如果你那么做的话，结果就是那些已经被索引的数据就不正确， 搜索也不能正常工作。对现有数据的这类改变最简单的办法就是重新索引：用新的设置创建新的索引并把文档从旧的索引复制到新的索引。字段 _source 的一个优点是在Elasticsearch中已经

查询时输入即搜索把邮编的事情先放一边，让我们先看看前缀查询是如何在全文查询中起作用的。用户已经渐渐习惯在输完查询内容之前，就能为他们展现搜索结果，这就是所谓的 即时搜索（instant search） 或 输入即搜索（search-as-you-type） 。不仅用户能在更短的时间内得到搜索结果，我们也能引导用户搜索索引中真实存在的结果。例如，如果用户输入 johnnie wa