天翼云云搜索服務，支持根據業務需求，靈活選擇合適的實例配置。我們根據天翼云搜索團隊豐富的實際業務經驗，在此提供一些搜索引擎常見使用場景下，配置選擇的建議。您可以根據業務的讀寫請求、數據存算和搜索與分析等需求進行參考。當然，也需要您根據業務的實際使用情況逐步去探索。

實例版本：

我們同時提供Elasticsearch和OpenSearch兩種選擇。

天翼云基于Elasticsearch7.10.2，默認搭配同版本的Kibana使用，并在開源版本做了大量的能力增強，包括壓縮算法、中文分詞、SQL兼容、異步搜索、向量檢索、跨實例復制、索引管理、拼音分詞、簡繁體轉換、HDFS存儲等，并進行了安全漏洞修復、BUG修復、性能優化等。

天翼云OpenSearch基于OpenSearch2.19.1版本打造，默認搭配同版本OpenSearch Dashboards使用。在開源版本的基礎上也做了大量的能力增強和優化，包括中文分詞優化、流量控制、監控告警、對象存儲適配、拼音分詞、簡繁體轉換等。

規劃實例可用區

天翼云云搜索服務支持多可用區部署，多可用區部署可以在某個可用區全部不可用的情況下，保證實例的主節點可正常選舉，從而為防止數據丟失，并確保在服務中斷情況下能降低實例的停機時間，最終能增強實例的健壯性和高可用性。

Elasticsearch/OpenSearch 實例中，主節點（Master Node）負責管理集群元數據（如索引分片分配、節點狀態等）。主節點通過選舉產生，遵循??過半原則??（Quorum），即候選節點需要獲得超過半數的投票才能成為主節點。

??奇數節點原則??：若主節點部署在 3 個可用區（AZ），每個可用區部署 1 個主節點，則總數為奇數。當單個可用區故障時，剩余兩個可用區的節點仍可形成多數票（2/3 > 50%），確保選舉出新的主節點。

??避免腦裂??：跨可用區部署主節點時，若網絡分區導致節點間通信中斷，奇數節點設計能確保只有一個子集群滿足過半條件，避免多個主節點同時存在的腦裂問題。

天翼云云搜索服務支持單AZ部署和多AZ部署，如果用戶需要某個AZ不可用時，實例仍然可以提供服務，那就需要多AZ部署。

在跨三個AZ部署中，為了保證其中任意一個AZ不可用時，剩余的AZ可以繼續提供服務，因此索引的副本數至少要為1個。

計算節點選型：

目前支持的節點規格如下，不同資源池支持在售機型不同，云搜索服務會根據產品規劃需要適時調整在售機型，請以購買頁可見機型為準：

通用型云主機適用場景：適合平衡型場景，適用于大多數通用搜索和分析任務。當實例需要處理中等規模的數據集，并且查詢和索引操作相對平衡時，這種比例可以提供足夠的處理能力和內存資源。

計算型云主機適用場景：適合CPU密集型操作，如需要進行大量數據聚合或實時分析的場景。當查詢操作非常復雜，需要進行大量的數據計算和聚合時，較高的CPU資源可以提高處理速度。

內存型云主機適用場景：適合內存密集型操作，如大量數據的索引和搜索。當數據集較大，需要頻繁進行全文搜索或復雜查詢時，較高的內存可以提高緩存效率，減少磁盤I/O操作。

基礎型云主機

增強型云主機

海光云主機

海光4云主機

鯤鵬云主機

飛騰云主機

存儲容量規劃

副本數量：副本有利于增加數據的可靠性，但同時會增加存儲成本。默認和建議的副本數量為1。

壓縮比：Elasticsearch和OpenSearch通常可以將數據壓縮20~30%，因此，1GB原始數據-> 1*1.2(Json轉換因子)*0.8(壓縮) -> 0.96壓縮比。

磁盤空間使用率：一般建議為70%。

索引開銷：可以使用cat/indices?v API 和 __pri.store.size_ 值計算確切的開銷計算，通常比源數據大10%。

操作系統預留空間：默認操作系統會保留5%的文件系統供您處理關鍵流程、系統恢復以及防止磁盤碎片化問題等。

因此，存儲容量 = 源數據 * (1 + 副本數量) * 0.96 / （1 - 磁盤使用率）*（1 *索引開銷）*（1 *預留空間） ≈ 源數據 * 2 * 0.96 / 0.7 *1.1 *1.05 = 源數據*3.168。根據原始數據大小，至少要預留大概3倍以上的空間。

數據節點數量規劃

實例建議最大節點數 = 單節點 CPU * 5。

單節點磁盤最大容量：

• 搜索類場景：單節點磁盤最大容量 = 單節點內存大小（GB）* 10。

• 日志類等場景：單節點磁盤最大容量 = 單節點內存大小（GB）* 50。

• 通用類等場景：單節點磁盤最大容量 = 單節點內存大小（GB）* 30。

綜上，示例節點數量規劃如下：

實際場景舉例

如：每天大概有500GB的日志數據寫入，日志數據需要在線保存7天。根據存儲容量規劃公式，500GB的原始數據需要1500GB的磁盤空間。7天就是10TB。16 核 64G的數據節點單節點磁盤最大容量（日志）為2TB，所以需要購買5臺規格為16 核 64G+2TB存儲的Elasticsearch/OpenSearch實例。

規劃節點類型

在訂購天翼云云搜索服務時，正確規劃集群節點類型非常重要。

目前天翼云云搜索服務支持數據節點、專屬master節點、專屬協調節點、冷數據節點四種節點類型。

數據節點

數據節點就是Elasticsearch/OpenSearch的data節點。數據節點是實例的核心數據存儲和計算單元，負責分片存儲、索引/搜索執行、聚合計算等基礎操作。如果沒有購買專屬master節點，數據節點也會承擔master節點的工作。

專屬master節點

專屬master節點負責集群元數據管理、分片分配、節點狀態監控等核心控制任務，不存儲數據。

??部署必要性??

??小型實例（≤10節點）??：可不單獨配置Master節點，由普通節點兼任。

??中大型集群實例：必須獨立部署，避免元數據操作與數據計算爭搶資源導致性能抖動。

??高可用配置??

??數量要求??：至少3個且為奇數，防止單點故障和腦裂問題。

??規格建議??：選擇低配機型（如 esearch-4c16g），因其不參與數據計算，資源消耗較低。

專屬協調節點

接收用戶請求并分發至數據節點，匯總結果返回客戶端，緩解數據節點的負載壓力。

??適用場景??

• 高并發查詢（如電商大促、實時監控）。

• 復雜聚合請求（如多維度分析、嵌套查詢）。

部署策略??

??獨立部署??：與數據節點分離，避免請求分發占用數據節點的CPU/內存資源。

??負載均衡??：如果開通了ELB服務，可將ELB服務配置到專屬協調節點，從而將流量均勻分配至多個協調節點。

協調節點規格建議購買較高規格的機型，比如esearch-8c32g。

冷數據節點

冷數據節點是面向歷史數據存儲的專用節點類型，用于存儲訪問頻率低、響應時效要求較寬松的冷數據（如超過30天的日志、歸檔業務數據等）。通過將冷熱數據分離，可實現存儲成本優化與查詢效率的平衡。

適用場景 

• 歷史數據歸檔（如超過半年的交易記錄、審計日志）。

• 低頻訪問數據（如季度/年度報表、備份索引）。

• 存儲成本敏感型業務（需降低高性能節點資源占比）。

存儲介質選擇 

建議選擇大容量較低規格的存儲類型，適合冷數據長期保存。

容量規劃 

冷節點存儲容量建議為熱節點的3-5倍，例如：

熱節點配置500GB SSD存儲，冷節點配置2TB HDD存儲。

可通過生命周期管理策略自動遷移超期索引。

標簽管理 

冷節點默認攜帶node.attr.tag: stale標簽，支持指定新創建索引到冷數據節點或者對已創建索引動態遷移：

PUT /historical_logs/_settings {

  "index.routing.allocation.require.tag": "stale"

}

規劃實例安全模式

實例的安全模式主要分為http模式和https模式。

• http模式：適合通過內網訪問實例的場景，通過http協議明文傳輸數據。

• https模式：適合需要公網訪問實例的場景。

實例訂購時默認開通https模式。如果需要使用http模式，可在實例開通完成后，在安全設置頁面修改為http訪問。

不管http模式還是https模式，都必須通過用戶名密碼才能訪問Elasticsearch/OpenSearch集群。

管理員賬戶名默認為admin，密碼為創建集群時設置的管理員密碼。

規劃索引分片數

適用場景

• 日志類，寫入頻繁，查詢較少，單個分片 30G 左右。

• 搜索類，寫入少，查詢頻繁，單個分片不超過 20G。

每個 Elasticsearch 索引被分為多個分片，數據按哈希算法打散到不同的分片中。由于索引分片的數量影響讀寫性能和故障恢復速度，建議提前規劃。

分片使用概要

在單節點上，最大分片數量為 1000。單個分片大小盡量保持在 10-50G 之間為最佳體驗，一般推薦在 30G 左右。分片過大可能使故障恢復速度變慢，分片過小可能導致非常多的分片，因為每個分片會使用占用一些 CPU 和內存，從而導致讀寫性能和內存不足的問題。

當分片數量超過數據節點數量時，建議分片數量接近數據節點的整數倍，便于將分片均勻的分布到數據節點中。