elsearch

1. ElasticSearch是性能优化的分布式全文搜索引擎，存储数据的载体是文档（Document），它的优势在于搜索速度快和支持聚合操作，在更新文档时，基本上能够达到实时搜索。ElasticSearch引擎总是按照文档标识来更新数据，并发控制是通过顺序的版本ID（version）实现的，控制写-写、写-读冲突，实现数据弱一致性。

2. 在编入索引时，索引操作支持参数op_type，用于指定索引数据的操作类型是create，当文档ID不存在时，将文档添加到索引中；当显式指定操作类型是create时，如果创建的文档ID已经存在于索引中，那么创建操作将失败。

PUT 'http://localhost:9200/twitter/tweet/1?op_type=create' -d
PUT 'http://localhost:9200/twitter/tweet/1/_create' -d

3. 在索引文档时，如果没有指定文档标识，那么ElasticSearch将会自动生成文档标识，并自动把操作类型(op_type)设置为create，注意，自动生成文档标识是更新操作，修改索引中的文档，而不是新建一个新的文档，因此使用POST动词，而不是PUT动词。

POST 'http://localhost:9200/twitter/tweet/' -d
'{
    "user" : "kimchy",
    "post_date" : "2009-11-15T14:12:12",
    "message" : "trying out Elasticsearch"
}'

4. 在ElasticSearch引擎中删除文档非常简单，通过文档标识删除文档，实际上，该文档并没有从索引中物理删除，只是在其他文件中被标记删除，只要ElasticSerach 引擎执行段合并操作时，才会真正从物理上删除文档。

5. ElasticSearch引擎在更新端点(_update)上更新文档，更新操作首先从索引中查询到文档，执行更新逻辑，并将更新之后的文档重新索引，使之能够被搜索到。在更新文档时，ElasticSearch使用版本控制并发操作可能产生的冲突。更新端点(_update)主要是基于脚本的文档更新，ElasticSearch引擎从索引中获取文档，使用脚本和可选的参数执行更新操作，并将文档重新编入索引。在更新时，即使只修改文档的部分字段，ElasticSearch也会重新索引整个文档，并使用文档版本避免读-写冲突。使用端点(_update)和内嵌脚本对文档执行更新操作，必须启用_source 字段。

6.upsert参数，当指定的文档不存在时，upsert参数包含的内容将会被插入到索引中，作为一个新文档；如果指定的文档存在，ElasticSearch引擎将会执行指定的更新逻辑。

7. 根据提供的文档片段更新数据

使用"doc"字段传递文档片段（Partial Document），doc字段包含完整文档的一部分字段，ElasticSearch引擎对已经存在的文档进行归并（Merge）更新，这就意味着，如果文档中存在doc节指定的字段，那么替换文档中的字段值；如果文档中部存在doc节指定的字段，那么向文档中增加新的字段，例如，对文档标识为1的文档，将该文档中的name字段更新为“new_name”：

POST 'localhost:9200/test/type1/1/_update' -d '{
    "doc" : {
        "name" : "new_name"
    },
   "detect_noop": false
}'

detect_noop参数，在更新部分文档时，文档值被归并到_source字段，默认值是true，这意味着，当ElasticSearch引擎会检测_source字段的数据发生变化时，ElasticSearch引擎将重新索引该文档；如果设置设置为False时，ElasticSearch引擎不管_source字段的数据是否变化，都会更新文档。

8.  retry_on_conflict参数：指定更新操作在发生版本冲突时重试的次数。

对于文档的更新操作，ElasticSearch引擎需要顺序执行三个阶段：获取文档（Get），更新文档（Update）和索引文档（Index）。在更新文档时，其他进程可能已经把相同的文档修改了。在默认情况下，更新操作由于检测到版本冲突而就立即失败，抛出异常。参数retry_on_conflict控制在ElasticSearch引擎真正抛出异常之前，更新操作重新执行的次数。

fields 参数：从已更新的文档中，返回有关字段（Relevant Fields）的数据，如果将fields设置为_source，将返回整个文档的所有数据。

9. 批量端点(_bulk)用于在一个请求（Request）中封装多个操作，请求格式是/index_name/type_name/_bulk。在请求主体中，包含多个操作请求，单个请求的格式相同，不同之处在于，每个请求包含两行JSON对象：信息行和数据行，由于批量端点必须识别换行，因此，发送的请求格式 使用--data-binary 代替 -d：

POST /_bulk?pretty  --data-binary  request_body

请求主动体，有四种类型，分别是index、update、create和delete，实现数据的索引分析，文档更新，文档创建和文档删除。

10. 字符串的完全匹配是指字符的大小写，字符的数量和位置都是相同的，词条（term）查询使用字符的完全匹配方式进行文本搜索，词条查询不会分析（analyze）查询字符串，给定的字段必须完全匹配词条查询中指定的字符串。由于词条查询的字符串是未经分析（analyzed）的词条，因此，词条查询经常用于结构化的数据，例如，数值，日期等，当用于文本搜索时，最好在索引映射中设置字符串字段不被索引，也就是说，设置index属性为not_analyzed，否则，只能对该字段进行单词条搜索，也可以使用多字段(fields)属性，定义一个不被分析的字段，原始字段用于全文搜索，而多字段用于词条搜索：

11. 词条（term）查询和全文（fulltext）查询最大的不同之处是：全文查询首先分析（Analyze）查询字符串，使用默认的分析器分解成一系列的分词，term1，term2，termN，然后从索引中搜索是否有文档包含这些分词中的一个或多个，如果执行的match查询，默认的操作符（operator）是，只要文档的字段值能够匹配任意一个词条，该文档就匹配查询条件；而词条查询是字符的完全匹配，只有当字段的字符完全匹配查询字符串时，ElasticSearch引擎才判定文档匹配查询条件：

词条查询：词条查询不会分析查询条件，只有当词条和查询字符串完全匹配时，才匹配搜索。当在未被分析的字段中进行搜索时，和查询字符串完全匹配的文档会被返回；如果在已分析（Analyzed）的字段中进行搜索，词条必须是小写的单个词条，否则，匹配不到任何文档；

全文查询：ElasticSearch引擎会先分析（analyze）查询字符串，将其拆分成小写的分词，只要已分析的字段中包含词条的任意一个，或全部包含，就匹配查询条件，返回该文档；如果不包含任意一个分词，表示没有任何文档匹配查询条件。

12. 对于单个词条，对eventname字段进行查询，由于该字段是被索引和分析（analyzed）的，因此，分词之后，该字段只包含小写的分词。     如果词条查询写成"eventname":"Azure"，那么将匹配不到任何文档，ElastiSearch引擎返回空的hits数组。

13. 匹配查询的行为受到两个参数的控制：

• operator：表示单个字段如何匹配查询条件的分词
• minimum_should_match：表示字段匹配的数量

14. 短语（Phrase）是一个字符串，其单个分词出现的位置和分词的数量是固定的。在进行短语查询时，必须匹配短语中每个分词及其相对位置，例如，对于包含两个分词的短语：“azure function”，分词“azure”出现在分词“function”之前，并且两个词条之间的位置相差一个空格，下面两个字符串都满足短语匹配：

• "Azure Notification Hubs & Azure Function"
• "Serverless Azure Function"

15. 在布尔查询中，对查询结果的过滤，建议使用过滤（filter）子句和must_not子句，这两个子句属于过滤上下文（Filter Context），经常使用filter子句，使得ElasticSearch引擎自动缓存数据，当再次搜索已经被缓存的数据时，能够提高查询性能；由于过滤上下文不影响查询的评分，而评分计算让搜索变得复杂，消耗更多CPU资源，因此，filter和must_not查询减轻搜索的工作负载。