Disjunction
Max 析取最大 （并集）
本质多域联合搜索，并且不同域指定不同的权重，命中时取最大得分域结果作为结果得分。与直接多域boost求和是完全不同的结果。使用起来非常复杂，需要debugquery
看结果，反复尝试！
http://wiki.apache.org/solr/DisMax
http://searchhub.org/dev/2010/05/23/whats-a-dismax/
What’s a “DisMax” ? Posted
by hossman
The term “dismax” gets
tossed around(被抛出来) on
the Solr lists frequently, which can be fairly confusing to new
users. It originated as a shorthand name for the DisMaxRequestHandler (which I named after the DisjunctionMaxQueryParser, which I named after the DisjunctionMaxQuery class that it uses heavily). In recent
years, the DisMaxRequestHandler and the StandardRequestHandler were
both refactored into(重构)
a single SearchHandler class, and
now the term “dismax” usually refers to the DisMaxQParser.
注解:dismax 现在对应于DisMaxQParser，而DismaxRequestHandler 与standardRequestHandler 重构到SearchHandler中
Clear as Mudd,
right?
Regardless of whether you
use the DisMaxRequestHandler via the qt=dismax
parameter, or use the SearchHandler with the DisMaxQParser viadefType=dismax the end result is that yourq parameter gets parsed by the
DisjunctionMaxQueryParser.
注解：qt=dismax,采取DisMaxRequestHandler,而defType=dismax,是SearchHandler中使用DisMaxQParser，二者q的参数采取DisJunctionMaxQueryParser解析
The original goals of dismax (whichever meaning you might infer)
have never changed:
… supports a simplified
version of the Lucene QueryParser syntax. Quotes can be used to
group phrases(分组短语), and
+/- can be used to denote mandatory(强制性、必选的) and optional(可选的) clauses … but all other Lucene query parser
special characters are escaped to simplify the user experience. The
handler takes responsibility for building a good query from the
user’s input using BooleanQueries containing DisjunctionMaxQueries
across fields and boosts you specify It also allows you to provide
additional boosting queries, boosting functions, and filtering
queries to artificially(人工) affect the outcome of all searches. These options can all
be specified as default parameters for the handler in your
solrconfig.xml or overridden the Solr query URL.
In short: You worry about
what fields and boosts you want to use when you configure it, your
users just give you words w/o worrying too much about
syntax.
注解: dismax句柄主要负责使用布尔查询封装DisjunctionMaxQueries，同时允许手工执行query激励、函数激励、过滤query影响最终搜索结果。所有参数可以通过在solrconfig.xml中配置，作为全局查询用，也可以通过url添加参数，在每一次或者每一类查询中动态使用。
The magic of dismax (in my
opinion) comes from the query structure it produces. What it
essentially boils down to is matrix multiplication: a one column matrix of each “chunk” of
your user’s input, multiplied by a one row matrix of theqf fields to produce a big matrix of every field:chunk
permutation(排列).
The matrix is then turned into a BooleanQuery consisting of
DisjunctionMaxQueries for each row
in the matrix. DisjunctionMaxQuery is used because
it’s score is determined by the maximum score of it’s
subclauses — instead of the sum like a BooleanQuery — so no one
word from the user input dominates the final score. The best way to
explain this is with an example, so let’s consider the following
input…
<span lang="EN-US">defType = dismax</span>
<span lang="EN-US"><span> </span>mm = 50%</span>
<span lang="EN-US"><span> </span>qf = features^2 name^3</span>
<span lang="EN-US"><span> </span>q = +"apache solr" search server</span>
First off, we consider the
“markup” characters of the parser that appear in thisq string:
- white space – dividing input
string into chunk (
分词 ) - quotes – makes a single phrase
chunk (
括号 ) - + – makes a chunk mandatory
(
组合关系 )
So we have 3 “chunks” of user input:
- “apache solr” (must
match) - “search” (should
match) - “server” (should
match>
If we “multiply” that with
our qf list (features, name) we get a
matrix like this…
|
features:”apache solr” |
name:”apache solr” |
(must match) |
|
features:”search” |
name:”search” |
(should match) |
|
features:”server” |
name:”server” |
(should match) |
If we then factor in themm param to determing the “minimum number of
‘ShouldMatch’ clauses that (ahem) must match” (50% of 2 == 1) we
get the following query structure (in psuedo-code)…
<span lang="EN-US">q = BooleanQuery(</span>
<span lang="EN-US"><span> </span><b>minNumberShouldMatch</b> => 1,</span>
<span lang="EN-US"><span> </span>booleanClauses => ClauseList(</span>
<span lang="EN-US"><span> </span>MustMatch(DisjunctionMaxQuery(</span>
<span lang="EN-US"><span> </span>PhraseQuery("features","apache solr")^2,</span>
<span lang="EN-US"><span> </span>PhraseQuery("name","apache solr")^3)</span>
<span lang="EN-US"><span> </span>),</span>
<span lang="EN-US"><span> </span>ShouldMatch(DisjunctionMaxQuery(</span>
<span lang="EN-US"><span> </span>TermQuery("features","search")^2,</span>
<span lang="EN-US"><span> </span>TermQuery("name","search")^3)</span>
<span lang="EN-US"><span> </span>),</span>
<span lang="EN-US"><span> </span>ShouldMatch(DisjunctionMaxQuery(</span>
<span lang="EN-US"><span> </span>TermQuery("features","server")^2,</span>
<span lang="EN-US"><span> </span>TermQuery("name","server")^3))</span>
<span lang="EN-US">));</span>
<span lang="EN-US"> </span>
<span style="font-size:9.0pt"><b>注解：<span lang="EN-US">boolean</span>查询这个是最最基本的原子查询，其他高级查询都是基于这个查询的组合、封装，<span lang="EN-US">Dismax</span>也是如此。从<span lang="EN-US">dismax qp</span>分解过程和定义看，<span lang="EN-US">dismax</span>也是分解为<span lang="EN-US">boolean</span>查询，并且<span lang="EN-US">field</span>激励也同一般域<span lang="EN-US">boost</span>一致，但是不同的时候<span lang="EN-US">dismax</span>是以最大得分作为最终得分，而一般多域独立<span lang="EN-US">boost</span>时候是求和得分。<br> <br></b></span>
With me so far
right?
Where people tend to get
tripped up(绊倒), is in thinking about how Solr’s per-field analysis
configuration (in schema.xml) impacts all of this. Our example
above was pretty straight forward, but lets consider for a moment
what might happen if:
- The
name
field uses the WordDelimiterFilter（单词分割符过滤器）at query time butfeaturesdoes not. - The
featuresfield is configured so that “the” is a stopword, butnameis
not.
Now let’s look at what we
get when our input parameters are structurally similar to what we
had before, but just different enough to for WordDelimiterFilter
and StopFilter to come into play…
<span lang="EN-US">defType = dismax</span>
<span lang="EN-US"><span> </span>mm = 50%</span>
<span lang="EN-US"><span> </span>qf = features^2 name^3</span>
<span lang="EN-US"><span> </span>q = +"apache solr" the search-server</span>
Our resulting query is going
to be something like…
<span lang="EN-US">q = BooleanQuery(</span>
<span lang="EN-US"><span> </span>minNumberShouldMatch => 1,</span>
<span lang="EN-US"><span> </span>booleanClauses => ClauseList(</span>
<span lang="EN-US"><span> </span><span style="color:red">MustMatch</span>(DisjunctionMaxQuery(</span>
<span lang="EN-US"><span> </span>PhraseQuery("features","apache solr")^2,</span>
<span lang="EN-US"><span> </span>PhraseQuery("name","apache solr")^3)</span>
<span lang="EN-US"><span> </span>),</span>
<span lang="EN-US"><span> </span><span style="color:red">ShouldMatch</span>(DisjunctionMaxQuery(</span>
<span lang="EN-US"><span> </span>TermQuery("name","the")^3)</span>
<span lang="EN-US"><span> </span>),</span>
<span lang="EN-US"><span> </span><span style="color:red">ShouldMatch</span>(DisjunctionMaxQuery(</span>
<span lang="EN-US"><span> </span>TermQuery("features","search-server")^2,</span>
<span lang="EN-US"><span> </span>PhraseQuery("name","search server")^3))</span>
<span lang="EN-US"><span> </span>));</span>
The use of
WordDelimiterFilter hasn’t changed things very much: features is
treating “search-server” as a single Term, while in thename field we are searching for the phrase “search
server” — hopefully this shouldn’t surprise anyone given the use of
WordDelimiterFilter for the name field (presumably that’s why it’s
being used). This DisjunctionMaxQuery still “makes sense”, but
other fields with odd analysis that produce less/more Tokens then a
“typical” field for the same thunk might produce queries that
aren’t as easily to understand. In particular consider what has
happened in our example with the word “the”: Because “the” is a
stop word in the features field, no Query object is
produced for that field/chunk combination. But a Query is produced
for the name field, which means the total number of
“ShouldMatch” clauses in our top level query is still 2 so our
minNumberShouldMatch is still 1 (50% of 2 == 1).
This type of situation tends
to confuse a lot of people: since “the” is a stop word in one
field, they don’t expect it to matter in the final query — but as
long as at least one qf field produces a Token for it
(name in our example) it will be included in the final
query, and will contribute to the count of “ShouldMatch”
clauses.
So, what’s the take away
from all of this?
DisMax is a complicated
creature. When using it, you need to consider all of it’s
options carefully, and look at the debugQuery=true
output while experimenting with different query strings and
different analysis configurations to make really sure you
understand how queries from your users will be parsed.
注解：dismax 构造非常复杂，使用的时候需要仔细考虑所有选项，同时，开启debugQuery=true，针对不同的查询串和分词器。
For qf (Query Fields), pf (Phrase Fields),
mm (Minimum ‘Should’ Match), and tie (Tie Breaker),
see: the Solr
Wiki DisMaxQParserPlugin.
Solr:
Forcing items with all query terms to the top of a Solr search »
Robot Librarian
Lucid Imagination » Solr Powered ISFDB – Part
#10: Tweaking Relevancy
http://searchhub.org/dev/2011/06/20/solr-powered-isfdb-part-10/
Lucid Imagination » Solr Powered ISFDB – Part
#11: Using DisMax
http://searchhub.org/dev/2011/08/08/solr-powered-isfdb-part-11/
http://tm.durusau.net/?p=21573
Using
Solr’s Dismax Tie Parameter « Another Word For It (tie
breake配合断路器)
http://java.dzone.com/articles/using-solrs-dismax-tie
Solr Powered ISFDB – Part #11: Using
DisMax
http://searchhub.org/dev/2011/06/20/solr-powered-isfdb-part-10/