es权威指南-中文版：
kibana用户手册-中文版：
es中文社区
es参考手册API
es客户端API

Bool查询则可以实现查询的组合，并支持多字段查询和精确匹配、模糊匹配、范围匹配等多种查询方式。下面我们来看一下Bool查询的基本语法：

must：表示必须匹配的条件，相当于AND。
filter：表示过滤条件，可以提高查询效率，相当于WHERE。
should：表示应该匹配的条件，可以有多个，相当于OR。
must_not：表示必须不匹配的条件，相当于NOT。

在这个查询中，必须同时匹配 title 和 content 字段，同时 status 字段必须为 published，publish_date 字段必须大于等于 2019-01-01，并且 author 字段必须匹配 John 或者 Doe 中的至少一个，同时 category 字段不能匹配 Marketing

增加预定义脚本

清空索引所有数据

新增doc

6.3版本后支持SQL，但是不支持join等复杂操作。
https://www.elastic.co/guide/en/elasticsearch/reference/current/sql-spec.html
https://www.elastic.co/guide/en/elasticsearch/reference/current/sql-search-api.html

在 Elasticsearch 中，段是倒排索引的物理存储单元。倒排索引是一种数据结构，它将文档中的每个词（term）映射到包含该词的文档列表。当文档被索引到 Elasticsearch 中时，它们会被分解成更小的单元，这些单元就是段。
例如，当有一个包含多个文档的索引，Elasticsearch 会把这些文档划分成多个段来存储和管理。每个段都是独立的，包含了倒排索引的一部分，并且是不可变的（immutable），这意味着一旦段被创建，就不能再修改。
查看某个索引的段

创建：
当新的文档被写入 Elasticsearch 时，会触发段的创建过程。在后台，Elasticsearch 会定期（由index.refresh_interval设置控制，默认是 1 秒）或者在达到一定的文档数量或大小阈值时，将内存中的索引数据刷新（flush）到磁盘上形成新的段。
例如，当向一个索引写入大量文档后，经过刷新间隔，这些文档就会被组织成新的段存储在磁盘上。
合并（Merge）：

随着时间的推移，索引中会积累许多小的段。为了提高查询性能和磁盘利用率，Elasticsearch 会自动合并这些小的段。段合并操作会读取多个小的段，将它们合并成一个更大的段，并删除原来的小的段。
例如，有多个小的段，每个段包含部分文档的倒排索引，合并后可以减少段的数量，使得查询时需要搜索的段数量减少，从而提高查询效率。同时，合并后的段可以更好地利用磁盘空间，因为它可以更紧凑地存储倒排索引。
删除：
当文档从索引中删除时，Elasticsearch 不会立即从段中删除相应的信息。而是在段合并时，会标记要删除的文档，在合并过程中真正从新的段中去除这些已删除文档的信息。

积极影响：
合理的段结构可以提高查询性能。因为段是倒排索引的存储单元，查询操作实际上是在段上进行的。当段的大小适中且经过优化（如通过合并）时，查询可以更快地定位到包含查询词的文档。例如，经过段合并后，查询时需要扫描的段数量减少，I/O 操作的次数也会相应减少，从而加快查询速度。
消极影响：
过多的小的段可能会导致查询性能下降。因为每个段都需要被搜索，过多的段会增加查询时的 I/O 开销和内存占用。例如，如果索引中有大量未合并的小的段，查询可能需要在许多小的段之间频繁切换，导致查询速度变慢。