关于solr:Solr-811入门教程2创建core

新建 core

增加 core

命令增加

应用命令比较简单

~$ bin/solr create -c mytest[core 名称]

这样就增加完了。Core Admin 就能够看到了。

手动增加

手动增加绝对简单一些，须要提前创立目录，而后通过可视化界面增加

1、到 server\solr（绝对于 solr 根目录的门路，下同）目录下，先把要创立的 core 目录提前创立，复制 configsets\_default 下的 conf 到 core 目录。

~$ cd solr-8.11.2
~$ mkdir server/solr/mytest
~$ cp -r server/solr/configsets/_default/conf  server/solr/mytest/

2、点击 core 的局部，因为限度没有 core（核）会呈现增加页面。依照图示增加

增加实现，点击“Core Admin”能够看到增加的核

配置 solr 字段

增加字段有 2 种办法，能够通过 web 页面增加，也能够间接批改 schema 文件增加。

可视化界面减少

通过浏览器的 Schema 菜单增加

增加字段名称，选中字段类型，增加增加字段即可。https://solr.apache.org/guide/8_11/field-type-definitions-and-properties.html#field-default-properties

类型高级属性

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

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

批改 managed-schema

也能够间接批改 managed-schema 文件，在 core 的 conf 下的 managed-schema 文件中减少字段配置

<!-- 自定义的字段，id 曾经存在不须要设置 -->
<field name="dd" type="string" indexed="true" stored="true"/>    
<field name="age" type="pint" indexed="true" stored="true" />
<field name="description" type="text_ik" indexed="true" stored="true"  />
<field name="createTime" type="pdate" indexed="true" stored="true"  />
<field name="updateTime" type="pdate" indexed="true" stored="true"  />

增加后到“Core Admin”中刷新一下核即可

就增加上了。

增加数据

当初 core 曾经建好了，然而外面还没有数据，这里咱们应用 json 增加以便疾速演示（反对 JSON,、CSV、XML 等格局），个别生产环境下都是从数据库拜访。

筹备 json 数据：

{"id": "11","age": 40,"name": "李白","description": "发明了现代浪漫主义文学顶峰、歌行体和七绝达到前人难及的高度"},
{"id": "12","age": 31,"name": "杜甫","description": "唐代平凡的现实主义文学作家，唐诗思维艺术的集大成者"}

找到该 core 的 Documents 菜单，抉择文档类型未JSON, 把方才筹备的数据粘贴进来，确认无误提交。

查问

方才曾经增加了数据，咱们当初验证一下查问一下

点击 Query 菜单，而后间接点击 Execute Query 按钮查问能够看到方才增加的 2 条数据曾经能查问到了。

参考文档

1. 官网文档