OpenStore儲存引擎是Elasticsearch團隊針對日誌、檢索等情境自研的彈性、高效能、低成本的儲存引擎，本文介紹OpenStore儲存引擎的架構優勢和適用情境。
引擎架構
該架構基於多級儲存設計，對上層提供統一的高效能檔案系統服務：
Leader/Follower：在OpenStore架構中，主分區（Leader）負責構建索引並將產生的Segment檔案上傳到共用儲存。副本分區（Follower）不再獨立構建索引，而是直接從共用儲存同步資料。
NameNode：作為Openstore分布式元資訊管理中心，管理組件括叢集拓撲、全域namespace在內的分布式元資訊，同時提供統一的任務調度服務如資料複製任務，保證叢集的分布式一致性。
Native Metadata Manager(NMM)：作為本地元資訊管理中心，管理組件括檔案長度、更新時間、持久化狀態等在內的檔案本地元資訊，同時提供基礎的UFS接入能力，如負載檔案、持久化檔案等原子操作。
Shared Data Service：遠端共用資料服務，提供海量的資料存放區能力。
優勢
儲存計算分離：OpenStore的核心設計理念，計算資源（Elasticsearch節點）和儲存資源（遠端共用儲存）可以獨立擴充。當計算需求增加時，您可以快速增加節點而無需遷移資料；當儲存需求增加時，可利用遠端共用儲存的海量擴充能力，實現了計算與儲存資源的解耦和獨立Auto Scaling。
資料一致性：通過基於Raft實現的混合儲存一致性協議，確保本機快取與遠端共用儲存之間的資料狀態一致，為上層應用提供統一、可靠的資料檢視。
易用性：全自動的索引生命週期管理，您只需要做簡單的索引周期配置，引擎完全託管了索引冷熱分離和資料移轉OpenStore儲存的全過程。
高可用：基於儲存計算分離架構，多副本之間共用一份資料，不增加額外儲存成本；底層儲存服務保證叢集的資料高可用，提供99.9999999999%（可達12個9）的資料持久性。
儲存類型及適用情境
儲存類型 | |
訪問延遲 （本機快取命中） | 0.2ms |
訪問延遲 （本機快取未命中） | 50ms~400ms |
訪問吞吐 （本機快取命中） | 1GB/s |
訪問吞吐 （本機快取未命中） | 750MB/s |
適用情境 | 監控日誌、歷史訂單、歸檔資料等低頻訪問資料 |
訪問延遲僅表示儲存訪問延遲，不代表端到端訪問延遲。