學習Elasticsearch原理筆記

Elasticsearch是一個分佈式可拓展的實時搜索和分析引擎

文件存儲：Elasticsearch，面向文檔型數據庫，一條數據就是一個文檔，用JSON做爲文檔序列化的格式

MySQL和Elasticsearch數據關係術語對比：

　　關係數據庫-數據庫-表-行-列

　　Elasticsearch-索引-類型-文檔-字段

Elasticsearch的交互：可使用Java API，也能夠直接使用HTTP的Restful API方式

Elasticsearch強大的索引能力：精髓-一切設計都是爲了提升搜索的性能

什麼是倒排索引？舉個例子

| ID | Name | Age | Sex |

| - - |:-------:| -----:| -----:|

| 1 | Kate | 24 | Female

| 2 | John | 24 | Male

| 3 | Bill | 29 | Male

ID是Elasticsearch自建的文檔ID，Name、Age、Sex索引以下：

Name:| Term | Posting List |

　　　| -- |:----:|

　　　| Kate | 1 |

　　　| John | 2 |

　　　| Bill | 3 |

Age:| Term | Posting List |

　　| -- |:----:|

　　| 24 | [1,2] |

　　| 29 | 3 |

Sex:| Term | Posting List |

　　| -- |:----:|

　　| Female | 1 |

　　| Male | [2,3] |

Posting List

　　Elasticsearch分別爲每一個field都創建了一個倒排索引，

　　Kate ，24，Female，John，Male，Bill，29這些是Term。

　　而1，2，3是文檔ID，[1][3][1,2][2,3]這些就是Posting List。

　　Posting List就是一個int的數組，存儲了全部符合這個Term的文檔ID。

Term Dictionnary

　　Elasticsearch將全部的Term排個序，二分法查找Term，logN的查找效率。

Term Index

　　Term Index是Term Dictionnary的索引，包含的是Term的一些前綴。

Frame Of Reference

　　Elasticsearch要求Posting List是有序的，方便壓縮。

　　原理：經過增量，將原來的大數變成小數，僅儲存增量值，再按bit排好隊，最後經過字節存儲。

Roaring Bitmaps

　　Bitmap是一種數據結構，假設Posting List[1,3,4,7,10]，對應的Bitmap就是[1,0,1,1,0,0,1,0,0,1]，很是直觀，用0/1表示某個值是否存在。

　　Bitmap的缺點是存儲空間隨着文檔個數線性增加。Roaring bitmaps須要用到某些指數特性：將posting list按照65535爲界限分塊，用<商，餘數>的組合表示每一組id。

聯合索引

　　若是多個field索引的聯合查詢，倒排索引如何知足快速查詢的要求呢？

　　利用跳錶的數據結構快速作」與「運算，或者利用bitset按位」與「。

Elasticsearch的索引思路：

　　將磁盤裏的東西儘可能搬進內存，減小磁盤隨機讀取次數（同時也利用磁盤順序讀特性），結合各類壓縮算法，用極其苛刻的態度使用內存。

因此，對於使用Elasticsearch進行索引時須要注意:

　　不須要索引的字段，必定要明肯定義出來，由於默認是自動建索引的

　　一樣的道理，對於String類型的字段，不須要analysis的也須要明肯定義出來，由於默認也是會analysis的

　　選擇有規律的ID很重要，隨機性太大的ID(好比java的UUID)不利於查詢

關於最後一點，我的認爲有多個因素:

　　上面看到的壓縮算法，都是對Posting list裏的大量ID進行壓縮的，那若是ID是順序的，或者是有公共前綴等具備必定規律性的ID，壓縮比會比較高；

　　最影響查詢性能的，應該是最後經過Posting list裏的ID到磁盤中查找Document信息的那步，由於Elasticsearch是分Segment存儲的，Term定位到Segment的效率直接影響了最後查詢的性能，

　　若是ID是有規律的，能夠快速跳過不包含該ID的Segment，從而減小沒必要要的磁盤讀次數