Solr字段属性解释

在solr中有很多关于字段和字段类型属性,这些属性非常重要,直接决定了我们对solr的理解深度,我一直对这些概念有些模糊,有必要总结下,给自己也给别人留个记录吧。

本文说锁的属性,均是指schemal格式定义文件(以前默认叫schema.xml,6.0版本以后默认是managed-schema )中定义的属性。


一.关于字段定义属性

1.Indexed和Stored

在字段的属性中最常见的就是这两个属性了,如:
<field name="id" type="string" indexed="true" stored="true" required="true" multiValued="false" />

Indexed

简单说明: 索引的字段是在搜索的时候可以用它来查询或排序,在lucene中,被索引的字段将会建立倒排表.

Stored

简单说明: 一个字段是否被存储,取决于你是否想在solr的查询结果中得到它,也就是说你是否想在查询结果中看到它,它将会消耗cpu和io和磁盘空间等资源。

2.multiValued

设置为true表示此字段可以存储多个值,意思是这个字段在一个文档中可以存储多个值的内容。
如:
<field name="text" type="text_general" indexed="true" stored="false" multiValued="true"/>

3.required

提示solr拒绝添加没有这个字段的任何文档,默认这个值设置为假。
简单来说就是这个字段是必须的,类似数据库的非空,如果添加的文档字段为空,则添加不到索引上去。
如:
<field name="id" type="string" indexed="true" stored="true" required="true" multiValued="false" />
如果添加的文档缺少这id字段就报错。

<uniqueKey>id</uniqueKey> 表示定义id字段为唯一值字段,这可以防止重复建索引,另外在Solr的云模式部署下是必须设置的,最好用string或long等基础数据类型作为唯一字段。

4.type

字段的类型,定义了字段的存储和处理方式,如string类型标示字段值将会被原样存储,不分词,不改变。

5.default

字段的默认值,经常用在字段是必须的,但是有时候又无法提供的情况,solr就会用默认值替代。如:
<field name="recordTime" type="date" indexed="true" stored="true" required="true" default="NOW+8HOUR"/>
标示recordTime如果没有提供,用当前的时间+8个小时作为recordTime的时间,加8小时是因为solr默认时区是0时区,按照中国北京时间(东8区)算,需要加上8个小时。

二.类型高级属性

1.docValue

在solr的schema定义中,基本的long、int、double、float类型设置docValue,如下:
<fieldType name="long" class="solr.TrieLongField" docValues="true" precisionStep="0" positionIncrementGap="0"/>
当然也可以在字段里面直接定义:
<field name="_root_" type="string" indexed="true" stored="false" docValues="false" />

solr说明
如果此字段应包含doc值,则为true。 Doc值为用于分面(faceting),分组,排序和函数查询。 虽然不是required,doc值会使索引加载更快,更多 NRT友好和更高内存利用率。
但他们有一些 限制:它们目前只受StrField,UUIDField支持 和所有Trie *字段,并且根据字段类型,它们可能要求字段为单值,是必需的或具有默认值 。
docValue值存在正排索引中,只所以在排序的时候效果更好,是因为docValue是按照列存储的,又存在正排索引中,所以可以通过文档ID快速找到它。

说明下: lucene的倒排索引是:Term(词)-> 文档ID
这样根据类似Hash算法,通过词可以迅速找到文档ID,然后把相关字段取处理。但是也有不利的方面就是如果要进行分组或排序的时候,会遍历取出所有文档的字段,然后在内存中根据排序字段进行排序,非常耗时和占用内存。

设置docValue就构建了正排索引,即文档ID->docValue字段,而且docValue字段又是排好序的,按照列存储的。只是简单说明。
设置docValue在lucene其实是增加一个字段,所以占存储,影响建索引效率。

useDocValuesAsStored:如果这一项设置为true则标示所有docValue为true的字段将被存储,即使它的stored=false。

2.omitNorms

solr对这个属性解释的有点拗口,自己理解下,就是如果这个为true,则在索引中不存在这个字段的长度属性。这在给文档打分的时候用的到。

举个例子,一个词语,在两篇文章中,一般认为段的文章比长的文章是不是要更加符合查询的需要(因为这个词在两篇文章中权重不一样,比如在100个词的文章中,这个词权重为0.01; 在100个词的文章中,这个词权重为0.001),如果是,则需要用长度来加强文档打分的策略,这就是这个属性的作用。Norm 在Lucene中是按照浮点数的形式,只占用一个字节的方式存储的。

忽略情况:
1、如果你的doc的字段的内容长度大小比较一致,则可以忽略。
2、如果在查询结果中,字段内容的长度对你的结果匹配无影响忽略。
3、需要节省空间,提高建索引和查询的性能。

使用情况:
1、字段内容长度影响了文档的打分,则需要使用。

在solr中,默认的时间、string或数字类型,这个属性为true。

3.termVectors

在solr中,我们通过查询的内容的词向量和文档中的此向量之间的夹角来求相关性,给文档相关性打分(词向量比较复杂,回头单独写一篇文章来阐述)。
solr中有个MoreLikeThis 的功能,现在很多电商的查询里面的找类似就是这个功能,solr利用term Vectors来计算相关度,通常是是利用存储在索引中查询信息计算的,设置termVectors为true,则可以在建索引的时候计算term Vector信息,且保存在索引中。

这对大数据量的索引来说,影响很大。如果你重度使用MoreLikeThis 的功能,可以开启这个属性。

4.termPositions和termOffset、termPayLoads

这三项和前面的termVectors关系很大,是在前面一项为true的情况下,这三项才有效果。分别是指词在文档中所处位置、词的偏移量、词在词向量中比重信息(词在文章中重要性?不确定此处)。
可以加速高亮功能和其他辅助功能,当然如果设置为true也会增加索引的大小和降低建索引的速度。

omitTermFreqAndPositions:
如果设置为true,则忽略词出现的频次、位置和在文章中这个字段的比重信息。在不需要这些信息时候可以改进索引性能。减少索引的大小。依赖这个词的位置的查询将默默地显示找不到信息,除了textField字段类型,其他字段类型默认设置为true。

omitPositions : 和omitTermFreqAndPositions 类似仅仅忽略位置。

5.precisionStep 和positionIncrementGap

precisionStep
这可能是这几个属性里面最难理解的属性了,不过这个属性用在数字或时间字段的范围查询或者排序的时候。通过字面理解就是精度步长,简单来说就是通过保存数据的多个精度来加快数据的范围定位。

举个例子,比如你在电商网站查询价格范围在1000 到10000之间的所有手机,这里面就用到了范围搜索。如果价格值的范围很小,用precisionStep 没多大意义,只有大量数据的时候使用它才可能起到加快搜索的作用。
假设手机价格如下定义:
<field name="phone_price" type="tint" indexed="true" stored="true" /

<fieldType name="tint" class="solr.TrieIntField"precisionStep="8"positionIncrementGap="0"/>
首先说明在solr中(在lucene中),一个数字类型(Date类型实际是按照Long来存储的)最高精度是其本身,这也称为基数据。
solr对于一个具有precisionStep非0的值保存了多个不同精度的term。
按照Solr In Action举例如图:

图来自Solr In Action

tint四个字节,按照precisionStep=8 ,则说明精度按照8位切分,4个字节一共32位,刚好保存四个值。

图来自Solr In Action

通过这两个图的对比,更小的步长,则同一个值需要保存更多的term,
当然范围搜索也更加精确,查找速度更快,但是也同样会增大索引的大小。

图来自Solr In Action

同样是50000个价格随机数,在不同的precisionStep下的索引大小和范围查询速度的快慢。
positionIncrementGap
它是和multiValued一起使用的,标示多值之间虚拟空白的数量。
举个网上的例子:

title1: ab cd
title2: xy zz
如果positionIncrementGap=0,那么这四个term的位置为0,1,2,3。如果检索"cd xy"那么能够找到,如果你不想让它找到,那么就需要调整positionIncrementGap值。如100,那么这是位置为0,1,100,101。这样就不能匹配了。

6.sortMissingFirst 和sortMissingLast

这两个比较好理解,是文档在排序的时候,如果排序字段的值缺失,那么是排在前面还是排在后面。

参考资料

1.Solr In Action(非常棒的一本书,学习solr的必看)
2.apache-solr-ref-guide-6.0.pdf

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 212,686评论 6 492
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,668评论 3 385
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 158,160评论 0 348
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,736评论 1 284
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,847评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 50,043评论 1 291
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,129评论 3 410
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,872评论 0 268
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,318评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,645评论 2 327
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,777评论 1 341
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,470评论 4 333
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,126评论 3 317
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,861评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,095评论 1 267
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,589评论 2 362
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,687评论 2 351

推荐阅读更多精彩内容