Document APIs 文檔接口
這一部分開始剪簡短介紹 Elasticsearch 的數據複製模型，接下來會詳解介紹下面的增刪改查接口（CRUD APIs）。
1. Single document APIs 單文檔操作接口
- Index API
- Get API
- Delete API
- Update API
2. Multi-document APIs 多文檔操作接口
- Multi Get API
- Bulk API
- Delete By Query API
- Update By Query API
- Reindex API
Reading and Writing documents 讀寫文檔
Introduction 介紹
在 Elasticsearch 中，每一個索引可以分片，而每一個分片可以有多個副本。當增加或刪除文檔的時候，它的這些副本集需要同步複製，否則，會出現不讀不同副本的數據結果返回不一致的情況。我們稱保持分片副本一致性和處理分片副本讀取的過程爲數據複製模型（data replication model）
Elasticsearch 的數據複製模型基於主備模型並且在微軟研究的PacificA論文中描述的非常清楚。模型是基於一個複製集中的單拷貝的朱分片。其他拷貝被稱爲複製分片。主分片作爲所有索引操作的主入口。挑戰在於校驗並確保這些主分片正確有效。當主分片接收到一個索引操作請求，它同時要對對其他副本的複製操作負責。
Basic write model 基本寫模型
在 Elasticsearch 中每個索引操作根據路由規則首先被分解到一個複製集，通常基於文檔ID。一旦複製集被選中，操作會被直接轉發到這個複製集的主分片。主分片負責校驗操作或者轉發操作到其他副本。因爲副本可能下線，主分片不需要將數據複製到所有副本。Elasticsearch 維護了一個可以接收操作的分片列表作爲替代方案。這個列表被稱爲in-sync副本被主節點持有。顧名思義，這組狀態“好”的分片拷貝，保證已經處理了所有已經被用戶確認的索引和刪除操作。
Failure handling 失敗處理
索引的過程當中可能會發生任何意想不到的事情-儘管主節點運行良好，二磁盤崩潰，節點之間不能通信，以及一些配置丟失都可能導致副本上的操作失敗。以上雖然很少發生，但主分片必須對此負責。
當主分片自己失敗的時候，持有主分片的節點會發送消息給Master。索引操作會等待（默認最多1分鐘）master重新選舉出一個副本爲新的主分片。索引操作會被轉發到新的主分片處理。比較典型的是當持有主分片的節點因爲網絡問題與集羣是回去聯繫會出現這種情況。
Basic read model 基本度模型
未完待續……
A few simple implications
Failures
The Tip of the Iceberg
