索引中最基本的單元叫作文檔 document. 在es中文檔的示例以下:web
{ "_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自帶的字段併發
這裏的索引,類型,文檔,字段的概念不少文章都作一個關係型數據的對比。curl
我如今有一個user表,這個user表有個type字段,0/1表明是男仍是女,這個表的每條數據就表明一我的,它擁有名稱,電話等屬性。elasticsearch
對應於es,表就至關於索引,男女的字段至關於type,每條數據就是一個document,名稱電話等屬性就是一個字段。ui
上面能夠看到es的文檔中有個_version字段,當兩個併發請求要修改文檔的時候,es使用的是樂觀鎖。
在es中,更新請求其實是分爲兩個階段,獲取文檔,修改文檔,而後保存文檔。
那麼當兩個更新請求同時要修改文檔的時候,系統樂觀的認爲不會有兩個併發請求對一個系統操做。this
文檔本來的版本爲1,請求A獲取了version爲1的文檔,請求B也獲取了version爲1的文檔,而後請求A修改完文檔後,而且先執行了保存操做,這個時候,系統中的文檔version變爲了2。
這個時候,B再執行保存操做的時候,告訴系統我要修改version爲1的文檔。系統就會拋出一個錯誤,說文檔版本不匹配。而後這個錯誤由應用程序本身來進行控制。url
這種機制在請求量大的時候會比悲觀鎖機制好。可是缺點是須要程序處理版本衝突錯誤,可能通常的方法是封裝更新操做,而且設置重複重試次數。版本控制
POST /website/blog/ -d { id: 123, name: "blog123" }
增長操做若是制定的文檔已經存在了,就會返回409錯誤code
DELETE /website/blog/123
若是文檔沒有存在,則返回404blog
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" } ] }