实时查询
通常对一个通过上面方法写入到 Elasticsearch 的文档，在默认的情况下并不马上可以进行搜索。这是因为在 Elasticsearch 的设计中，有一个叫做 refresh 的操作。它可以使更改可见以进行搜索的操作。通常会有一个 refresh timer 来定时完成这个操作。这个周期为1秒。这也是我们通常所说的 Elasticsearch 可以实现秒级的搜索。当然这个 timer 的周期也可以在索引的设置中进行配置。如果我们想让我们的结果马上可以对搜索可见，我们可以用如下的方法：
|
上面的方式可以强制使 Elasticsearch 进行 refresh 的操作，当然这个是有代价的。频繁的进行这种操作，可以使我们的 Elasticsearch 变得非常慢。另外一种方式是通过设置 refresh=wait_for。这样相当于一个同步的操作，它等待下一个 refresh 周期发生完后，才返回。这样可以确保我们在调用上面的接口后，马上可以搜索到我们刚才录入的文档：
|
查询后更新
在关系数据库中，我们通常是对数据库进行搜索，让后才进行修改。在这种情况下，我们事先通常并不知道文档的 id。我们需要通过查询的方式来进行查询，让后进行修改。ES 也提供了相应的 REST 接口。
要结合脚本才可以实现
|
存在更新不存在新增
仅在文档事先存在的情况下，我们在前面的代码中看到的部分更新才有效。 如果具有给定 id 的文档不存在，Elasticsearch 将返回一个错误，指出该文档丢失。 让我们了解如何使用更新 API 进行 upsert 操作。 术语 “upsert” 宽松地表示更新或插入，即更新文档（如果存在），否则，插入新文档。
doc_as_upsert 参数检查具有给定ID的文档是否已经存在，并将提供的 doc 与现有文档合并。 如果不存在具有给定 id 的文档，则会插入具有给定文档内容的新文档。
下面的示例使用 doc_as_upsert 合并到 id 为 3 的文档中，或者如果不存在则插入一个新文档：
|
查询后删除
在关系数据库中，我们通常是对数据库进行搜索，让后才进行删除。在这种情况下，我们事先通常并不知道文档的 id。我们需要通过查询的方式来进行查询，让后进行删除。ES 也提供了相应的 REST 接口。
|
批处理命令_bulk
因为每一次操作都是一个 REST 请求，对于大量的数据进行操作的话，这个显得比较慢。ES 创建一个批量处理的命令给我们使用。这样我们在一次的 REST 请求中，我们就可以完成很多的操作。这无疑是一个非常大的好处。下面，我们来介绍一下这个 _bulk 命令。
|
在上面的命令中，我们使用了 bulk 指令来完成我们的操作。在输入命令时，我们需要特别的注意：千万不要添加除了换行以外的空格，否则会导致错误。在上面我们使用的 index 用来创建一个文档。为了说明问题的方便，我们在每一个文档里，特别指定了每个文档的 id。当执行完我们的批处理 bulk 命令后，我们可以看到：
bulk 指令是高效的，因为一个请求就可以处理很多个操作。在实际的使用中，我们必须注意的是：一个好的起点是批量处理 1,000 到 5,000 个文档，总有效负载在 5MB 到 15MB 之间。如果我们的 payload 过大，那么可能会造成请求的失败。
使用create批量创建
|
index 和 create 的区别。index 总是可以成功，它可以覆盖之前的已经创建的文档，但是 create 则不行，如果已经有以那个 id 为名义的文档，就不会成功。
批量删除
|
批量更新
|
分页搜索
1.使用from,size分页搜索
深分页性能会有所降低，并且from， size 最大不能超过 10000 超过10000 ES会直接报错。
例如，如果更改 mapping 并希望将所有现有数据重新索引到新索引中，您可能没有足够的内存来对所有结果进行排序以返回最后一页的数据。
对于大量的数据而言，我们尽量避免使用 from+size 这种方法。这里的原因是 index.max_result_window 的默认值是 10K，也就是说 from+size 的最大值是1万。搜索请求占用堆内存和时间与 from+size 成比例，这限制了内存。假如你想 hit 从 990 到 1000，那么每个 shard 至少需要 1000 个文档：
2.使用scroll分页
|
这里的 scroll=1m，表明 Elasticsearch 允许等待的时间是1分钟。如果在一分钟之内，接下来的 scroll 请求没有到达的话，那么当前的请求的上下文将会丢失。
返回的数据是
|
在这里，我们可以看到一个返回的 _scroll_id。这个 _scroll_id 将会被用于接下来的请求。
利用上次请求返回来的 _scroll_id，再次请求以获得下一个 page 的信息：
|
在这里必须指出的是：
- 这里填写的 scroll_id 是上一个请求返回的值
- 这个 scroll_id 的有效期是我们在第一次搜索时定义的 1m，也就是1分钟。如果超过了，这个就没有用
如果完成此过程，则需要清理上下文，因为上下文在超时之前仍会占用计算资源。 如下面的屏幕快照所示，您可以使用 scroll_id 参数在 DELETE API 中指定一个或多个上下文：
|
注意事项: 使用scroll时，数据是一致的，不会实时更新，生成scroll时，数据生成快照，有效期到期之前有新增数据 scroll查询不能感知。 scroll占用内存，当快照不使用时，应当及时清除。 scroll到期后，在java程序中查询会抛出异常，应当及时捕获处理。
3.使用after_search分页(推荐)
为了避免过度使得我们的 cluster 繁忙，通常 Scroll 接口被推荐作为深层次的 scrolling，但是因为维护 scroll 上下文也是非常昂贵的，所以这种方法不推荐作为实时用户请求。search_after 参数通过提供实时 cursor 来解决此问题。 我们的想法是使用上一页的结果来帮助检索下一页。
我们先创建一些测试数据
|
这里共有6个文档。假设检索第一页的查询如下所示：
|
结果为：
|
上述请求的结果包括每个文档的 sort 值数组。 这些 sort 值可以与 search_after 参数一起使用，以开始返回在这个结果列表之后的任何文档。 例如，我们可以使用上一个文档的 sort 值并将其传递给 search_after 以检索下一页结果：
|
搜索结果为：
|
注意：当我们使用 search_after 时，from 值必须设置为 0 或者 -1。
它与 scroll API 非常相似，但与它不同，search_after 参数是无状态的，它始终针对最新版本的搜索器进行解析。 因此，排序顺序可能会在步行期间发生变化，具体取决于索引的更新和删除。
计数
我们经常会查询我们的索引里到底有多少文档，那么我们可以使用_count重点来查询：
|
如果我们想知道满足条件的文档的数量，我们可以采用如下的格式：
|
查询
在我们使用 match query 时，默认的操作是 OR，我们可以做如下的查询：
|
这是因为默认的操作是 or 操作。上面查询的结果是任何文档匹配：“朝”，“阳”，“区”，“老”及“贾”这5个字中的任何一个将被显示：
|
我们也可以设置参数 minimum_should_match 来设置至少匹配的 term。比如：
|
上面显示我们至少要匹配“朝”，“阳”，“区”，“老” 及 “贾” 这5个中的3个字才可以。显示结果：
|
我们也可以改为 and 操作：
|
显示的结果是：
|