第一章-準備工作

工欲善其事必先利其器

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）。

可以這麼理解：

索引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。