Java API
Elasticsearch 為Java用戶提供兩種內置客戶端：
節點客戶端（node client）：
節點客戶端已無數據節點（none data node）身份加入集群，換言之，它自己不存儲任何數據，但是它知道數據在集群中的具體位置，並且能夠直接轉發請求到對應的節點上。
傳輸客戶端（transport client）：
這個更輕量的傳輸客戶端能夠發送請求到遠程集群。它自己不加入集群，只是簡單的轉發請求給集群中的節點。
兩個Java客戶端都通過9300端口與集群交互，使用Elasticsearch 傳輸協議（Elasticsearch Transport Protocol）。集群中的節點 之間通過9300端口進行通信。如果此端口為開發，你的節點 講不能組成集群。
tip：Java客戶端所在的Elasticsearch版本必須與集群中其他節點一致，否則，它們可能互相無法識別。
基於HTTP協議，一JSON為數據交互格式的RESTFUL API
其他所有程序語言都可以使用RESTFUL API，通過9200端口與Elasticsearch進行通信，你可以使用你喜歡的ＷＥＢ客戶端，事實上，如你所見，你甚至可以通過curl命令與Elasticsearch通信
NOTE Elasticsearch官方提供了多種程序語言的客戶端 ---——Groovy，Javascript， .NET，PHP，Perl，Python，以及 Ruby——還有很多由社區提供的客戶端和插件，所有這些可以在文檔中找到。
向Elasticsearch 發出請求的組成部分與其他普通的HTTP請求是一樣的：
curl -X<verb> <PROTOCOL>://<HOST>/<PATH>?<QUERY_STRING> -d<BODY>
verb HTTP 方法：GET , POST, PUT, HEAD, DELETE
PROTOCOL HTTP或者HTTPS協議（只有在Elasticsearch 前面有https代理的時候可用）
HOST Elasticsearch集群中的任何一個節點主機名，如果在本地節點，那么就叫localhost
PORT Elasticsearch http服務所在的端口 默認為9200
QUERY_STRING 一些可選的查詢請求參數，例如？pretty參數講請求返回更加美觀易讀的JSON數據
BODY 一個JSON格式的請求主體（如果請求需要的話）
舉例說明，為了計算集群中的文檔數據量，我們可以這樣做：
curl -XGET http://localhost:9200/_count?pretty? -d
{
"query":{
"math_all":{}
}
}
Elasticsearch返回一個類似 200 OK 的HTTP狀態碼和JSON格式的響應主體（除了 HEAD 請求）。上面的請求會得到如下的
JSON格式的響應主體：
{
"count" : 0,
"_shards" : {
"total" : 5,
"successful" : 5,
"failed" : 0
}
}
面向文檔
應用中的對象很少只是簡單的鍵值列表，更多時候，它擁有復雜的數據結構，比如包含日期、地理位置、另一個對象或者數組。
總有一天，你會想把這些對象存儲到數據庫中。將這些數據保存到由行和列組成的關系數據庫中，就好像是把一個豐富，信息表現力強的對象 拆散了放入一個非常大的表格中：你不得不拆散對象以適應表模式（通常一列表示一個字段），然后又不得不在查詢的時候重建它們。
Elasticsearch是面向文檔（document oriented）的，這意味着它可以存儲整個對象或文檔。然而它不僅僅是存儲，還會索引每個文檔的內容之所以被搜索。在Elasticsearch中，你可以對文檔（而非成行成列的數據）進行索引、搜索、排序、過濾。這種理解數據的方式與以往完全不同，這也是Elasticsearch能夠執行復雜的全文搜索的原因之一。
JSON
Elasticsearch 使用Javascript對象符號（JavaScript Object Notation），也就是JSON，作為文檔序列化格式。JSON現在已經被大多語言所支持，而且已經成為ＮＯＳＱＬ領域的標准格式。它簡潔、簡單且容易閱讀。
{
"email": "john@smith.com",
"first_name": "John",
"last_name": "Smith",
"info": {
"bio": "Eco-warrior and defender of the weak",
"age": 25,
"interests": [ "dolphins", "whales" ]
},
"join_date": "2014/05/01"
}
盡管原始的user對象很復雜，但它的結構和對象的含義已經被完整的體現在ＪＳＯＮ中了在Elasticsearch中將對象轉化為JSON 並做索引要比在biao結構中做相同的事情簡單的多
ＮＯＴＥ
盡管幾乎所有的語言都有相應的模塊用於將任意數據結構轉換為JSON，但每種語言處理細節不同。具體請查看serialization or marshalling 兩個用於處理JSON的模塊。Elasticsearch官方客戶端會自動為你序列化和反序列化JSON
Relational DB --> Databases -->Tables --> Rows --> Columns
Elasticsearch --> Indices -->Types --> Documents --> Fieds
Elasticsearch致力於隱藏分布式系統的復雜性。以下這些操作都是在底層自動
完成的：
1、將你的文檔分區到不同的容器或者分片(shards)中，它們可以存在於一個或
多個節點中。
2、將分片均勻的分配到各個節點，對索引和搜索做負載均衡。
3、冗余每一個分片，防止硬件故障造成的數據丟失。
將集群中任意一個節點上的請求路由到相應數據所在的節點。
4、無論是增加節點，還是移除節點，分片都可以做到無縫的擴展和遷移。
Elasticsearch 是一種分布式數據存儲引擎，實時存儲並檢索復雜數據結構---
序列化的JSON文檔。分片在索引創建的時候被指定，此后主分片不可變，復制分
片可以改變，復制分片：應對故障，防止丟失數據。w
文檔
對象是一個JSON結構體。文檔特指最頂層結構或者跟對象序列化成的JSON
數據（以唯一ID標識並存儲於Elasticsearch中）
一個文檔不只有數據。它還包含了元數據，三個必須的元數據節點：
_index
我們的數據被存儲和索引在分片(shards)中，索引只是一個把一個或多個分片分組在一起的邏輯空間
命名規則：這個名字必須是全部小寫，不能以下划線開頭，不能包含逗
_type
_type 的名字可以是大寫或小寫，不能包含下划線或逗號。
_id
id僅僅是一個字符串，它與 _index 和 _type 組合時，就可以在ELasticsearch中唯一標識一個文檔。當創建一個文檔，你可以
自定義 _id ，也可以讓Elasticsearch幫你自動生成。
自動生成的ID有22個字符長，URL-safe, Base64-encoded string universally unique identifiers, 或者叫 UUIDs