es的速度快是多方面的原因，此篇博文主要從資料儲存方面來解釋為什麼es的速度快。
es中的乙個shard就是乙個lucene index。
lucene index中有很多小segments， 即為儲存的最小管理單元
為什麼要說明es和lucene之間的關係呢？
因為es是在apache lucene的基礎上開發的，而且倒排索引是在segments的維度上實現的。
其實這個名詞的翻譯給人有種誤解，感覺上是對索引進行了倒排序，但其實不是這樣子的。它的英文原文是：inverted index， 有種顛倒的意思在裡面。 回想我們使用的關係型資料中的索引， 我們是通過索引來定位記錄，倒排索引是根據屬性值來確定記錄的位置。 所以倒排索引也常被稱為反向索引。
如下是lucene中實際的索引結構：
下面我們會一 一講解上述三個概念。
場景： 假設我們有乙個es的集群，並且在該集群中建立了索引people，people具有如下字段：
***， age， height， name接下來es會為每個term建立乙個docid列表（posting list）。
posting list 儲存的是所有符合特定term的文件id（在實際的搜尋引擎中儲存的並不都是文件的id，取而代之的是文件id的偏移量，這樣就可以把大資料的儲存轉成小資料的儲存。 例如： 100-》120-》150 變成了100 -》20-》30）。除此之外還包含：文件的數量、詞條在每個文件**現的次數、出現的位置、每個文件的長度、所有文件的平均長度等，在計算相關度時使用。
假設我們的有很多的人員資料，那麼我們的posting list會變得很大，這時候查詢的速度肯定會變慢，於是我們對term進行排序，排序之後使用二分查詢就能更快的查詢出目標，這就是term dictionary。
對於age我們有以下的term dictionary：
18，20，21儘管有了term dictionary，但是磁碟的隨機訪問（random access）仍然是昂貴的， 所以為了再次提公升效能，可以考慮把一部分資料直接讀到記憶體中，但是term dictionary又太大了, 全部快取到記憶體是不現實的，於是就有了term index（對term本省進行索引）。
term dictionary是term的有序集合，那麼term index就模擬字典的大章節目錄。
a --
----
----
----
----
--第1頁
ab***x--
----
----
----第2頁
ac***--
----
----
----
-第3頁
b --
----
----
----
----
---第4頁
trie樹共享的是字首，而fst既共享字首也共享字尾。
優點：空間占用小， 通過對詞典中單詞字首和字尾的重複利用，壓縮了儲存空間。
查詢速度快。o(len(str))的查詢時間複雜度。
對比：
do dog does deep cost從上面的圖可以看出來term index只保留term的字首和字尾，再加上一系列的壓縮技術（比如前面提到的使用偏移量而不是真正的id），term index可能只有term dictionary的幾十分之一，甚至更少，這樣使得記憶體快取整個term index成為可能。
未完待續。。。。。。。
batch normalization為什麼效果好
batch normalization為什麼效果好 深度學習中 batch normalization為什麼效果好？龍鵬 言有三的回答 知乎 深度學習中 batch normalization為什麼效果好？魏秀參的回答 知乎 為什麼batch normalization那麼有用？autocyz的文章...
為ElasticSearch新增HTTP基本認證
es的http連線沒有提供任何的許可權控制措施，一旦部署在公共網路就容易有資料洩露的風險，尤其是加上類似elasticsearch head這樣友好的前端介面，簡直讓你的資料瞬間裸奔在黑客的眼皮底下。專案上線前做十萬伏特的防護當然不現實，但至少，我們不要裸奔，穿一套比基尼吧。而做乙個簡單的http認...
為什是 property不自動生成屬性？
使用 property 時候，xcode 會自動為我們生 setter 和 getter，甚至會自動生成屬性。例如下面的情況 h 檔案 inte ce person nsobject property copy,nonatomic nsstring name end m 檔案 implementat...