一、背景

隨著ES在業(yè)務(wù)場景中的使用逐漸增多，平臺對ES集群的穩(wěn)定性、管理、運維的壓力逐漸增大，通過日常的運維情況來看，發(fā)現(xiàn)用戶對ES的了解熟悉程度參差不齊，經(jīng)常性的遇到索引創(chuàng)建不規(guī)范，或者參考別人索引的創(chuàng)建腳本進行創(chuàng)建索引，對索引沒有一個比較清晰的認知，對索引結(jié)構(gòu)的規(guī)劃也寥寥無幾，為此，平臺使用了一些列手段來幫助用戶提前合理規(guī)劃模板，比如索引、模板的創(chuàng)建接入飛書審批流，平臺側(cè)會逐一結(jié)合業(yè)務(wù)場景和ES集群情況詳細溝通確定索引或者模板結(jié)構(gòu)；又比如ES內(nèi)核增加業(yè)務(wù)不停服的動態(tài)擴分片能力，旨在進行不合理索引的治理提升ES集群穩(wěn)定性（索引一旦創(chuàng)建分片是不能修改的），我們內(nèi)部改動ES源碼實現(xiàn)了不停服動態(tài)擴分片。

因此有必要從ES的索引講起，讓大家對ES的索引從概念、原理到使用有一個清晰的認知，希望日常業(yè)務(wù)場景中用到ES的同學能夠抽時間讀一下。當然文章避免不了存在主觀的分析，大家可以在文章底部進行評論或者私聊我們，一起探討。好了廢話不多說了，現(xiàn)在開始介紹。

二、什么是index(索引)

下面會針對索引的組成和基本結(jié)構(gòu)結(jié)合官方文檔逐一介紹。

基本概念

index(索引)是索引是具有相似特征的文檔（Document）集合，類似于關(guān)系型數(shù)據(jù)庫中的表。每個索引都具有自己唯一的名稱與_id。并且可以進行不同的參數(shù)配置與mapping映射。以適應(yīng)不同的業(yè)務(wù)場景。索引中的最小單位是文檔。每一條文檔(doc)都是一個json格式的數(shù)據(jù)對象。包含了實際的具體數(shù)據(jù)以及該數(shù)據(jù)所對應(yīng)的元數(shù)據(jù)。文檔可以是結(jié)構(gòu)化，半結(jié)構(gòu)化或非結(jié)構(gòu)化的數(shù)據(jù)。索引在elasticsearch中被用于存儲，檢索與分析數(shù)據(jù)。通過對索引進行搜索與聚合操作可以快速地找到相關(guān)的文檔。

官方描述：The index is the fundamental unit of storage in Elasticsearch, a logical namespace for storing data that share similar characteristics. After you have Elasticsearch deployed, you’ll get started by creating an index to store your data.

翻譯：索引是Elasticsearch中存儲數(shù)據(jù)的基本單位，是一個邏輯命名空間，用于存儲具有相似特性的數(shù)據(jù)。在部署Elasticsearch后，您將通過創(chuàng)建索引來存儲數(shù)據(jù)。

An index is a collection of documents uniquely identified by a name or an alias. This unique name is important because it’s used to target the index in search queries and other operations.

翻譯：索引是一種文檔集合，通過名稱或別名唯一標識。這個唯一名稱非常重要，因為它用于在搜索查詢和其他操作中定位索引。

三、索引結(jié)構(gòu)詳解

索引結(jié)構(gòu)詳解

圖片

創(chuàng)建索引結(jié)構(gòu)
PUT /index_demo
{
  "aliases" : {
    "index_demo_alias" : { }
  },
  "mappings" : {
    "properties" : {
      "id" : {
        "type" : "long"
      },
      "name" : {
        "type" : "text",
        "fields" : {
          "keyword" : {
            "type" : "keyword",
            "ignore_above" : 256
          }
        }
      },
      "status" : {
        "type" : "keyword"
      },
      "createDate" : {
        "type" : "long"
      }
    }
  },
  "settings" : {
    "index" : {
      "refresh_interval" : "5s",
      "number_of_shards" : "3",
      "number_of_replicas" : "1"
    }
  }
}

ignore_above屬性說明：

- ignore_above的默認值通常為256個字符，這意味著任何超過256個字符的字符串將不會被索引或存儲。

- 該參數(shù)僅適用于keyword類型的字段，因為這些字段主要用于過濾、排序和聚合操作，不需要進行全文搜索。

- ignore_above的值以字符為單位計算，包括英文字符和漢字。例如，一個漢字和一個英文字符都算作一個字符。

- 性能優(yōu)化：通過限制字段長度，可以減少索引大小和查詢時間，從而提高性能。

- 避免資源浪費：對于包含大量數(shù)據(jù)的字段，如日志文件中的長字符串，可以通過ignore_above避免不必要的存儲和索引。

官方描述：Strings longer than the ignore_above setting will not be indexed or stored. For arrays of strings, ignore_above will be applied for each array element separately and string elements longer than ignore_above will not be indexed or stored.

別名

別名將其生命置于群集狀態(tài)內(nèi)，由主節(jié)點（master node) 管理; 這意味著如果你有一個名為 xiaoming 的別名指向一個名為 potato 的索引，那么開銷就是群集狀態(tài)映射中的一個額外鍵，它將名稱 xiaoming 映射到具體的索引字符串。這意味著與其他指數(shù)相比，別名的重量要輕得多; 可以維護數(shù)千個而不會對集群產(chǎn)生負面影響。

官方原話：An alias points to one or more indices or data streams. Most Elasticsearch APIs accept an alias in place of a data stream or index name.

Aliases enable you to:

- Query multiple indices/data streams together with a single name

- Change which indices/data streams your application uses in real time

- Reindex data without downtime

翻譯：別名（Alias）可以指向一個或多個索引或數(shù)據(jù)流。大多數(shù)Elasticsearch API接受別名代替數(shù)據(jù)流或索引名稱。別名的功能包括：

- 使用單一名稱查詢多個索引/數(shù)據(jù)流；

- 實時更改應(yīng)用程序使用的索引/數(shù)據(jù)流；

- 在不中斷服務(wù)的情況下進行擴分片。

可以看到索引有上面三個作用，平臺建議為每個索引添加別名（動態(tài)擴分片依賴別名）。添加別名可以在索引創(chuàng)建時和創(chuàng)建后再添加，即索引可以隨時添加，但是平臺還是建議你在創(chuàng)建索引時候指定別名，避免動態(tài)擴分片時候再去修改代碼重新部署應(yīng)用。

添加別名的幾種方式

1. 創(chuàng)建索引時指定別名

PUT /test_index
{
    "settings" : {
        "number_of_shards" : 1,
        "number_of_replicas" : 1
    },
    "aliases":{"test_alias":{}},
    "mappings" : {
        "properties" : {
            "field1" : { 
                "type" : "text" 
            },
            "createdAt": {
                "type": "date",
                "format": "yyyy-MM-dd HH:mm:ss"
           }
        }
    }
}

2. 已存在的索引添加別名

POST /_aliases
{
  "actions": [
    {
      "add": {
        "index": "test_index", # 索引名
        "alias": "test_alias" # 別名
      }
    }
  ]
}

3. 別名更換

別名更換可以零停機進行動態(tài)擴分片。

POST /_aliases
{
  "actions": [
    {
      "add": {
        "index": "existing_index",
        "alias": "test_alias" # 別名
      },
      {
        "remove": {
          "index": "old_index",
          "alias": "old_test_alias" # 別名
        }
      }
    }
  ]
}

映射

建立索引時需要定義文檔的數(shù)據(jù)結(jié)構(gòu)，這種結(jié)構(gòu)叫作映射。在映射中，文檔的字段類型一旦設(shè)定后就不能更改。因為字段類型在定義后，elasticsearch已經(jīng)針對定義的類型建立了特定的索引結(jié)構(gòu)，這種結(jié)構(gòu)不能更改。借助映射可以給文檔新增字段。另外，elasticsearch還提供了自動映射功能，即在添加數(shù)據(jù)時，如果該字段沒有定義類型，elasticsearch會根據(jù)用戶提供的該字段的真實數(shù)據(jù)來猜測可能的類型，從而自動進行字段類型的定義。

字段類型

字段類型（Field Type）是定義數(shù)據(jù)格式和索引方式的重要概念，它決定了字段在索引中的存儲、搜索和聚合行為。下面針對日常用到最多的三個字段類型進行解釋，text、keyword、Numeric（Integer、Long）。

Text

text字段類型是Elasticsearch中用于全文搜索的核心字段類型。它通過分析器將文本拆分為單個詞，并存儲為倒排索引，適用于非結(jié)構(gòu)化文本的搜索和分析。然而，由于其經(jīng)過分析器處理，不適用于排序和聚合操作。

1. 特點

• 全文搜索：text字段類型主要用于存儲和索引可讀的文本內(nèi)容，例如郵件正文、產(chǎn)品描述、新聞文章等。這些字段會被分析器（analyzer）處理，將字符串拆分為單個詞（term），以便進行全文搜索。
• 分詞處理：text字段支持分詞器（tokenizer），可以根據(jù)語言和需求選擇不同的分詞策略（如標準分詞器、正則表達式分詞器等）。分詞后的結(jié)果會存儲為倒排索引，便于快速檢索。
• 不適用于排序和聚合：由于text字段經(jīng)過分析器處理，其原始字符串無法直接用于排序或聚合操作。如果需要排序或聚合，通常需要結(jié)合keyword字段類型。
• 支持多字段映射：可以通過多字段（multi-field）映射同時使用text和keyword類型，以滿足全文搜索和精確匹配的需求。

2. 使用場景

• 全文搜索：適用于需要對文本內(nèi)容進行模糊搜索的場景，例如搜索引擎、新聞網(wǎng)站、商品搜索等。
• 文本分析：可以結(jié)合分析器（如TF-IDF、BM25等）進行文本相似性搜索或評分計算。
• 日志分析：用于分析和搜索日志文件中的文本內(nèi)容，提取關(guān)鍵信息。
• 內(nèi)容管理：在內(nèi)容管理系統(tǒng)中，用于存儲和搜索文檔、文章等內(nèi)容。

3. 官方建議

Use a field as both text and keyword

Sometimes it is useful to have both a full text (text) and a keyword (keyword) version of the same field: one for full text search and the other for aggregations and sorting. This can be achieved with multi-fields.

通過多字段映射同時使用text和keyword類型，可以實現(xiàn)全文搜索和精確匹配的雙重需求。

4. 平臺建議

• 明確業(yè)務(wù)使用場景，如果不需要進行模糊搜索的話，設(shè)置為keyword類型，來避免分詞帶來的存儲開銷，增加系統(tǒng)壓力。

Keyword

keyword字段類型是一種用于存儲和索引結(jié)構(gòu)化數(shù)據(jù)的字段類型。

1. 特點

• 不進行分詞：keyword字段類型不會對字段值進行分詞處理，而是將其作為整體存儲。這意味著字段值會被原樣存儲到倒排索引中，不會被拆分成單獨的單詞或短語。
• 精確匹配：由于字段值不進行分詞，keyword字段類型非常適合用于精確匹配查詢，例如查找特定的電子郵件地址、身份證號或狀態(tài)碼等。
• tips：在term查詢中可以結(jié)合case_insensitive屬性，忽略大小寫對值進行搜索，但不支持terms查詢。
• 支持排序和聚合：keyword字段類型可以用于排序和聚合操作，例如按狀態(tài)碼統(tǒng)計數(shù)量或按用戶ID進行分組。
• 存儲效率高：由于不需要分詞，keyword字段類型的存儲開銷較低，適合存儲大量具有唯一性或固定值的字段。

2. 使用場景

• 精確查詢：適用于需要精確匹配的場景，例如查找特定的電子郵件地址、身份證號、狀態(tài)碼等。
• 排序和聚合：當需要對數(shù)據(jù)進行排序或聚合時，keyword字段類型是理想選擇。例如，按用戶ID排序或按狀態(tài)統(tǒng)計數(shù)量。
• 標簽和分類：用于存儲標簽、分類等結(jié)構(gòu)化數(shù)據(jù)，例如用戶畫像標簽（學生、IT、教師等）。
• 唯一性字符串：適用于存儲具有唯一性的字符串，如SpuId、貨號、得物訂單號等。

Numeric

數(shù)值類型，包含long、interger、short、byte、double、float等數(shù)字類型。

1. 特點

• 整數(shù)類型：適用于范圍查詢、排序和聚合操作。由于整數(shù)類型占用空間較小，推薦優(yōu)先使用范圍較小的類型（如 integer 或 long）以提高索引和搜索效率。
• 浮點類型：適用于需要高精度的計算場景。如果數(shù)據(jù)范圍較大或精度要求不高，可以使用 scaled_float 類型并設(shè)置合適的 scale 值。
• 選擇合適的類型：在滿足需求的前提下，盡量選擇范圍較小的類型以節(jié)約存儲空間和提升性能。

tips

  如果確定業(yè)務(wù)使用場景，建議keyword代替數(shù)值類型字段，如果不確定則采用多字段，keyword在term查詢中性能更佳。

圖片

針對字段類型選擇的幾條建議

1. 針對Text和數(shù)值類型場景的字段，盡量改成keyword字段類型，來提升查詢速度。
2. 在不確定業(yè)務(wù)查詢有哪些需求的情況下，設(shè)置多字段類型keyword。
3. 枚舉字段沒有特殊業(yè)務(wù)場景下，統(tǒng)一使用keyword字段類型。
4. 業(yè)務(wù)不需要范圍查詢的話，使用keyword字段類型（支持聚合和排序的）。
5. 對keyword字段類型進行模糊查詢會性能較差，使用多字段類型wildcard來模糊查詢性能更高。
6. 盡量不要使用聚合查詢，text的fielddata會加大對內(nèi)存的占用，如有需求使用，建議使用keyword。
7. 需要中文分詞的話，不要使用默認分詞器，推薦使用ik_smart，ik_max_word會生成更多的分詞，其中含有重復的內(nèi)容，需謹慎使用。
8. 時間字段不要使用keyword，除非點查，推薦使用date/long類型，支持范圍查詢，建議精確到分鐘，會提高查詢效率。
9. keyword字段類型不適用于模糊wildcard查詢，建議使用wildcard字段類型。

圖片

10. 日期的查詢條件為now時，并不能有效利用緩存，盡量換成絕對時間值。
11. ES默認字段個數(shù)最大1000，但建議不要超過100，對于不需要建立索引的字段，不寫入ES。
12. 將不需要建立索引的字段index數(shù)據(jù)設(shè)置為false，對字段不分詞，不索引可以減少很多運算操作。
13. 不建議或者禁止每次寫入后立馬進行顯示的refresh，refresh會帶來較高的磁盤IO，和CPU消耗，甚至有可能導致ES宕機。
14. 持續(xù)補充......

索引結(jié)構(gòu)與關(guān)系性數(shù)據(jù)庫對比

圖片

四、索引(Shard)結(jié)構(gòu)-分片與副本

什么是Shard

基本概念

分片是管理文檔的一個數(shù)據(jù)單元，分片是Elasticsearch中邏輯概念。ES內(nèi)部把索引中文檔進行按照一定路由規(guī)則（文檔_id的hash值與分片數(shù)取余）進行路由到不同的存儲數(shù)據(jù)單元，存儲數(shù)據(jù)單元就是分片。你可以理解為MySQL的分表。

ElS的邏輯分片就是一個Lucene索引，一個ES索引是分哦的集合，當ES在索引中搜索的時候，他發(fā)送查詢到每一個屬于索引的分片（Lucene索引）進行檢索，最后合并每個分片的結(jié)果得到一個全局的結(jié)果集。

分片劃分

分片分為primary shard(主分片)和replicate shard(副本分片)。

• 主分片：索引的基本數(shù)據(jù)存儲單元，每個索引被水平拆分為多個主分片，每個分片都是互相獨立的。包含一部分索引的數(shù)據(jù)與索引的結(jié)構(gòu)(segement)。每個分片都可以在集群中不同的節(jié)點上進行移動與復制。以提高數(shù)據(jù)的可用性與容錯性。
• 副本分片：主分片的完整拷貝，用于冗余存儲和容災，副本分片和主分片在ES節(jié)點數(shù)足夠的情況下不會同時存在一個ES節(jié)點。

注意：單分片的記錄條數(shù)不要超過上限2,147,483,519。

• 主副分片分布示意圖

圖片

分片的功能

1. 主分片

• 數(shù)據(jù)存儲與寫入：所有文檔通過路由算法（如 hash(_id) % num_primary_shards（主分片數(shù)））分配到主分片，主分片負責處理索引、更新、刪除等寫操作。
• 擴展性：通過增加節(jié)點和分片分布，實現(xiàn)數(shù)據(jù)的水平擴展。
• 不可變性：主分片數(shù)量在索引創(chuàng)建時通過 number_of_shards 參數(shù)設(shè)定，創(chuàng)建后無法修改（需重建索引）。

2. 副本分片

• 高可用性：當主分片所在節(jié)點宕機時，副本分片自動升級為主分片（和對應(yīng)的主分片不在一個節(jié)點），避免數(shù)據(jù)丟失和服務(wù)中斷。
• 讀取負載均衡：副本分片可并行處理查詢請求，提升讀吞吐量。
• 動態(tài)調(diào)整：副本分片數(shù)量通過 number_of_replicas 參數(shù)動態(tài)配置，支持按需擴展或縮減。

分片數(shù)規(guī)劃

分片的基本概念和功能咱們咱們已經(jīng)了解，在日常ES運維過程中發(fā)現(xiàn)不少同學對分片和數(shù)量的設(shè)置沒有什么概念，照搬其他同學的比較多，這是嚴重錯誤的。咱們在實際的業(yè)務(wù)場景中也要做好分片（主副）數(shù)量的規(guī)劃，來避免慢查、數(shù)據(jù)傾斜、磁盤容量浪費等問題。

 當索引分片數(shù)量過多時，可能會對ES性能產(chǎn)生不利影響。因為每個分片都需要一定量的內(nèi)存來存儲索引數(shù)據(jù)和緩存，從而導致內(nèi)存消耗增加。另外當查詢或?qū)懭霐?shù)據(jù)涉及多個分片時，ES需要在節(jié)點之間進行傳輸和協(xié)調(diào)數(shù)據(jù)，從而增加網(wǎng)絡(luò)開銷，這也會導致查詢和寫入性能的降低。可見分片數(shù)量的選擇需要慎重考慮。

索引在不同場景中，其分片分設(shè)置是不一樣的，接下來咱們會在下面四個場景中來進行闡述。

讀場景

索引單分片20g~40g，盡量減少分片數(shù)，可以降低熱點，因為當分片數(shù)過多時，就容易出現(xiàn)長尾子請求，即有可能部分子請求因ES集群節(jié)點異常、Old GC、網(wǎng)絡(luò)抖動等延遲響應(yīng)，導致整個請求響應(yīng)緩慢。另一方面，拆分過多的子請求無法提升數(shù)據(jù)節(jié)點請求吞吐，不能充分利用 CPU。在盡量減少主分片數(shù)的情況下，同時也可以適當增加副本數(shù)，從而提升查詢吞吐。

寫場景

索引單分片10g~20g，小分片更有利于數(shù)據(jù)寫入。小分片維護的segment數(shù)量遠低于大分片，在數(shù)據(jù)刷新落盤與段合并上更有優(yōu)勢。由于單分片數(shù)據(jù)量更少，在寫入時數(shù)據(jù)可以更快地緩存至內(nèi)存中并通過refresh參數(shù)更快的持久化至磁盤中。

日志存儲場景

• 需要考慮每日寫入集群的數(shù)據(jù)總量大小。通過過數(shù)據(jù)量與數(shù)據(jù)節(jié)點數(shù)評估索引分片數(shù)量。
• 在日志存儲后是否需要兼顧查詢與聚合性能。合理大小的分片數(shù)據(jù)量能夠提高查詢效率。
• 根據(jù)日志持久化策略，采用按月/周/天的策略生成索引。并使用ILM(索引生命周期管理策略)動態(tài)對日志索引進行完整生命周期的管理。
• 建議副本數(shù)設(shè)置為0來減少磁盤容量成本。

小數(shù)據(jù)量索引業(yè)務(wù)場景

對于數(shù)據(jù)量比較小的索引，增加索引分片數(shù)并不一定會帶來性能提升，反而可能會帶來一些負面影響。

首先，增加索引分片數(shù)會增加集群的管理開銷，包括維護分片的狀態(tài)、備份和恢復分片等。如果索引數(shù)據(jù)量比較小，這種開銷可能會超過性能提升帶來的收益。

其次，增加索引分片數(shù)可能會導致數(shù)據(jù)分布不均衡，從而影響查詢性能。具體來說，如果某些分片中的數(shù)據(jù)量過小，可能會導致這些分片的查詢性能比其他分片差。此外，如果查詢涉及到多個分片，數(shù)據(jù)的合并操作也會增加查詢時間。

因此，對于數(shù)據(jù)量比較小的索引，在查詢場景下，通常建議將分片數(shù)設(shè)置為1或2，以避免不必要的開銷和性能問題。如果需要提高查詢性能，可以考慮配置索引副本，優(yōu)化查詢語句或使用緩存。

通用場景

• 根據(jù)實際業(yè)務(wù)場景提前規(guī)劃預算索引數(shù)據(jù)量，做好分片數(shù)量規(guī)劃（索引一旦創(chuàng)建無法修改分片數(shù)）。
• 分片數(shù)量：推薦公式：主分片數(shù) ≈ 總數(shù)據(jù)量 / 單分片容量上限（官方建議單分片10-50GB，單個分片文檔數(shù)在1億條以內(nèi)，日志場景可放寬至50-100GB）。

注意：分片數(shù)量平臺強烈建議或者要求設(shè)置為ES data節(jié)點角色的整數(shù)倍。

• 副本數(shù)量：增加副本數(shù)可提升讀性能，但會降低寫入速度（需同步更多副本），因此在讀場景可以酌情考慮。
• 如果索引是時序類，或者數(shù)據(jù)過大，單分片幾百G，可以結(jié)合生命周期和索引模板進行索引滾動管理。
• 平臺不建議使用自動移routing值進行分片，默認使用文檔_id就好。

原因：使用自定義routing值進行路由分片的話很容易產(chǎn)生數(shù)據(jù)傾斜，另外ES內(nèi)部會多一些計算邏輯來如何進行分片路由，在寫入較高的場景下也會有一定的性能損耗。

• 控制分片數(shù)量，分片數(shù)不是越多越好，過多分分片，也會造成ES集群元數(shù)據(jù)管理的壓力，降低系統(tǒng)的性能損耗。
• 設(shè)置total_shards_per_node，將索引壓力分攤至多個節(jié)點。
• index.routing.allocation.total_shards_per_node參數(shù)可以限制每個節(jié)點上的shard數(shù)量，從而將索引的壓力分攤到多個節(jié)點，這樣可以提高集群性能和可用性，避免某個節(jié)點過載導致整個集群出現(xiàn)問題。
• index.routing.allocation.total_shards_per_node是一個索引級別設(shè)置（創(chuàng)建索引和對已有索引進行設(shè)置），語法如下：

PUT <index_name>/_settings
{
    "index.routing.allocation.total_shards_per_node":<number_of_shards>
}
<index_name>為索引名字，<number_of_shards>表示每個節(jié)點上該索引的分片數(shù)量。

持續(xù)調(diào)整索分片

對于集群分片的調(diào)整，通常不是一蹴而就的。隨著業(yè)務(wù)的發(fā)展，不斷新增的子業(yè)務(wù) 或 原有子業(yè)務(wù)規(guī)模發(fā)生突變，都需要持續(xù)調(diào)整分片數(shù)量。

索引與資源消耗的關(guān)系

分片數(shù)量與內(nèi)存消耗

每個分片都是獨立的Lucene索引，需要維護倒排索引、緩存等內(nèi)存結(jié)構(gòu)。分片數(shù)量過多會導致以下問題：

• 內(nèi)存占用激增：每個分片默認占用約10-30MB內(nèi)存（含元數(shù)據(jù)），數(shù)千分片可能消耗數(shù)十GB內(nèi)存。
• 文件句柄耗盡：集群總分片數(shù)過多會占用大量文件描述符，可能觸發(fā)"too many open files"錯誤。
• CPU熱點問題：分片分配不均會導致部分節(jié)點負載過高。

Segment碎片化

分片由多個segment組成，segment數(shù)量過多會：

• 增加IO壓力：查詢需遍歷多個segment文件。
• 占用堆內(nèi)存：每個segment需加載部分元數(shù)據(jù)到內(nèi)存，百萬級segment可能消耗數(shù)GB內(nèi)存。
• 影響GC效率：頻繁的segment合并會觸發(fā)Full GC。

五、總結(jié)

創(chuàng)建一個索引需要結(jié)合業(yè)務(wù)使用場景考量字段類型選擇和是否需要索引分詞，按照數(shù)據(jù)規(guī)模和業(yè)務(wù)增長速度來確定分片和副本的數(shù)量的大小。索引的結(jié)構(gòu)直接影響集群的穩(wěn)定性，因此我們在創(chuàng)建索引的時候要養(yǎng)成習慣，作為技術(shù)方案的一環(huán)去仔細打磨這樣才能保證線上的穩(wěn)定性。

大家工作中遇到的一些穩(wěn)定性問題，和使用上的一些問題都可以找我們一起探討，尋找最優(yōu)解。