问题描述
Lucene分别存储每个字段的索引.因此，当我们执行查询"fld1:a AND fld2:b"时，我们在Termdocs上迭代了第一项和第二项.这不可能更快.如果是数据库，则fld1和fld2的两个单独的索引将工作缓慢，并且仅使用一个.在那种情况下，DB要求fld1和fld2的复合键.
Lucene stores index for each field separetly. So when we perform query "fld1:a AND fld2:b" we iterate over Termdocs for first term and second term. This can't be faster. In case of database two separete indexes for fld1 and fld2 will work slow and only one will be used. In that case DB requres composite key for fld1 and fld2.
我的问题是.如果DB和DB索引一样快并且不需要不同的列组合，为什么DB不能利用Lucene索引算法来执行布尔查询?
My question is. Why Can't DB utilize Lucene index algorithm for executing Boolean queries if it as fast as DB index and dosn't requires different combinations of columns?
Lucene布尔查询搜索的一些详细信息:它利用接口 TermDoc .使用两种方法boolean skipTo(int)和boolean next()的主要思想.因此，它不依赖于术语顺序(受欢迎或不受欢迎的术语)，因为这些方法调用的次数将始终与最不频繁的术语一样(由于skipTo方法).因此，没有必要使用分层复合索引，它将不会带来任何额外的性能.
Some details of Lucene Boolean Query search:It utilize interface TermDoc. The main idea in using two methods boolean skipTo(int) and boolean next(). So it is doesn't depend on term order(popular or not popular term) because count of those method calls will be always as most infrequent term(due to skipTo method). So there are no need in hierarchical composite index, it will not bring any additional performance.
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()
}
}
推荐答案
我认为@Frank Farmer的注释为您提供了大部分答案:RDB完全可以使用多个索引，即使它们不是复合"的.
I think @Frank Farmer's comment gives you most of your answer: it's perfectly possible for an RDB to use multiple indexes even if they aren't "composite".
一个更具体的问题很难回答:为什么RDB不使用 Lucene的多索引搜索范式?
A more specific question has a harder answer: why don't RDBs use Lucene's multi-index-search paradigm?
回想一下，Lucene使用带跳过列表的倒排索引；还记得只有在索引非常稀疏并且术语数量非常多的情况下，这些方法才有效.
Recall that Lucene uses an inverted index with a skip list; recall also that these are only efficient if the index is extremely sparse and the number of terms is very high.
在您可能要进行类似where a = b的查询的列的类型中，可能的b的数量可能很小，因此索引将相对密集.因此，使用位图(像PostgreSQL一样)并提高位级并行性比将其存储为跳过列表并处理指针跟踪更有意义.
In the type of column where you're likely to do a query like where a = b, the number of possible bs is probably pretty small, and hence the index will be relatively dense. So it makes more sense to use bitmaps (like PostgreSQL does) and gain the speedup of bit-level parallelism than to store it as a skip list and deal with pointer-chasing.
我应该注意，当结合使用过滤器和查询时，甚至Lucene也会使用位图，因此我们可能同样地问为什么Lucene不使用Lucene的搜索.我的猜测是位图较小，因此更可能适合内存.
I should note that even Lucene uses bitmaps when combining filters with queries, so we might equivalently ask why Lucene doesn't use Lucene's search. My guess is that bitmaps are smaller and therefore more likely to fit in memory.
据我所知，这并不是很大的性能提升，因此在一般情况下，您可能无法对位图或跳过列表提出非常强的论据.但是，如果我不得不猜测为什么PostgreSQL开发人员为什么要走位图路线，我想就是这样.
To the best of my knowledge, this is not a huge performance gain, so you probably can't make a very strong argument for either bitmaps or skip lists in the general case. But if I had to guess why the PostgreSQL devs went the bitmap route, I think it would be this.
这篇关于为什么lucene不需要复合索引，但是关系数据库呢?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！