ElasticSearch怎樣加入,檢索資料

2021-09-22 11:14:16 字數 3268 閱讀 1860

elasticsearch是乙個分布式的文件(document)儲存引擎。它能夠實時儲存並檢索複雜資料結構——序列化的json文件。換言說,一旦文件被儲存在elasticsearch中,它就能夠在集群的任一節點上被檢索。

當然,我們不僅須要儲存資料。還要高速的批量查詢。儘管已經有非常多nosql的解決方式同意我們以文件的形式儲存物件,但它們依然須要考慮怎樣查詢這些資料,以及哪些字段須要被索引以便檢索時更加高速。

程式中大多的實體或物件可以被序列化為包括鍵值對的json物件,

鍵(key)

是字段(field)

或屬性(property)

的名字,

值(value)

可以是字串、數字、波爾型別、還有乙個物件、值陣列或者其它特殊型別,比方表示日期的字串或者表示地理位置的物件。

文件元資料(document metadata):

乙個文件不僅僅有資料。它還包括了元資料(metadata)——關於文件的資訊。

三個必須的元資料節點是:

節點說明

_index文件儲存的地方

_type文件代表的物件的類

_id文件的唯一標識

索引(index)類似於關係型資料庫裡的「資料庫」——它是我們儲存和索引關聯資料的地方。

其實,我們的資料被儲存和索引在

分片(shards)

中,索引僅僅是乙個把乙個或多個分片分組在一起的邏輯空間。然而,這僅僅是一些內部細節——我們的程式全然不用關心分片。對於我們的程式而言,文件儲存在

索引(index)

中。剩下的細節由elasticsearch關心既可。

後面會繼續**怎樣建立並管理索引。但如今,我們將讓elasticsearch為我們建立索引。我們唯一須要做的不過選擇乙個索引名。這個名字必須是所有小寫。不能下面劃線開頭,不能包括逗號。

讓我們使用website做為索引名。

在關係型資料庫中,我們常常將同樣類的物件儲存在乙個表裡。由於它們有著同樣的結構。同理,在elasticsearch中,我們使用同樣型別(type)的文件表示同樣的「事物」。由於他們的資料結構也是同樣的。

_type的名字能夠是大寫或小寫,不能包括下劃線或逗號。

我們將使用blog做為型別名。

id不過乙個字串。它與_index_type組合時。就能夠在elasticsearch中唯一標識乙個文件。

當建立乙個文件。你能夠自己定義_id,也能夠讓elasticsearch幫你自己主動生成。

ps:還有其他部分其他元資料,興許再介紹。

假設你的文件有自然的識別符號(比如user_account字段或者其它值表示文件)。你就能夠提供自己的_id,使用這樣的形式的indexapi:

put ///
{"key": "value"...}
如,put /website/blog/123

elasticsearch中每乙個文件都有版本,每當文件變化(包含刪除)都會使_version新增。興許我們將**怎樣使用_version號確保你程式的一部分不會覆蓋掉還有一部分所做的更改。

假設我們的資料沒有自然id。我們能夠讓elasticsearch自己主動為我們生成。請求結構發生了變化:put方法——「在這個url中儲存文件」變成了post方法——"在這個文件下儲存文件"

(注:原來是把文件儲存到某個id相應的空間。如今是把這個文件加入到某個_type下)。

url如今僅僅包括_index_type兩個字段:

post /website/blog/

響應內容與剛才類似。僅僅有_id字段變成了自己主動生成的值:

文件在elasticsearch中是不可變的——我們不能改動他們。假設須要更新已存在的文件,我們能夠使用《索引文件》提到的indexapi 重建索引(reindex) 或者替換掉它。

put /website/blog/123

在響應中。我們能夠看到elasticsearch把_version新增了。

在內部,elasticsearch已經標記舊文件為刪除並加入了乙個完整的新文件。

舊版本號文件不會馬上消失。但你也不能去訪問它。elasticsearch會在你繼續索引很多其它資料時清理被刪除的文件。

在後面**updateapi。這個api 似乎 同意你改動文件的區域性。但其實elasticsearch遵循與之前所說全然同樣的過程,這個步驟例如以下:

從舊文件中檢索json

改動它刪除舊文件

索引新文件

唯一的不同是updateapi完畢這一過程僅僅須要乙個client請求既可。不再須要getindex請求了。

刪除文件的語法模式與之前基本一致,僅僅只是要使用delete方法:

delete /website/blog/1234
假設文件被找到,elasticsearch將返回200 ok狀態碼和下面響應體。注意_version數字已經新增了。

假設文件未找到。我們將得到乙個404 not found狀態碼,響應體是這種:

雖然文件不存在——"found"的值是false——_version依然新增了。

這是內部記錄的一部分。它確保在多節點間不同操作能夠有正確的順序。

刪除乙個文件也不會馬上從磁碟上移除,它僅僅是被標記成已刪除。

elasticsearch將會在你之後加入很多其它索引的時候才會在後台進行刪除內容的清理。

elasticsearch配置詳解

elasticsearch的config資料夾裡面有兩個配置檔案 elasticsearch.yml和logging.yml,第乙個是es的基本配置檔案,第二個是日誌配置檔案,es也是使用log4j來記錄日誌的,所以logging.yml裡的設定按普通log4j配置檔案來設定就行了。下面主要講解下e...

誰在使用Elasticsearch

github github使用elasticsearch搜尋20tb的資料,包括13億的檔案和1300億行的 這個不用介紹了吧,碼農們都懂的,github在2013年1月公升級了他們的 搜尋,由solr轉為elasticsearch,目前集群規模為26個索引儲存節點和8個客戶端節點 負責處理搜尋請求...

elasticsearch配置說明

elasticsearch.yml是elasticsearch主要的配置檔案,所有的配置都在這個檔案裡完成,一般情況下,預設的配置已經可以比較好地執行乙個集群了,但你也可以對其進行微調。在環境變數中的引數可以用來作為配置引數的值,比如配置檔案裡舉的乙個例子為 node.rack 再比如 等。下面對其...