Elasticsearch/Kibana Queries - In Depth Tutorial
本教程是關於如何在Kibana頂部的搜索欄中編寫查詢或在Elasticsearch中使用查詢字符串查詢的深入講解。所使用的查詢語言是Lucene查詢語言，因為Lucene在Elasticsearch內部用於索引數據。
有很多教程已經解釋了Lucene查詢語言，那么為什么要寫另一個？這些教程大部分僅涵蓋了Lucene查詢語言，但不考慮Elasticsearch 。了解您的數據在Elasticsearch中的索引如何高效地影響您通過查詢能搜索的內容和方式。
所以本教程的主題不僅僅是解釋查詢語言，而且還解釋了為什么可能找到或者找不到您存儲在Elasticsearch中的文檔。它應該可以幫助您解決您在Kibana中的查詢找不到您要查找的文檔的一些情況，您是否想知道為什么？
如果您只是想要一些很簡單的概述關於您可以在Kibana / Elasticsearch中輸入什么樣的查詢，並且不會對細節造成麻煩，或者沒有發現任何未找到的文檔的問題，即使您期望它們，其他教程中的一個可能是更好的開始選擇。
Indexing of documents
首先了解Elasticsearch如何索引數據至關重要。因此，我們將以下兩個文檔放入我們想象的Elasticsearch 實例中：
{
"title": "The Hitchhiker's Guide to the Galaxy",
"author": "Douglas Adams"
}
{
"title": "The Deeper Meaning of Liff",
"author": "Douglas Adams"
}
如果我們沒有在該索引的Elasticsearch 映射中更改任何內容，Elasticsearch將在插入第一個文檔時自動檢測字符串作為兩個字段的類型。
分析儀做什么？分析儀有幾個附加到它的編譯器和/或過濾器。編譯器將獲得應該被索引的字段的值（例如“The Hitchhiker's Guide to the Galaxy”），並且可以將該值分割成用戶應該能夠搜索的多個塊（稍后更多）。分析器的過濾器可以轉換或過濾編譯器產生的令牌。
所有產生的令牌將被存儲在所謂的倒排索引中。該索引將包含分析器生成的所有令牌以及包含它們的文檔的鏈接。因此，如果用戶使用搜索詞顯示Elasticsearch，那么只需要在倒排索引中查找它，它將立即看到需要返回哪些文檔。
由於我們沒有為我們的Elasticsearch索引指定任何映射，因此默認情況下，使用標准分析器分析字符串類型的字段。
該分析儀將首先將字段值分成字（將使用空格和標點符號作為邊界），然后使用過濾器將所有令牌轉換為小寫。
在插入上述兩個文件之后，標題欄的倒排索引如下所示，1參考第一個文檔（“The Hitchhiker's Guide to the Galaxy”），2參考“The Deeper Meaning of Liff”：
| TERM | DOCUMENTS |
|---|---|
| the | 1, 2 |
| hitchhiker's | 1 |
| guide | 1 |
| deeper | 2 |
| liff | 2 |
| of | 2 |
| to | 1 |
| galaxy | 1 |
| meaning | 2 |
還將為author字段創建同樣的倒排索引。這將包含兩個條目：一個用於“douglas”，一個用於“adams”，兩者都鏈接到這兩個文檔。
如果用戶搜索“guide”，則Elasticsearch可以快速查找要返回的文檔。此外，Elasticsearch / Kibana中的Terms-Aggregation只是查看該倒排索引並返回具有最多/最少（取決於用戶指定的順序）匹配的文檔。
Mappings in Elasticsearch
如果你插入到elasticsearch的數據不是真正的文本，例如一個URL或者類似的，那么默認的分析器沒有什么意義。特別是如果您要使用Kibana可視化您的數據，你不希望一個包含“http”條目的頂層訪問URL圖形，並且每個斜杠上的路徑分開。您只想在每個真實域中輸入一個條目。您想要的是Elasticsearch不會分析文檔中的值。
因此，您需要手動定義索引的映射。這個教程沒有涵蓋，但請看官方文檔。如果在映射中指定index：not_analyzed，title字段的倒排索引將如下所示：
| TERM | DOCUMENTS |
|---|---|
| The Hitchhiker's Guide to the Galaxy | 1 |
| The Deeper Meaning of Liff | 2 |
而author字段的倒排索引現在如下所示：
| TERM | DOCUMENTS |
|---|---|
| Douglas Adams | 1, 2 |
如你所見，Elasticsearch不會拆分值，也不會將它們轉換為小寫。
您的值觀是否被分析（即倒排索引中的哪些術語）將對您可以搜索的內容以及如何搜索有巨大的影響，我們將在以下部分中看到。當我們談論“analyzed data”時，這意味着你有分析的字符串字段中的數據。當我們談論“non-analyzed data”時，這意味着你有一個映射，這兩個字段都沒有被分析。
提示：從Elasticsearch5，不再有字符串字段類型了。分析字符串現在將是類型文本，未分析的字符串來自版本5之后的類型關鍵字。這背后的基本邏輯沒有改變。因此，本教程將繼續討論分析和未分析的字符串。請參閱changelogs
Simple queries on fields
由於我們現在解釋了Elasticsearch如何索引數據，我們可以繼續實際的主題：搜索。在“Discover”選項卡，visualization和/或dashboards的頂部，Kibana中始終可以使用以下查詢。此外，這些查詢可以在直接與Elasticsearch連接時在查詢字符串查詢中使用。
我們從簡單的查詢author:douglas開始。如果在分析的數據集上輸入此查詢，Elasticsearch將返回兩個文檔。為什么？它將在author字段的倒排索引中查找術語“douglas”。它連接到這兩個文檔，所以Elasticsearch將返回這兩個文檔作為結果。
如果您在非分析數據集上使用相同的搜索，您將無法獲得結果。為什么？Elasticsearch在倒排索引中再次查找“douglas”，沒有僅僅作為“douglas”條目的術語（僅適用於“Douglas Adams），因此不會返回任何結果。
如果您嘗試在分析的數據中搜索author:Douglas（大寫第一個字母），那么您仍然會收到這兩個文檔。為什么？因為Elasticsearch識別author字段已被分析，並嘗試將相同的分析器應用於搜索查詢“Douglas”，這意味着它也將被轉換為小寫，然后才能在反向索引中查找。這就是為什么它仍然找到文件。對未分析數據的相同查詢仍然不會產生結果，因為沒有“Douglas”條目（僅適用於“Douglas Adams”）。
注意:冒號后沒有空格。搜索author: douglas與搜索author:douglas 不一樣，很有可能不會帶來任何有意義的結果。
Search for phrases
假如你想搜索更多單詞， 你可以把這些單詞放在引號內。我們來搜索整個名字，使用author:"douglas adams"。
如果您跳過引號（即 author:douglas adams），您將搜索完全不同的內容，我們將進一步介紹的幾個部分。
如果您搜索author:"douglas adams"對未分析的數據，您將獲得 - 戲劇性的暫停 - 沒有結果（如您所預期的）。為什么？它會在倒排的索引中查找“douglas adams”的條目，但“Douglas Adams”只有一個 - 搜索區分大小寫。您可能已經猜到了，但是尋找author:"Douglas Adams"將在未分析的數據中返回兩個文檔，因為這正是存儲在反向索引中的“key”。
如果您在分析的數據上搜索author：“douglas adams”，它將返回兩個文檔。為什么？Elasticsearch再次認識到，author字段被分析，並嘗試將相同的分析器應用於您的查詢，即在這種情況下將單詞分解並將其轉換為小寫。之后，它發現兩個文件有“douglas”和“adams”條目，所以它將返回兩者。搜索author:"Douglas Adams"將返回相同的，因為Elasticsearch在實際搜索之前將小寫過濾器應用於您的查詢（如上所述）。
Wildcard Queries
您也可以在搜索查詢中使用通配符。有兩個通配符可用：？ （問號）將是一個字符的占位符。 *（星號）是任意數量字符（包括0）的占位符。
注意：您不能在短語內使用通配符。如果您搜索author：“Do？glas Adams”，問號不會用作通配符，但必須是索引值的一部分（這不是我們的情況）。更多的關注：由於Elasticsearch將分析器應用於您的查詢，如果將它們放在詞的開頭/結尾，它可能看起來像通配符在短語內正在工作---例如author：“Douglas Adams*”仍然會在分析的數據上返回兩個文檔，但並不是因為通配符按預期工作，只是因為在分析查詢時分析儀剝離了該星號。該查詢找不到“Douglas Adamsxxx”的值。
在展示了什么不起作用之后（短語中的通配符），我們來看看它們是如何工作的。假設我們想搜索以“doug”開頭名字的作者的所有圖書。如果我們搜索author:doug*在分析的數據，我們將得到這兩個文件。相反，搜索author:doug不會返回任何東西，因為“doug”的倒排索引中沒有條目。當輸入該查詢時，Elasticsearch將查找倒排索引並搜索與“doug *”匹配的條目（星號是任意數量的字符）。倒排索引中有一個條目（即“douglas”），鏈接到這兩個文檔，因此這兩個文件都將被返回。
現在我們來看一個可能令人困惑的部分查詢語言。如果我們對未分析的數據使用相同的搜索項，我們將不會得到結果。到目前為止，這不應該是一個驚喜，因為在倒排索引中只有“Douglas Adams”（大寫字母）的條目，意味着搜索“doug *”將不會產生任何結果。所以讓我們來巧妙地搜索author:Doug*。從我們到現在所知道的，現在應該在倒排的索引中找到“Douglas Adams”條目。但是如果你搜索它，它不會返回任何結果。
那里發生了什么？一旦您在查詢中使用通配符，Elasticsearch將自動小寫您的查詢。無論您正在搜索的字段是否被分析。意味着搜索author：Doug *將被轉換為author：doug *，因此在未分析的倒排索引中將找不到“Douglas Adams”。如果您直接與Elasticsearch通信，則編寫JSON查詢，則可以在query_string對象中將lowercase_expanded_terms設置為false以禁用該行為。如果您在Kibana中進行搜索，並希望在搜索大寫值時使用通配符（在未分析的字段中），則必須編寫JSON查詢，我將在本教程末尾進行說明。
還不太困惑？然后讓我們直接跳到下一節。
Writing queries without a field
Old behavior
以下行為是舊的Elasticsearch行為，但為了完整性在這里描述。如果您在5.1之前使用Elasticsearch版本或者在5.1之前仍然有數據索引，則可能會影響您。
如果你只是寫一個像Douglas一樣查詢，那么Elasticsearch就不知道你想看哪個倒排索引。如果在直接查詢Elasticsearch時使用JSON，您可以使用query_string對象中的default_field選項指定應該查找的字段。如果您不指定它（或在Kibana中輸入該查詢），則它將默認為_all字段。這是一個Elasticsearch為您創建的特殊字段，它具有自己的倒排索引。所以搜索Douglas就像搜索_all：Douglas一樣。
那么_all字段的倒排索引是什么？默認情況下，插入文檔時，Elasticsearch會將所有字段的值連接成一個大字符串 - 無論原始字段是不是字符串類型，還是根本沒有分析。它將構建一個大的值，由標准分析器進行分析，並將其歸結為自己的倒排索引。
我們來看一個例子。假設我們將以下文檔放到Elasticsearch中：
{
"some_field": "foo bar",
"unanalyzed_field": "Douglas Adams",
"numeric_field": 42
}
{
"another_field": "foo adams"
}
之后，_all字段的倒排索引將如下所示：
| TERM | DOCUMENTS |
|---|---|
| douglas | 1 |
| foo | 1, 2 |
| bar | 1 |
| 42 | 1 |
| adams | 1, 2 |
因此，_all字段允許您在默認情況下甚至搜索未分析字段中的單個字詞。而unanalyzed_field的倒排索引（在上面的示例文檔中）將僅包含條目“Douglas Adams”，因為該字段設置為未分析（在我們想象的Elasticsearch映射中）。
回到我們以前的數據（我們關於Douglas Adams的兩本書籍文件）：如果我們設置了author字段no_analyzed，它的反向索引將只有一個條目：“Douglas Adams”。_all字段的反向索引將同時包含：“douglas”條目和“adams”條目，因為文檔中每個字段的值都將以“元字段”進行分析和索引。
這意味着 - 查看我們未分析的數據 - 搜索Douglas （或同等的_all:Douglas）將返回兩個文檔。搜索author:Douglas不會返回任何結果（即使作者字段最初包含該值）。為了搜索未分析的作者字段，您需要在其反向索引（即“Douglas Adams”）中指定精確匹配，以便在_all字段中搜索分析的值（如“douglas”）。
如果您想知道，為什么搜索_all:Douglas （大寫）仍然找到該文檔，即使_all反向索引有“douglas”（小寫）索引：Elasticsearch將使用與前面提到的相同的自動檢測。它檢測到_all字段是一個分析的字段，因此它將對搜索值（“Douglas”）使用相同的分析器，其中將值轉換為小寫。
New behavior
從Elasticsearch 5.1開始，_all字段被all_fields搜索模式替換。如果您在更現代的Elasticsearch版本中搜索沒有字段的字符串（例如上述示例中的Douglas），搜索將不會針對特定的_all反向索引，而是針對所有反向索引。這樣可以在每個（可搜索）字段中搜索該值，但是將使用該字段的實際分析器。
您可以在GitHub的pull請求中找到更多關於_all字段何時可以使用all_fields搜索的詳細信息。
AND & OR Operators
到目前為止，我們只給出了一個條件。但是當然你也可以使用AND和OR來指定多於一個條件。你必須把這些操作符寫成大寫。如果你把它們寫成小寫，就不會被檢測到。（實際上你可能會發現結果很奇怪，因為你只是將它們寫入小寫，因為它只會拋出另一個_all:and個別_all:or查詢。）
我們來搜索author:douglas AND author:adams。AND周圍的每個查詢部分的工作原理如前幾節所述。因此，無論數據是否被分析，對於每個部分都是重要的，但對於AND / OR操作者本身並不重要。這就是為什么我們從現在開始僅僅查看分析數據。
搜索author:douglas AND author:adams將返回這兩個文件，因為反向索引中有一個“douglas”條目和一個“adams"條目，並且都指向相同的文件，所以返回。
搜索author:douglas OR author:terry將導致相同的兩個文檔，因為它們都匹配查詢的第一部分（它只需要匹配其中一個部分）。author:douglas AND author:terry不會返回任何文件，因為沒有任何文件完整填滿查詢的兩個部分。
如果你只是鍵入author:douglas author:terry Elasticsearch再次需要知道你是否意味着OR或AND在這種情況下。如果您向Elasticsearch編寫JSON查詢，則可以使用query_string對象中的default_operator選項指定應該插入哪個操作符。默認情況下，如果您不指定（或從Kibana進行搜索），則為OR。意味着author:douglas author:terry相當於author:douglas OR author:terry。
在本教程的開頭，我提到如果要搜索短語，設置引號是多么的重要。我說author:"Douglas Adams"搜索與author:Douglas Adams是完全不同的東西。我們現在知道一切，以了解后期查詢搜索的內容。假設您沒有更改default_operator和default_field，這個查詢將等同於author：Douglas OR _all：Adams將最有可能導致與author:“Douglas Adams”不同的文檔。
如果您在查詢中使用多於兩個部分，則可以在其周圍放置括號以更改分組。默認情況下，Elasticsearch將在查看OR運算符之前首先查看是否所有AND運算符匹配。
除了使用關鍵字AND和OR，您還可以使用&&或||分別。
關於這些操作符的官方文檔非常詳細。
Plus Operator
除了使用AND和OR之外，還有一個加號運算符（+）。如果把它放在查詢部分的前面，這個查詢部分必須匹配。所有其他查詢部分（前面沒有加號）是可選的。例如 +author:adams title:guide將匹配在author字段中包含adams的所有文檔，並且可選title字段中包含guide。
通常使用加號運算符比使用AND和OR查詢更容易理解。Elastic同時也建議在可能的情況下使用+號（減號操作符在下一章 講解）而不是使用AND 和 OR。
請注意，加號和實際查詢部分之間不允許有空格。
Exclusion (NOT operator)
如果要排除匹配特定條件的文檔，可以在查詢的該部分前面加上減號（ - ），感嘆號（！）或NOT字。如果要搜索包含“douglas”，但不包含“adams”的文檔，查詢author:douglas -author:adams。
小心：不要在減號或感嘆號和實際查詢之間有空格。
Regular expressions
Elasticsearch還通過將搜索字符串包裝在斜杠中來支持正則表達式搜索，例如 author:/[Dd]ouglas.*/。像其他查詢一樣，將在反向索引中搜索正則表達式，即正則表達式必須與反向索引中的條目匹配，而不是實際的字段值。
例如，如果我們搜索author:/[Dd]ouglas.*[Aa]dams/在未分析的數據中，它將產生兩個文檔，因為在倒排索引中有一個條目“Douglas Adams”。
如果在分析數據上使用相同的查詢，則不會得到任何結果，因為它與任何反向索引條目不匹配。只有“douglas”和“adams”的條目，但沒有一個符合上述正則表達式。
支持的正則表達式語法是Lucene特有的，您可以查找文檔以查看正則表達式運算符的支持。
注意：執行正則表達式搜索可能相當昂貴，因為Elasticsearch可能需要將每個反向索引條目與正則表達式進行比較，這可能需要一些時間。如果您不用正則表達式並且使用其他查詢類型之一，則應該這樣做。
Range Queries
如果要在數字字段上搜索，您當然可以使用一個簡單的查詢，如number：42（假設您的文檔中有一個名為數字的數字字段）來查找此字段為42的所有文檔。使用數字時，您通常需要在特定范圍內搜索，而不僅僅是為了固定值。因此，Elasticsearch為您提供范圍查詢：
- number:[32 TO 42] -- 將找到所有文檔，其number在32到42之間（32和42仍然包括在結果中）
- number:[32 TO 42} -- 將找到所有number在32到42之間的文檔（包括32，42被排除在結果之外）
- number:[23 TO *] -- 將找到所有number大於或等於23的文檔
如您所見，方括號總是包括實際的數字，而花括號將從搜索中排除指定的數字。您當然也可以使用星號和花括號，用於范圍的下邊界。
如果你的范圍有一個開放的結尾（星號），那么寫一個比更大或者更少的速記查詢語法：
number:>42number:<42- number:>= 42
- number:<=42
Ranged queries on string fields
您還可以對字符串字段使用范圍查詢。字符串按字母順序排列，大寫字母在小寫字母之前，即它們的ASCII順序。所以一個正確的字符串順序是：
A < D < Douglas < Douglas Adams < a < d < douglas
搜索author:>=n對分析的數據將返回所有文件，其名稱或姓氏以n開頭。再次，該比較是針對該字段的反向索引，這就是為什么在分析數據時，名稱的一部分足以匹配此查詢。
我們使用上面的大或等於運算符。在搜索author:>n時（只有大於）你可能會認為，這只會顯示以o或更高開頭的名字，但事實並非如此。它將顯示大於“n”的所有名稱，這是以“n”開頭的每個名稱，除了唯一的字符串“n”本身。
警告：在字符串字段上使用范圍查詢時存在一個陷阱。如果您不將“通配符查詢”部分中介紹的lowercase_expanded_terms選項更改為false，那么Elasticsearch默認將查詢轉換為小寫的查詢，意思是搜索author:>D等效於搜索author:>d。如果您的數據未分析，並且在倒排索引中實際上有一個“Douglas Adams”條目，您不會指望author:<C找到它，因為您只想搜索所有低於“C”的authors 。由於這將被轉換為author：<c它將找到您的文檔，因為所有大寫字母總是小於任何小寫字母，意思是“D”<“c”，“Douglas”<“c”也是如此。如果您不希望該行為，則在使用JSON與Elasticsearch進行通信時，您需要在query_string對象中將lowercase_expanded_terms設置為false。
More Query Types
還有一些查詢類型，詳細的說明可以在官方文檔中找到。您現在應該具有關於反向索引如何工作的所有知識，以便從官方文檔中了解這些運算符。我將簡要介紹一下缺少的操作：
Fuzziness
如果要搜索與特定值類似的術語，但不一定需要相同，可以使用模糊（〜）運算符：
doglas〜將搜索所有類似“doglas”的事物。默認情況下，它必須在 Damerau-Levenshtein distance為2（您需要編輯/插入/刪除以將查詢更改為實際索引項的字符數量）。
您可以用操作符后面的數字指定允許的距離：doglas〜1
Proximity
模糊運算符類似於近似運算符。如果您搜索author：“adams douglas”短語 Elasticsearch希望單一術語在原始文檔中按照該順序顯示，並且找不到任何文檔。
指定鄰近像author：“adams douglas”〜2允許這些單詞以另一個順序或最多（在這種情況下）在實際文檔中分開2個字。
Search for (non)existing fields
有兩個特殊的“字段”來檢查一個文檔是否包含一個字段，或者沒有。
如果要搜索所有文檔，那么沒有“author”字段或沒有值（即為空），您可以使用查詢_missing_：author。
果要檢查所搜索文檔中是否存在特定字段，並且具有非空值，則可以使用_exists_：author。
由於Elasticsearch對數據索引的方式，您無法看到文檔在插入到Elasticsearch之后是否沒有字段，或者該值是否為null時的任何差異。所以在查詢中沒有可能分離這兩種情況。
Boosting
Elasticsearch排序它找到的結果，首先返回最匹配的文檔。您可以使用boost操作符（^）來更改單個查詢部分的重要性。
例如。當搜索author:douglas OR title:guide^5在排序重要性方面，第二部分是第一部分查詢的五倍（默認增強值為1）。
該操作符不影響Elasticsearch發現的文檔，只響應這些結果排列的順序。（如果您限制搜索結果的數量，當然這個順序可以確定哪些文檔實際上返回給用戶。）
Using JSON in the Kibana search
從Kibana搜索時，通常會在整個教程中將實際的查詢字符串輸入到頂部欄中。如果查詢字符串不足以滿足您的需要，您也可以在該欄中編寫JSON。
您可以編寫JSON對象，當您將Elasticsearch 與該框進行通信時，您將附加到“query”鍵，例如：
{ "range": { "numeric": { "gte": 10 } } }
這相當於在該框中寫入numeric：> = 10。如果您需要訪問僅在JSON查詢中可用的選項，而不是查詢字符串中的選項，這通常才有意義。
再一次警告：如果您將query_string的JSON寫入該字段（例如，因為要訪問lowercase_expanded_terms），則Kibana將為查詢存儲正確的JSON，但會再次向你僅顯示（在按下enter鍵之后）您Json的"query"部分。這可能是超級混亂，當然如果您現在輸入文本並再次按Enter鍵，它也會失去您通過JSON設置的選項，所以這應該真的要小心使用。
More Special cases
本節應該介紹一些更特殊的情況，您可能會認為：“我閱讀了整個教程，我了解了一切，但是我的查詢仍然找不到我希望找到的數據。”
Elasticseach doesn't find terms in long fields
這是從我的經驗 - 一個很常見的問題，並不容易找到，如果你不知道你在查找什么。
Elasticsearch有一個ignore_above設置，您可以在每個字段的映射中設置。這是一個數字值，當插入文檔時，這將導致Elasticsearch不指定比指定的ignore_above值更長的值。該值仍將被存儲，所以當查看文檔時，您將看到該值，但是您不能搜索它。
你如何檢查一個字段上設置的值？您需要通過調用<your-elasticsearch-domain> / <your-index-name> / _mapping來檢索Elasticsearch的映射。在返回的JSON中，會顯示您正在查找的字段的映射，可能如下所示：
"fieldName": {
"type": "string",
"ignore_above": 15
}
在這種情況下，超過15個字符的值不會被索引，您無法搜索它們。
示例：假設上述映射，我們將兩個文檔插入到Elasticsearch中：
{ "fieldName": "short string" }
{ "fieldName": "a string longer as ignore_above" }
如果現在列出所有文檔（在Kibana或Elasticsearch本身），您將看到兩個文檔都在那里，兩個字段的值都是您插入的字符串。但是如果您現在搜索fieldName:longer ，您將不會得到任何結果（而fieldName：short將返回第一個文檔）。Elasticsearch發現值“a string longer as ignore_above”超過15個字符，因此它只將其存儲在文檔中，但不對其進行索引，所以您無法搜索任何內容，因為該字段的倒排索引中不會有該值的任何內容。
Searching needs a specific field it doesn't work without
如果您可以搜索例如author：foo，但不是為了foo，這最有可能是您的default_field的“problem”。Elasticsearch在foo前面添加了默認字段。該字段可以配置為與_all不同的東西。
可能的是，index.query.default_field設置被設置為不同的事情，Elasticsearch不使用可能導致問題的_all字段。
另一種可能性是，_all字段的行為不像您期望它的行為，因為它以其他方式配置。您可以從_all字段中排除特定字段（例如，在上述示例中，fieldName可能已從_all字段中的索引中排除），或者_all字段映射中的分析/索引選項已更改。
What's next?
我希望這個在Kibana / Elasticsearch中的查詢語言的深入概述可以幫助您更好地了解查詢，希望您現在可以理解查詢是否（或不）匹配數據中的文檔。
如果您覺得我忘記了任何重要的部分或邊緣案件，或者您有任何其他問題，請隨時在下面發表評論。
原文地址：https://www.timroes.de/2016/05/29/elasticsearch-kibana-queries-in-depth-tutorial/