Elasticsearch實戰之深入功能(二)

  • 使用curl 和 REST API, 發送JSON文檔讓Elasticsearch進行索引。你將看到返回時JSON應答。
  • 如果索引和類型尚不存在,Elasticsearch是如何自動地創建文檔所屬的索引和類型

通過curl命令發送HTTP請求 ,也有Head kopf Marvel 在瀏覽器裏支持Elasticsearch

創建索引和映射索引

1. 手動創建索引

curl -XPUT 'localhost:9200/new-index'
{"acknowledged":true}

2.獲取映射

發送一個HTTPGET請求到該索引的_mapping端點 會展示索引內所有類型的映射,但是可以通過在_mapping端點後指定類型的名字來獲得某個具體的映射。

搜索並獲取數據 

一個查詢在某個指定字段上運行,如q=name:elasticsearch,但是在這個例子中並沒有指定任何字段,因爲我們想在所有字段中搜索。實際上,Elasticsearch默認使用一個稱爲_all的字段,其中索引了所有字段內容。

一個搜索的三個重要組成部分:

1. 在哪裏搜索

2. 回覆的內容

3. 搜索什麼以及如何搜索

在哪裏搜索 

告訴Elasticsearch在特定的類型和特定索引中進行查詢,也可以在同一個索引的多個字段中搜索,在多個索引中搜索或者在所有的索引中搜索。

爲了在多個類型中搜索,使用逗號分隔的列表。

通過向索引ULR的_search端點發送請求,可以在某個索引的多個類型中搜搜:

和類型類似,爲了在多個索引中搜索,用逗號分隔它們:

如果沒有事先創建other-index,這個特定的請求將會失敗。爲了忽略這種問題,可以像添加pretty旗標那樣添加ignore_unavailable旗標.爲了在所有的索引中搜索,徹底省略索引的名稱:

如果需要在所有索引內搜索,也可以使用名爲_all的佔位符索引名稱、當需要在全部索引中的同一個單獨類型中進行搜索時

http://localhost:9200/_all/event/_search.

這種關於 ‘在哪裏搜索’的靈活性,允許你在多個索引和類型中組織數據,具體方式取決於哪種對於你的使用案例更有意義。例如,日誌事件經常以基於時間的索引來組織,好比'logs-2013-03-03'等。這種設計意味着當天的索引是很熱門的:所有新的事件集中在這裏,並且多數的搜索也集中在最近的數據上。熱門的索引只包含所有數據的一部分,使得處理變得更容易。更快速。如果需要,仍然可以在舊的數據或全量數據裏搜索。

回覆的內容

JSON應答包含了所要求的信息,包括時間、分片、命中統計數據、文檔等。

如何搜索

通常,要將查詢放入組成請求的數據中。es允許使用JSON格式指定所有搜索條件。當搜索變得越來越複雜的時候,JSON更容易讀寫,並且提供了更多的功能。

例如,需要查詢所有分組信息;

 1.設置查詢的字符串現象

上述JSON請求最後一級有‘query’:‘elasticsearch’,你可能認爲‘query’部分是多餘的。因爲已經知道它就是一個查詢。這裏query_string提供了除字符串之外的更多選項。

例如,如果搜索‘elasticsearch san Francisco’,es默認查詢_all字段。如果想在分組的名稱裏查詢,需要指定:

"default_field":"name"

同樣,ES默認返回匹配了任一指定關鍵詞的文檔(默認操作符是OR).如果希望匹配所有的關鍵詞,需要指定:

"default_operator":"AND"

修改後的查詢看上去是下面這樣的:

2. 選擇合適的查詢類型 

如果query_string查詢類型看上去令人生畏,還有很多其他類型的查詢,比如,查找一個詞,term查詢可能更快捷,更直接。

3. 使用過濾器

目前爲主,你所見到的搜索請求都是查詢。查詢返回的結果中,每個結果都有一個得分。如果對得分不感興趣,可以使用過濾查詢來代替。

返回的結果和同樣詞條的查詢相同,但是結果沒有根據得分來排序,因爲所有的得分都是1.0

4. 應用聚集

除了查詢和過濾,還可以通過聚集進行各種統計。假如一個用戶正在訪問聚會網站,並且想探索各種已有的分組。你可能想展示分組的組織者是誰。爲了返回分組的組織者,可以使用詞條聚集。這回展示指定字段中出現的每個詞之計數器。

有時由於你並不清楚需求是什麼,從而無法搜索想要的。這個時候,聚集是很有用處的。有時面臨相反的場景。你明確地知道需要什麼,而且根本不想運行一次搜索。這個時候通過ID檢索文檔就很有用處。

通過ID獲取文檔

必須知道它所屬的索引和類型,以及它的ID,然後可以發送HTTP GET請求到這篇文檔的URI:

通過ID獲得文檔要比搜索更快,所消耗的資源成本也更低。這也是實時完成的:只要一個索引操作完成了,新的文檔就可以通過GET API獲取。相比之下,搜索是近實時的,因爲它們需要等待默認情況下每秒進行一次的刷新操作。 

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章