(四)ElasticSearch之数据
0、概述
在Elasticsearch中,每一個字段的數據都是默認被索引的。也就是說,每個字段專門有一個反向索引用于快速檢索。而且,與其它數據庫不同,它可以在同一個查詢中利用所有的這些反向索引,以驚人的速度返回結果。
1、文檔
程序中大多的實體或對象能夠被序列化為包含鍵值對的JSON對象,鍵(key)是字段(field)或屬性(property)的名字,值(value)可以是字符串、數字、布爾類型、另一個對象、值數組或者其他特殊類型,比如表示日期的字符串或者表示地理位置的對象。
{"name": "John Smith","age": 42,"confirmed": true,"join_date": "2014-06-01","home": {"lat": 51.5,"lon": 0.1},"accounts": [{"type": "facebook","id": "johnsmith"},{"type": "twitter","id": "johnsmith"}] }通常,我們可以認為對象(object)和文檔(document)是等價相通的。不過,他們還是有所差別:對象(Object)是一個JSON結構體——類似于哈希、hashmap、字典或者關聯數組;對象(Object)中還可能包含其他對象(Object)。 在Elasticsearch中,文檔(document)這個術語有著特殊含義。它特指最頂層結構或者根對象(root object)序列化成的JSON數據(以唯一ID標識并存儲于Elasticsearch中)。
一個文檔不只有數據。它還包含了元數據(metadata)——關于文檔的信息。三個必須的元數據節點是:
| _index | 文檔存儲的地方 |
| _type | 文檔代表的對象的類 |
| _id | 文檔的唯一標識 |
2、索引
- 索引一個文檔
文檔通過index?API被索引——使數據可以被存儲和搜索。但是首先我們需要決定文檔所在。正如我們討論的,文檔通過其_index、_type、_id唯一確定。們可以自己提供一個_id,或者也使用index?API 為我們生成一個。
- 使用自己的ID
如果你的文檔有自然的標識符(例如user_account字段或者其他值表示文檔),你就可以提供自己的_id,使用這種形式的index?API:
# _id就等于你設置的id PUT /{index}/{type}/{id} {"field": "value",... }例如我們的索引叫做“website”,類型叫做“blog”,我們選擇的ID是“123”,那么這個索引請求就像這樣:
PUT /website/blog/123 {"title": "My first blog entry","text": "Just trying this out...","date": "2014/01/01" }Elasticsearch的響應:
{"_index": "website","_type": "blog","_id": "123","_version": 1,"created": true }響應指出請求的索引已經被成功創建,這個索引中包含_index、_type和_id元數據,以及一個新元素:_version。Elasticsearch中每個文檔都有版本號,每當文檔變化(包括刪除)都會使_version增加。
- 自增ID
響應內容與剛才類似,只有_id字段變成了自動生成的值:
{"_index": "website","_type": "blog","_id": "wM0OSFhDQXGZAWDf0-drSA","_version": 1,"created": true }自動生成的ID有22個字符長,URL-safe, Base64-encoded string universally unique identifiers, 或者叫?UUIDs。
3、獲取
- 檢索文檔
- 檢索文檔的一部分
4、存在
# 只是檢查文檔是否存在 # 存在200 OK,不存在404 Not Found HEAD /website/blog/1235、更新
# Elasticsearch把_version增加了 PUT /website/blog/123 {"title": "My first blog entry","text": "I am starting to get the hang of this...","date": "2014/01/02" }6、創建
請記住_index、_type、_id三者唯一確定一個文檔。
# Elasticsearch自動生成唯一_id,再次執行,又生成一個_id POST /website/blog/ { ... }然而,如果想使用自定義的_id,我們必須告訴Elasticsearch應該在_index、_type、_id三者都不同時才接受請求。為了做到這點有兩種方法,它們其實做的是同一件事情。你可以選擇適合自己的方式:
# 123存在則報錯提示文檔已經存在,否則創建 # 或者使用PUT /website/blog/123/_create PUT /website/blog/123?op_type=create {"title": "My first blog entry","text": "Just tryinsssssg this out...","date": "2014/01/01" }7、刪除
# 刪除id=123的文檔 DELETE /website/blog/123# 刪除blog刪除索引 DELETE /website/8、局部更新
我們也說過文檔是不可變的——它們不能被更改,只能被替換。update?API必須遵循相同的規則。表面看來,我們似乎是局部更新了文檔的位置,內部卻是使用update檢索-修改-重建索引流程;
# 添加tags字段 POST /website/blog/123/_update {"doc" : {"tags" : [ "testing" ],"views": 0} }9、檢索多個文檔(Mget)
像Elasticsearch一樣,檢索多個文檔依舊非常快。合并多個請求可以避免每個請求單獨的網絡開銷。如果你需要從Elasticsearch中檢索多個文檔,相對于一個一個的檢索,更快的方式是在一個請求中使用multi-get或者mget?API。
# mget API參數是一個docs數組,數組的每個節點定義一個文檔的_index、_type、_id元數據。 # 如果你只想檢索一個或幾個確定的字段,也可以定義一個_source參數: POST /_mget {"docs" : [{"_index" : "website","_type" : "blog","_id" : 2},{"_index" : "website","_type" : "pageviews","_id" : 1,"_source": "views"}] }響應體也包含一個docs數組,每個文檔還包含一個響應,它們按照請求定義的順序排列。每個這樣的響應與單獨使用get?request響應體相同
{"docs" : [{"_index" : "website","_id" : "2","_type" : "blog","found" : true,"_source" : {"text" : "This is a piece of cake...","title" : "My first external blog entry"},"_version" : 10},{"_index" : "website","_id" : "1","_type" : "pageviews","found" : true,"_version" : 2,"_source" : {"views" : 2}}] }10、批量
就像mget允許我們一次性檢索多個文檔一樣,bulk?API允許我們使用單一請求來實現多個文檔的create、index、update或delete。這對索引類似于日志活動這樣的數據流非常有用,它們可以以成百上千的數據為一個批次按序進行索引。
POST /_bulk { "delete": { "_index": "website", "_type": "blog", "_id": "123" }} <1> { "create": { "_index": "website", "_type": "blog", "_id": "123" }} { "title": "My first blog post" } { "index": { "_index": "website", "_type": "blog" }} { "title": "My second blog post" } { "update": { "_index": "website", "_type": "blog", "_id": "123", "_retry_on_conflict" : 3} } { "doc" : {"title" : "My updated blog post"} } <2>11、參考
?
?
?
?
?
總結
以上是生活随笔為你收集整理的(四)ElasticSearch之数据的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 毛玻璃效果
- 下一篇: command对象提供的3个execut