【拓展篇】Elasticsearch 6.0 一個索引只允許有一個type
一，單index,單type
未來發布的elasticsearch 6.0.0版本爲保持兼容，仍然會支持單index，多type結構，但是作者已不推薦這麼設置。在elasticsearch 7.0.0版本必須使用單index,單type，多type結構則會完全移除。
針對這一問題，elasticsearch 作者的討論：
https://github.com/elastic/ela ... 24317
https://www.elastic.co/guide/e ... .html
二，單index，多type結構弊端
人們經常會談到index類似傳統sql數據庫的“database”,而type類似於"table"。現在想想，這是一個非常糟糕的比喻，而這個比喻會造成很多錯誤的假設。
在傳統的sql數據庫中，各個"table"之間是互相獨立的，在一個表中的列都與另一個表相同名稱的列無關。
①，而在我們elasticsearch中同一 Index 下，同名 Field 類型必須相同，即使不同的 Type；
②， 同一 Index 下，TypeA 的 Field 會佔用 TypeB 的資源（互相消耗資源），會形成一種稀疏存儲的情況。尤其是 doc value ，爲什麼這麼說呢？doc value爲了性能考慮會保留一部分的磁盤空間，這意味着 TypeB 可能不需要這個字段的 doc_value 而 TypeA 需要，那麼 TypeB 就被白白佔用了一部分沒有半點用處的資源；
③，Score 評分機制是 index-wide 的，不同的type之間評分也會造成干擾。
④，索引元數據本身是放在主節點中維護的，CP 設計。意味着涉及到大量字段變更及元數據變更的操作，都會導致該 Index 被堵塞或假死。我們應該對這樣的 Index 做隔離，避免影響到其他 Index 正常的增刪改查。甚至當涉及到字段變更十分頻繁且無法預定義 schema 的場景時，是否要使用 ES 都應該慎思熟慮了！
三，doc value 擴展介紹
參見官方文檔docvalues
先看倒排索引組織結構大致如下：
如果我要查詢包含 brown 的文檔有哪些？這個就是全文檢索了，也相當好辦，先從詞典裏遍歷到 brown 這個單詞，然後根據倒排索引查得 Doc_1 和 Doc_2 包含這個單詞。
如果我要查 Doc_1 和 Doc_2 包含的單詞分別有什麼？這個用倒排索引的話開銷會非常大，至少是要將整張表關於 Doc_1 和 Doc_2 的列數據遍歷一遍纔行。這時候我們將數據換一種組織形式，將會起到非常好的效果。
Doc_1 和 Doc_2 存了什麼單詞，一目瞭然。我們把這種數據的組織方式叫做doc_value。
倒排索引的特點很明顯，就是爲了全文檢索而生的，但是對於一些聚合查詢（排序、求平均值等等）的場景來說，顯然不適用。那麼這樣一來我們爲了應對一些聚合場景就需要結構化數據來應付，這裏說的結構化數據就是『列存儲』，也就是上面說的doc_value。
doc_value在 ES 中有幾個應用場景：
對某個字段排序；
某個字段聚合查詢（ max/min/count ）；
部分過濾器 （ 地理位置過濾器 ）；
某個字段的腳本執行。等等。
doc_value是順序存儲到磁盤的，因此訪問是很快的。當我們所處理的集合小於所給的 JVM 堆內存，那麼整個數據集合是會被加載到內存裏的；如果數據集合大於所給的堆內存，那麼就會分頁加載到內存之中，而不會報出『OutOfMemory Error』。
值得一提的是，doc_value的字段使用極其頻繁，因此在5.x 版本後強化成爲兩個字段，分別是 text 和 keyword。
text：string 類型，支持倒排索引，不支持 doc_value；
keyword：string 類型，不支持倒排索引，支持doc_value。
四：參考
①：ElasticSearch 內部機制淺析