該文章同步發佈於:我的部落格
也歡迎關注我的 Facebook 以及 Instagram 接收軟體相關的資訊!
上一篇文章 我們把 Elasticsearch 在本地建立起來後,今天就要介紹 Elasticsearch 的基本架構。
運行的 Elasticsearch 實體中最小的單位是 node,中文叫做節點,而節點一定會隸屬於 cluster,也可以叫做叢集 ( 集群應該是中國的用語 )。
我們在 上一篇文章 利用 Docker 加上參數 single-node 啟動了 1 個節點的服務。
而這邊對於節點可能會有些疑問,節點代表的是機器嗎?還是電腦呢?都不是,沒有規定一個機器或電腦只能運行一個節點,相反的,在你的電腦上,你想同時啟動 5 個節點都是可以的。
當節點增加之後,問題就隨之而來,節點之間是如何傳遞資料呢?又是如何確保資料的正確性?
答案是:這些都是叢集的工作,之後會再仔細地說明
而當我們使用 single-node 啟動 Elasticsearch 的瞬間,意味著也把現在這個節點設立為主節點,並且會自動被加入預設叫做 elasticsearch 的叢集。
所以有節點,就一定有叢集。
至於為什麼要在本地使用 single-node 呢?不想要耗費太多的記憶體,避免繁雜的設定,當我們使用 single-node 時,也同時告訴 Elasticsearch 略過一些和叢集相關的啟動檢查。
但在 Production 的環境上,還是建議使用多節點的方式來分散風險是一種更好的做法。
在節點中,我們儲存資料的最小單位叫做 document,有另外一種讓人更快進入狀況的方式就是,可以把它想像成 SQL 的 row,每一筆的概念,這樣可以更快的理解這些用語,但在實際上儲存的內容還是有很多的不同。
下面是一個範例,想像我們將 JSON 的物件送到 Elasticsearch 並且儲存成為一個 document。
// 送到 Elasticsearch
{
"name": "Robert",
"address": "xxx",
"phone": "09xx-xxx-xxx"
}
它會被轉換成這樣儲存,而我們可以說,這就是一個 document:
{
"_index": "membership",
"_type": "_doc",
"_id": "456",
"_version": 1,
"_seq_no":0,
"_primary_term": 1,
"_source": {
"name": "Robert",
"address": "xxx",
"phone": "09xx-xxx-xxx"
}
}
好的,當我們了解如何儲存最小資料單位到節點後,接著來的問題是,Elasticsearch 如何組織這些資料呢?我們都知道 Elasticsearch 最厲害的就是搜尋,而在傳統的認知中,我們會使用資料庫的外部鍵來替表格之間建立關聯,那 Elasticsearch 是怎麼做這件事呢?
答案是 Index。
想像 index 就是 SQL 的表個負責儲存這些 documents,而我們在搜尋時,會針對一個或是多個 index 進行搜尋。
所以我們會把相關連的 documents 放到同一個 index 中,可以看到上面的 document 中 index 是顯示 membership,也就說明了這個 index 儲存的是和會員相關的資料。
所以我們可以說,一個節點可以儲存多個 index 的 shared,而每一個 index 又會儲存多個 documents。
為什麼不是儲存多個 index 而是 index 的 shared 呢?
這在之後會解釋,但我們要有一個認知,一個節點是可以儲存相同且多個 index 的,這和傳統的關聯式資料庫有所不同。
Q: 有可能叢集內沒有節點嗎?
不可能。叢集至少需要有一個節點。如果沒有節點,叢集實際上就不存在了。
當我們啟動 Elasticsearch,至少啟動了一個節點,這個中點就會自動成為所屬叢集的一部分。
Q: 可以建立一個沒有叢集的節點嗎?
不可以。當您啟動一個 Elasticsearch 節點,它總是屬於某個叢集。
預設情況下,該節點會嘗試加入名為 elasticsearch
的叢集,除非在設定中指定了其他的叢集名稱。但無論如何,一個節點總是屬於某個叢集。
關於 Elasticsearch 的基本架構,我們可以統整出一個結論: