第一章-准備工作
關注公眾號：CoderBuff，回復“es”獲取《ElasticSearch6.x實戰教程》完整版PDF。
工欲善其事必先利其器
ElasticSearch安裝
ElasticSearch6.3.2下載地址（Linux、mac OS、Windows通用，下載zip包即可）：https://www.elastic.co/cn/downloads/past-releases/elasticsearch-6-3-2。ES歷史版本下載頁面：https://www.elastic.co/cn/downloads/past-releases#elasticsearch。
在正式安裝前，你需要確保你的系統已配置JDK8環境。
mac OS
在上述下載地址下載完elasticsearch-6.3.2.tar.gz后，首先在當前登錄用戶的home下創建一個Settings目錄，通過tar -zxvf elasticsearch-6.3.2.tar.gz解壓到當前目錄。
進入elasticsearch-6.3.2.tar.gz目錄，執行./bin/elasticsearch命令，等待一小段時間，通過瀏覽器訪問http://localhost:9200/?pretty出現以下響應：
{
"name": "x4x7wWJ",
"cluster_name": "elasticsearch",
"cluster_uuid": "sJ6LTYJ1TDmtR1kzl0M2Ig",
"version": {
"number": "6.3.2",
"build_hash": "8bbedf5",
"build_date": "2017-10-31T18:55:38.105Z",
"build_snapshot": false,
"lucene_version": "6.6.1"
},
"tagline": "You Know, for Search"
}
Linux
Linux的安裝過程和Linux相同。
ES需要使用普通用戶安裝、啟動，如果你是root用戶，需要先創建一個用戶，用普通用戶而不是root用戶啟動ES。
第二章-基本術語
白馬非馬
ES是一個搜索引擎，同時它也是一個分布式文檔存儲數據庫（當然是非關系型的）。為了保證后續的實戰教程順利進行，這里通過對比傳統的關系型數據庫MySQL介紹在ES中的一些術語。
在MySQL中共有數據庫（Database）、表（Table）、記錄（Row）、列（Column）的概念，同樣在ES中也有類似的概念，索引（Index），類型（Type），文檔（Document），字段（Field）。
可以這么理解：
| 數據庫 | 表 | 記錄 | 列 | |
|---|---|---|---|---|
| MySQL | DB | Table | Row | Column |
| ES | Index | Document | Document | Field |
索引Index
ES中的索引概念可不是關系型數據庫中的“索引”，ES中的索引指的是存儲數據的地方，類似關系型數據庫中的數據庫概念。
類型Type
有的文章指出ES中的類型Type對應的就是關系型數據庫中的表，在使用ES中我們會遇到另外一個概念映射（Mapping），也有不少的文章指出Mapping對應的就是關系型數據庫中的表。關系型數據庫中表與表是物理獨立的，即使在兩個表中存在相同名稱不同類型的列，這在我們的關系型數據庫也是極為合理的，但這在ES中就不合理，ES中即使是在同一個索引Index下，如果字段Field存在於不同的類型Type中，即使他們代表不同的含義，但是只要它們的名稱相同也必須要求類型相同，在ES中類型Type對應於關系型數據庫中表的概念已經名存實亡。實際上在ES中Type作為表的概念在后期版本中越來越被弱化，在未被ES正式移除前，ES后期版本已經不允許一個索引Index創建多個Type，相信在后面的版本會徹底移除類型Type。
（注：ES6已經不允許一個Index創建多個Type，https://github.com/elastic/elasticsearch/pull/24317）
如果在現階段一定要理解ES中的Type，那么一定要和Mapping結合起來。可以理解為類型Type就是定義一個表，僅僅是定義而已，而映射Mapping定義了表結構（有哪些列，列的類型是什么）。
文檔Document
在非關系型數據庫中，有部分被稱之為“文檔數據庫”，對應於關系型數據庫中的一行記錄。
字段Field
對應關系型數據庫中的列。
節點
一個ES實例稱之為一個節點，單機部署的ES有且只有一個節點，集群部署的ES有多個節點且有一個主節點。
分片
ES可作為分布式集群部署，同樣也可以作為單機單節點部署。ES中的數據被分散存儲在分片中，ES屏蔽了底層的分片實現，我們直接與索引交互而不與分片交互。分片數量的多少與是否是集群部署和單機部署無關，即使是單機部署在創建索引時仍然也可以指定划分多個分片（默認5個主分片1份備份（包含5個備分片））。分片有主分片和備分片之分，顧名思義，備分片是主分片的備份，當主分片出現故障時，備份片充當主分片。
對於單機部署
單機部署的ES，即表示ES有且只有一個節點，在創建索引時，如果不指定主分片與備分片的數量，默認創建5個主分片和1份備份（5個備分片），實際上對於單機部署的ES服務來講，多個主分片並沒有意義，多個分片存在的意義本身就是將數據分散存儲到多個ES節點中進行同時查詢，此時只有一個節點多個分片也沒有意義。備分片在單機部署中同樣也沒有意義，備份存在的意義本身就是當主分片故障時，仍然能對外提供服務，此時主備都在一個節點上，如果主分片故障，備分片也同樣會導致故障。
對於集群部署
對於集群部署的ES來講，此時存在多個節點，主分片的分配與備分片機制就顯得尤為重要（這涉及查詢性能以及服務高可用），例如現在有3個節點，此時如果在創建索引時只分配1個主分片就顯得有點浪費（注：主分片一旦在創建索引時確定便不能修改）。主分片的划分並沒有一定放之四海而皆准的規則，更多的是取決於用戶的數據量以及ES節點數量等。通常所理解的是，分片數量越多越好，因為這能將數據分散到不同分片，以便以后在擴容新增節點時，ES能將自動將分片重新進行均勻分布。但這條理論也不絕對，如果你的節點只有3個，設置了100個分片，每個節點就有33個節點，當搜索請求調度到同一節點的不同分片時，此時會引發硬件資源（CPU）的搶奪，造成性能問題。反過來，如果3個節點只分配了3個分片，隨着業務的發展，數據量越來越大，單個分片已不能承受它最大的數據量，此時就算新增節點，但是分片數量只有3個，分片的數量在創建索引時便確定且不可修改，此時只能通過重新創建索引。
既要對合理的數據增長有一個判斷（規划較大的分片），又要對期望有一個度的把握（合理的分片數量）。官方給出了一點建議，每個分片的數據量最好是在20G~40G左右，這就意味着如果你有4個節點，數據量預估在200G左右甚至更大，此時分片數量設置為5~10個比較合適，7、8個差不多，每個節點有2個分片。（官方博客的建議，https://www.elastic.co/cn/blog/how-many-shards-should-i-have-in-my-elasticsearch-cluster）
上面談到的是主分片，副分片的划分也同等重要。如果不對分片備份，主分片故障則導致數據丟失，部分數據不可查詢。副本分片設置過多造成額外的存儲空間，默認情況下，創建索引時會創建一個分片副本（一個分片副本不代表一個備分片，如果有5個主分片，那么分片副本就有5個備分片，同理如果指定創建兩個分片副本，此時一共就有10個備分片。）需要注意的是備分片是可以修改的，所以備分片可以直接采用默認一個分片副本。
關注公眾號：CoderBuff，回復“es”獲取《ElasticSearch6.x實戰教程》完整版PDF。
