Solr in action学习笔记 第三章 Key Solr Concept
3.1 Searching, matching, and finding content
3.1.1What is a document?
什么样的信息可以放进solr，以被搜索，这些信息是如何组织的？
Solr是文档存储和检索引擎。所有的提交到Solr的数据都是一个文档document。
（可以理解为document是Solr的内置数据结构）
每个文档包含一个或多个字段/域（field），每个域有一个域类型：
string, tokenized text, Boolean, date/time, lat/long, etc
每种域类型都有0或多个分析步骤（分词，过滤等）来处理该类型域的数据并映射到Solr index。
所有的域都在Solr schema中定义为一个特定的域类型，告诉Solr如何处理该域的内容。
当执行搜索时，Solr会在一个或多个域上进行搜索，返回匹配的结果
Solr是flexible schema，一个文档不必包含所有域，只有有值的域被Solr处理。
（Solr可以通过apache tika提取文档的值映射到域中，也可以手动通过HTTP，API等添加文档的某些域值）
Solr甚至可以通过观察数据，预测一个未定义的域的类型，自动添加域到schema，但不推荐这样做。
综上，一个文档是域的集合，域和域类型在schema中定义，并配置好分析器，分析结果添加到index中等待搜索，搜索的返回结果也是一个包含一个或多个域（可以选择）的文档
3.1.2The fundamental search problem
数据库方法的问题
1.要么限制太严格，要么限制太宽松，都达不到较好的搜索体验
解决：相关性排序，语义分析，同义词分析，去停止词等。
2.效率底下：需要遍历所有文档来查找结果
解决：倒排索引(搜索引擎的核心技术)，文本分析等
3.1.3 The inverted index
Solr使用Lucene的倒排索引 详见Lucene in action
*index项是有序的，这样查找效率更高！
3.1.4Terms, phrases, and Boolean logic
如过搜索new house，solr如何处理？
*搜索new和house两个词，同时匹配
*搜索new和house两个词，只需要一个匹配
*搜索new house短语
REQUIRED TERMS：+new+house 或new AND house
OPTIONAL TERMS：new house或new OR house
NEGATED TERMS：new house -rental 或者new house NOT rental 排除带rental的文档
注：Solr还有修改逻辑运算符的语法q.op=AND q.op=OR
PHRASES:"new home"
GROUPED EXPRESSIONS：New AND (house OR (home NOT improvement NOT depot NOT grown))这个用户很难用到吧。。。
3.1.5Finding sets of documents
查找new home，默认为OR操作，则分别查找两个词，找到匹配的文档，然后集合并运算找到最终的结果集。
如果布尔运算符为AND，则交运算。
Lucene就是通过集合运算提供强大的query语法！
3.1.6Phrase queries and term positions
索引是分开的，那么如何搜索短语？
答案：短语的每个词仍然独立搜索，先找到交集（短语语法比AND还严格，是AND的子集）。
index中还有一个特征车高伟term positions， 记录该项在文档中的相对顺序！
如果匹配到的集合词语的顺序是连续的，则可以认定匹配。
3.1.7Fuzzy matching
WILDCARD SEARCHING通配符：搜索一个特定前缀的词：offi*，off?r
通配符搜索相当耗时，匹配词尾更耗时，可以开启Solr的“反向”索引，转为匹配前缀，但如无需求就不推荐
另外：通配符不支持按短语查找，除非另配文本分析器使得整个短语都被索引。
RANGE SEARCHING：按范围过滤，电商网站按价格范围，按时间范围比较常用！
一个电商网站，通常提供层面搜索，排序方式，价格范围过滤等3种服务！
FUZZY / EDIT-DISTANCE SEARCHING：编辑距离
administrator~N：容忍N个编辑距离的匹配，默认为2
距离为1-2的使用高效Levenshtein automaton自动机，距离大于2的非常慢
PROXIMITY SEARCHING
例子：要搜索chief *** officer
如果使用chief AND officer，可能会搜到chief和police officer
“chief officer”～1:匹配所有chief和officer的距离小于1的文档
3.2相关性
只有10%的用户会打开第2页，1%的用户会打开第3页！
所以，搜索排序非常重要！
3.2.1Default similarity
Solr相关性分数基于Similarity class，你也可以写自己的相关性排序类，但理解Similarity的实现和理论是有必要的。
Solr默认使用LUcene的DefaultSimilarity class。
首先Solr使用集合运算得到需要排序的文档，然后使用一个向量空间模型，用于评分，并把query转换成向量，同时每文档都对于一个向量。
然后基于向量的余弦距离进行评分，角度小，余弦大的得到的分值高。
在向量空间模型中，每个文档和query都被计算出一个词向量term vector
怎么计算向量？？？
公式较复杂
3.2.2Term frequency
词频tf表示一个特定的词在文档中的出现频率，
Lucene代码：传入frequency取平方根，因为其重要性不是成倍增长的，所起取出现次数的平方根
问题：不知道哪个程序调用tf，idf等计算相关性评分
3.2.3Inverse document frequency
逆文档频率？
query中每个词的重要性显然是不一样的，如a，the等词显然不重要
常识是文档中罕见的词比文档中常见的词重要！
idf就是衡量搜素的词多么“罕见”！
docFreq：表示该词出现的文档数，总文档越多，该词出现的越少，则该词就越有价值
3.2.4 Boosting
如果你确定特定的域或词比其他的更重要，那么可以在index或query时boost
3.2.5 Normalization factor
默认公式计算3种正态参数，
*field norms
describing the
importance of a particular field on a per-document basis。索引时计算。
norm(t,d) = d.getBoost() • lengthNorm(f) • f.getBoost()，在索引时存为一字节，
分别为文档boost，域boost和长度Norm用于惩罚较长的文档（基于较长的文档相关性较低的假定）
Solr允许相同的field加入多次？？？（为什么），boost为它们的乘积
上述三项被编码到1个字节存在Solr索引中。存在精度损失可以接受。
*query norms
不影响排序的一个因子，用来尝试使query间的分数可比较
*THE COORD FACTOR
3.3Precision and Recall
Precision查准率:正确匹配/返回文档数
Recall查全率 ：正确匹配数/所有匹配数（返回+未返还）
balance： Solr致力于同时提高查准率和查全率，但更倾向于查全率。
一个侵略性的文本分析（比配词的变种）可以提高查全率，但会降低查准率
一种常见的方法是：在结果全集中衡量查全率，在第一页或前几页衡量查准率。
平衡性的选择最终基于你的用例
3.4Searching at scale
Solr最吸引人的特性：分布式
3.4.1 The denormalized document
反规格化？——Soolr的核心概念
理解：不像关系数据库，信息存在多个表中，Solr的信息存在一个document里！
Solr提供了join功能，但推荐仅在反规格化不实际的时候使用
反规格化缺点：数据冗余
优点：极度的可扩展性，因为文档被假定为独立的，允许query并行处理
3.4.2 Distributed searching
分布式搜索？
单服务器会因为搜索量过大或数据量过大而过载。
第二种情况需要将索引分割，搜索时query发给所有服务器，结果返回是再进行汇总。
Solr允许一次query提交给多个core，而每个core可以看出index的一个分割，有一个或多个core提供shard的list，
且搜索是并行进行的，速度更快。
理论上速度是线性增加的，但实际上会达到极限
3.4.3 Clusters vs. servers
可能需要几台相同的服务器平衡query流量？
概念转换：服务器s到服务器集群s
如果一个多core的query中，有core不可连接，则整个query失败！所以从集群的角度考虑问题很重要！
Solr提供有Apache ZooKeeper管理的集群Solr Cloud
3.4.4The limits of Solr
1.Solr的文档不相关，这是很多NoSql为了分布式付出的代价
2.数据冗余
3.如果进行域相关性操作，非常不方便
4.他是基于document的，对field直接操作并不方便，如果更新field，实际上要更新整个document
5.Solr针对短query优化，长query（数千词）并不优化
6.分布式的灵活性：自动增加或删除服务器并重新部署的能力
