基本概念

• 文檔（Document）

  • es是面向文檔的，文檔是所有可搜索數據的最小單位

  • 文檔會被序列化為JSON格式，保存在es中

  • 每個文檔都有一個Unique ID

    • 可以自己指定
    • 也可以由es自動生成

  • 示例

    {"year": 1995,"@version": "1","genre": ["Adventure", "Animation","Children", "Comedy", "Fantasy"],"id": "1","title": "Toy Story" }

  • 文檔的元數據

    {"_index": "movies", // 文檔所在的索引名"_type": "_doc", // 文檔所屬的類型名"_id": "1", // 文檔的uid"_score": 14.69302, // 相關性打分"_source": { // 文檔的原始json數據"year": 1995,"@version": "1", // 文檔的版本信息"genre": ["Adventure", "Animation","Children", "Comedy", "Fantasy"],"id": "1","title": "Toy Story"} }

    其他：_all整合所有字段內容到該字段，已被廢除

• 索引（index）

  • 索引是文檔的容器，是一類文檔的集合（類似于mongo中的集合）
    • Index體現邏輯空間的概念，每個索引都有自己的Mapping定義，用于定義文檔的字段及類型（類似于表結構schema）
    • Shard體現物理空間的概念，索引中的數據分散在Shard上
  • Mapping和Settings
    • Mapping等一文檔字段及類型
    • Settings定義不同的數據分布
  • 其他語義：保存一個文檔到es中的過程，也叫索引（indexing）

• Type

  • 7.0開始，一個Index只能創建一個Type，也就是_doc

分布式系統

• 高可用性

  • 服務可用性：允許有節點停止服務
  • 數據可用性：部分節點丟失，不會丟失數據

• 可擴展性

  • 請求量提升 / 數據不斷增長，將數據分布到所有節點上（存儲的水平擴展）

• es的分布式架構

  • 不同集群通過不同的名字區分，默認是”elasticsearch“

    • 可以通過配置文件，或者啟動時指定

      -E cluster.name=xxx

    • 一個集群可以有一個或多個節點

• 節點

  • 節點是一個Elasticsearch的實例

    • 本質是一個JAVA進程
    • 一臺機器可以運行多個Elasticsearch進程，但是生產環境一般建議一臺機器只運行一個Elasticsearch實例

  • 節點的名字可以通過配置文件或啟動時指定

    -E node.name=xxx

  • 每個節點啟動之后，會被分配一個UID，保存在data目錄下

• Master-eligible Node和Master Node

  • 每個節點啟動后，默認就是一個master-eligible節點
  • master-eligible節點可以參加選主流程，成為master節點
  • 當地一個節點啟動后，它會將自己選舉成為master節點
  • 每個節點上都保存了集群的狀態，只有master節點上才能修改集群的狀態信息（cluster state）：
    • 所有節點信息
    • 所有的索引（集）以及相關的Mapping和Setting信息
    • 分片的路由信息

• Data Node 和Coordinating Node

  • data節點負責保存分片數據，是實現水平擴容的基本單位
  • coordinating節點負責接受客戶端的請求，將請求分發到合適的節點，最終把結果匯集到一起
  • 每個節點默認都起到coordinating節點的職責

• 其他節點類型

  • Hot & Warm Node （冷熱節點）
    • 熱節點是配置比較高的節點data node，用于存儲較新的數據，冷節點相反，以此降低集群部署的成本
  • Machine Learning Node
    • 負責跑機器學習的任務，用來做異常檢查

• 節點啟動時，讀取elasticsearch.yml配置文件，來決定自己承擔的角色

  • master eligible 對應的配置項是 node.master，默認值是true
  • data對應的是node.data，默認值true
  • 一個節點可以承擔多種角色
  • 在生產環境中，推薦設置單一角色的節點

• 分片

  • 主分片（Primary Shard），用以解決數據水平擴展的問題。通過主分片，可以將數據分布到集群內的所有節點上

    • 一個分片是一個運行Lucene的實例
    • 主分片數在索引創建時指定，后續不允許修改，除非Reindex

  • 副本（Replica Shard），用以解決數據高可用問題，是主分片的拷貝

    • 副本分片數，可以動態調整
    • 增加副本數，還可以一定程度上提高服務的可用性（吞吐性能）

  • 示例1：在一個3節點的集群中，blogs索引（集）的分片分布情況

    PUT /blogs {"settings": {"number_of_shards": 3, // 主分片數3"number_of_replicas": 1 // 副本1份} }
    • Node1
      • P1
      • R2
    • Node2
      • P2
      • R3
    • Node3
      • P3
      • R1

  • 示例2：在一個2節點的集群中，如果有3個索引（集）的分片情況

    PUT /index1 {"settings": {"number_of_shards": 1, // 主分片數1"number_of_replicas": 1 // 副本1份} }
    • Node1
      • Index1P1，Index2P1, Index3P1
    • Node2
      • Index1R1, Index2R1, Index3R1

  • 示例3: 一個2節點的集群中，blog索引在如下設置下的分片情況

    PUT /blogs {"settings": {"number_of_shards": 3, // 主分片數3"number_of_replicas": 1 // 副本1份} }
    • Node1
      • P1
      • R2
      • R3
    • Node2
      • P2
      • P3
      • R1

  • 分片的設定：在生產環境中，需要提前做好容量的規劃

    • 分片數設置過小
      • 導致后續無法增加節點實現水平擴展
      • 單個分片數據量太大，導致數據重新分配耗時
    • 分片數設置過大
      • 影響搜索結果的相關性打分，影響統計結果的準確性
      • 單個節點傻姑娘過多的分片，會導致資源浪費，同時也會影響性能（7.0開始，默認分片數由5改為1）

• 查看集群健康狀態

  GET _cluster/health

  狀態說明：

  • green：主分片和副本都分配正常
  • yellow：主分片分配正常，有副本未能正常分配
  • red：有主分片未能正常分配。例如，當服務器磁盤容量操作85%時，去創建一個新的索引（集）
  GET _cat/nodes # 查看節點信息 GET _cat/shards # 查看分片信息

• 通過cerebro查看集群的分片及詳細信息

總結

以上是生活随笔為你收集整理的基本概念的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。