傳統我們檢索文章，是逐個遍歷找到對應關鍵詞的位置；
而倒排索引，是通過分詞策略，形成詞與文章的映射關系表，這種詞典+映射表即為倒排索引。
倒排索引的底層實現是基於：FST（Finite State Transducer）數據結構。
lucene [lu'sen] 從4+版本後開始大量使用的數據結構是FST。FST有兩個優點：
利用es的分片預分配。
不能，因為分片數是 文檔路由算法 中重要的元素：
shard = hash(routing) % number_of_primary_shards
動態修改分片將意味著幾乎重新索引文檔數據，這是比僅僅將分片從壹個節點復制到另壹個節點更重量級的操作。
壹個分片存在於單個節點，壹個節點可以包含多個分片。
elasticSearch天然具有分布式的特征，實現水平擴容時通過 分片預分配 。在創建索引時，選擇合適的分片數。
隨著數據量的增加，可以動態的增加節點數，elasticSearch將會自動將分片分配到新增的節點上，當重新分配完成時，每個分片將會有接近至少兩倍於之前的運算速度。
elasticSearch中新添加的索引默認被指定了5個主分片。這意味著我們最多可以將那個索引分散到5個節點上，每壹個節點壹個分片。
不能，壹個分片並不是沒有代價的。
es適當的預分配是好的，但是上千個分片就有些糟糕。
ElasticSearch推薦的最大JVM堆空間是30~32G, 所以把妳的分片最大容量限制為30GB, 然後再對分片數量做合理估算. 例如, 妳認為妳的數據能達到200GB, 推薦妳最多分配7到8個分片。
在開始階段, 壹個好的方案是根據妳的節點數量按照1.5~3倍的原則來創建分片. 例如,如果妳有3個節點, 則推薦妳創建的分片數最多不超過9(3x3)個。當性能下降時，增加節點，ES會平衡分片的放置。
對於基於日期的索引需求, 並且對索引數據的搜索場景非常少. 也許這些索引量將達到成百上千, 但每個索引的數據量只有1GB甚至更小. 對於這種類似場景, 建議只需要為索引分配1個分片。如日誌管理就是壹個日期的索引需求，日期索引會很多，但每個索引存放的日誌數據量就很少。
副本分片 可以實現高可用。當持有主分片的節點掛掉之後，壹個副本分片將會晉升為主分片的角色。
在索引寫入時，副本分片做著和主分片相同的工作。新文檔首先被索引進主分片然後在同步到其他所有的副本分片。增加副本分片並不會增加索引容量。
副本分片可以服務於讀請求，如果索引偏向查詢，那麽可以通過增加副本的數目來提升查詢性能。但也要為此增加額外的硬件資源。
當使用上面配置時，每壹個分片的副本分片數量為1個。
壹個擁有兩個主分片壹份副本的索引可以在四個節點中橫向擴展
Elasticsearch: 權威指南 ? 數據建模 ? 擴容設計 ? 擴容的單元
面試官：Elasticsearch如何設計索引？滿分答案來了
elasticsearch 設置多少分片合適
新年手打，24道進階必備Elasticsearch 面試真題（建議收藏！）