爲什麼lucene不需要組合索引，但關係數據庫呢？

Lucene將每個字段的索引分開存儲。因此，當我們執行查詢「fld1：a AND fld2：b」時，我們對第一學期和第二學期的Termdoc進行迭代。這不可能更快。在數據庫的情況下，fld1和fld2的兩個分隔索引將運行緩慢，只有一個將被使用。在這種情況下，DB會爲fld1和fld2請求複合鍵。爲什麼lucene不需要組合索引，但關係數據庫呢？

我的問題是。爲什麼DB不能使用Lucene索引算法執行布爾查詢，如果它與DB索引一樣快並且dosn't需要不同的列組合？

Lucene的一些細節布爾查詢搜索：它利用接口TermDoc。使用兩種方法boolean skipTo(int)和boolean next()的主要想法。所以它不依賴於術語順序（流行的或不流行的術語），因爲這些方法調用的計數總是作爲最不頻繁的項（由於skipTo方法）。所以在分層組合索引中沒有必要，它不會帶來任何額外的性能。

TermDocs t1 = searcher.docs(fld1:a); 
TermDocs t2 = searcher.docs(fld2:b); 
int doc = -1; 
t1.next(); t2.next(); 
while(t1.doc()!=-1 && t2.doc()!=-1) { 
if(t1.doc()<t2.doc()) { 
    if(!t1.skipTo(t2.doc)) return; 
} 
if(t2.doc()<t1.doc()) { 
if(!t2.skipTo(t1.doc)) return; 
} 
if(t1.doc()==t2.doc()) { 
println("found doc:"+t1.doc()); 
t1.next() 
} 
}

來源

2011-06-21 yura

'在數據庫的情況下，fld1和fld2的兩個分隔索引將運行緩慢，只有一個將被使用。「這僅僅是MySQL的真實情況。 Postgres沒有這個問題。 –

你確定嗎？ Db2也是如此。 – yura

那麼，我肯定知道它不是一個問題postgres = D http://www.postgresql.org/docs/8.3/static/indexes-bitmap-scans.html –

我覺得@Frank農民的評論給你大部分的答案：這是完全有可能的RDB使用，即使他們不是「複合」多個索引。

更具體的問題有一個更難的答案：爲什麼RDBs不使用Lucene的多索引搜索範例？回憶一下，Lucene使用帶有跳過列表的倒排索引;還要回顧一下，如果指數非常稀疏且條款數量非常高，這些指標纔有效。

在可能執行類似於where a = b這樣的查詢的列的類型中，可能的b的數目可能非常小，因此該索引將相對密集。因此，使用位圖更有意義（比如PostgreSQL），並且獲得比特級並行性的提速，而不是將其存儲爲跳過列表並處理指針追蹤。

我應該注意的是，即使Lucene在使用查詢結合過濾器時也使用位圖，所以我們可能會等同地問爲什麼Lucene不使用Lucene的搜索。我的猜測是位圖較小，因此更適合內存。

據我所知，這不是一個巨大的性能增益，因此在一般情況下，您可能無法爲位圖或跳過列表提供強有力的參數。但是如果我不得不猜測爲什麼PostgreSQL開發者去了位圖路線，我想這應該是這樣。

來源

2011-06-23 21:50:21 Xodarap

謝謝，我現在認識到爲什麼Lucene skipTo的工作速度如此之快 - 僅僅因爲它是跳過列表。現在這些問題對我來說似乎很清楚。 – yura

爲什麼lucene不需要組合索引，但關係數據庫呢？

回答

相關問題