elasticsearch 文檔
文檔格式
索引中最基本的單元叫做文檔 document. 在es中文檔的示例如下:
{
"_index": "questions",
"_type": "baichebao",
"_id": "4",
"_score": 1,
"_version" : 1,
"_source": {
"id": 4,
"content": "汽車常見故障的解決辦法有哪些?",
"uid": 1,
"all_answer_count": 2,
"series_id": 0,
"score": 0,
"answer_count": 2
}
}
文檔中下划線開頭的是es自帶的字段
- _index 代表索引名
- _type 代表類型
- _id 代表文檔id,如果插入文檔的時候沒有設置id的話,那么es會自動生成一個唯一id
- _score 這個不是文檔自帶的,而是進行搜索的時候返回的,代表這個文檔和搜索的相關匹配分值
- _source 儲存原始文本及分類好的字段
- _version 代表這個文檔的版本
這里的索引,類型,文檔,字段的概念很多文章都做一個關系型數據的對比。
我現在有一個user表,這個user表有個type字段,0/1代表是男還是女,這個表的每條數據就代表一個人,它擁有名稱,電話等屬性。
對應於es,表就相當於索引,男女的字段相當於type,每條數據就是一個document,名稱電話等屬性就是一個字段。
版本控制
上面可以看到es的文檔中有個_version字段,當兩個並發請求要修改文檔的時候,es使用的是樂觀鎖。
在es中,更新請求實際上是分為兩個階段,獲取文檔,修改文檔,然后保存文檔。
那么當兩個更新請求同時要修改文檔的時候,系統樂觀的認為不會有兩個並發請求對一個系統操作。
文檔原本的版本為1,請求A獲取了version為1的文檔,請求B也獲取了version為1的文檔,然后請求A修改完文檔后,並且先執行了保存操作,這個時候,系統中的文檔version變為了2。
這個時候,B再執行保存操作的時候,告訴系統我要修改version為1的文檔。系統就會拋出一個錯誤,說文檔版本不匹配。然后這個錯誤由應用程序自己來進行控制。
這種機制在請求量大的時候會比悲觀鎖機制好。但是缺點是需要程序處理版本沖突錯誤,可能一般的方法是封裝更新操作,並且設置重復重試次數。
增刪改查操作
增加:
POST /website/blog/ -d
{
id: 123,
name: "blog123"
}
增加操作如果制定的文檔已經存在了,就會返回409錯誤
刪除:
DELETE /website/blog/123
如果文檔沒有存在,則返回404
更新:
PUT /website/blog/123
{
"title": "My first blog entry",
"text": "I am starting to get the hang of this...",
"date": "2014/01/02"
}
更新的時候往往有個操作就是“如果有數據,則更新,如果沒有數據,則創建”
可以用upsert
curl -XPOST 'localhost:9200/test/type1/1/_update' -d '{
"script" : "ctx._source.counter += count",
"params" : {
"count" : 4
},
"upsert" : {
"counter" : 1 // 如果沒有id為1的文檔,則創建,並且設置counter為1
}
}'
curl -XPOST 'localhost:9200/test/type1/1/_update' -d '{
"doc" : {
"name" : "new_name"
},
"doc_as_upsert" : true // 如果沒有文檔,則doc就是新的文檔
}'
更新必須明確的一點是,es中的文檔的更新操作實際上是執行了兩步,獲取文檔,更新文檔,然后再保存文檔。
查:
GET /website/blog/123
如果你已經知道一批文檔id了,那么你可以使用批量查的功能
GET /_mget
{
"docs" : [
{
"_index" : "website",
"_type" : "blog",
"_id" : 2
},
{
"_index" : "website",
"_type" : "pageviews",
"_id" : 1,
"_source": "views"
}
]
}