編程界的小學生 2017-12-27 07:50:54
直接舉例說明
1.假設現在要在倒排索引中去搜索字符串（xxx）
比如如下有個倒排索引列表：
我現在要搜索：2017-02-02
去倒排索引中找，發現對應的document list是doc2和doc3
2.爲每個在倒排索引中搜索到的結果，構建一個bitset
使我們找到的doc list構建一個bitset，就是一個二進制數組，數組每個元素都是0或1。用來標識一個doc對一個filter條件是否匹配，如果匹配就是1，不匹配就是0
[0,1,1]
doc1：不匹配這個filter的
doc2和doc3：匹配這個filter的
儘可能用簡單的數據結構去實現複雜的功能，可以節省內存空間，提升性能
3.遍歷每個過濾條件對應的bitset，優先從最稀疏的開始搜索，查找滿足所有條件的document
一次性其實可以在一個search請求中，發出多個filter條件，每個filter條件都會對應一個bitsite，遍歷每個filter條件對應的bitset，先從最稀疏的開始遍歷
[0, 0, 0, 1, 0, 0]：比較稀疏
[0, 1, 0, 1, 0, 1]
先遍歷比較稀疏的bitset，就可以先過濾掉儘可能多的數據
遍歷所有的bitset，找到匹配所有filter條件的doc
請求：filter，postDate=2017-01-01，userID=1
postDate: [0, 0, 1, 1, 0, 0]
userID: [0, 1, 0, 1, 0, 1]
遍歷完兩個bitset之後，找到的匹配所有條件的doc。就是doc4，就可以將doc4作爲結果返回給client了
4.caching bitset
跟蹤query，在最近256個query中超過一定次數的過濾條件，緩存其bitset。對於小segment（<1000，或<3%），不緩存bitset。
比如postDate=2017-01-01, [0,0,1,1,0,0]，可以緩存在內存中，這樣下次如果再有這個條件過來的時候，就不用重新掃描倒排索引，不用反覆生成bitset，可以大幅度提升性能。
在最近的256個filter中，有某個filter超過了一定的次數，次數不固定，就會自動緩存這個filter對應的bitset
lter針對小segment獲取到的結果，可以不緩存，segment記錄數<1000，或者segment大小<index總大小的3%
segment數據量很小，此時哪怕是掃描也很快；segment會在後臺自動合併，小segment很快就會跟其他小segment合併成大segment，此時就緩存也沒有什麼意義，segment很快就消失了
針對一個小segment的bitset，[0, 0, 1, 0]
filter比query的好處就在於會caching，但是之前不知道caching的是什麼東西，實際上並不是一個filter返回的完整的doc list數據結果。而是filter bitset緩存起來。下次不用掃描倒排索引了。
5. filter大部分情況下來說，在query之前執行，先儘量過濾掉儘可能多的數據
query：是會計算doc對搜索條件的relevance score，還會根據這個score去排序
filter：只是簡單過濾出想要的數據，不計算relevance score，也不排序
6. 如果document有新增或修改，那麼cached bitset會被自動更新
postDate=2017-01-01，[0, 0, 1, 0]
document，id=5，postDate=2017-01-01，會自動更新到postDate=2017-01-01這個filter的bitset中，全自動，緩存會自動更新。postDate=2017-01-01的bitset，[0, 0, 1, 0, 1]
document，id=1，postDate=2016-12-30，修改爲postDate-2017-01-01，此時也會自動更新bitset，[1, 0, 1, 0, 1]
7. 以後只要是有相同的filter條件的，會直接來使用這個過濾條件對應的cached bitset