《ElasticSearch6.x實戰教程》之準備工作、基本術語

OKevin發表於2019-07-17
Elasticsearch

第一章-準備工作

工欲善其事必先利其器

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，回覆“抽獎”參與《從Lucene到Elasticsearch：全文檢索實戰》圖書抽獎活動（7.17-7.21）。

這是一個能給程式設計師加buff的公眾號 （CoderBuff）
《ElasticSearch6.x實戰教程》之準備工作、基本術語

相關文章