上一篇文章 我們把 Elasticsearch 在本地建立起來後，今天就要介紹 Elasticsearch 的基本架構。

Cluster 以及 Node

運行的 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 的基本架構，我們可以統整出一個結論：

1. 節點是執行 Elasticsearch 所需的最小單位
2. document 是 儲存資料 最小的單位
3. index 可以儲存多個 documents
4. 一個節點可以儲存多個相同的 index
5. 一個節點必定隸屬於一個叢集，即便我們只有一個節點