Solr 文档，字段和Schema设计
1. 概述文档，字段和schema设计
Solr的基本前提很简单。 你给它很多信息，然后你可以问问题，找到你想要的信息。 您在所有信息中提供的部分称为indexing(索引)或updating(更新)。 当您提出问题时，称为query(查询)。
schema是告诉Solr如何从输入文档构建索引的地方。
Solr的Schema 文件
Solr存储有关在Schema文件中理解的字段类型和字段的详细信息。 此文件的名称和位置可能会有所不同，具体取决于您最初配置Solr的方式或稍后修改它。
- managed-schema是Solr默认使用的模式文件的名称，用于支持在运行时通过Schema API或Schemaess Mode功能进行Schema更改。 您可以显式配置托管架构功能以使用替代文件名，如果您选择，但文件的内容仍然由Solr自动更新。
- schema.xml是模式文件的传统名称，可以由使用ClassicIndexSchemaFactory的用户手动编辑。
- 如果使用SolrCloud，您可能无法在本地文件系统上找到这些名称的任何文件。 您只能通过Schema API（如果启用）或通过Solr Admin UI的“云端屏幕”来查看模式。
2. Solr字段类型
字段类型定义了Solr应如何解释字段中的数据以及如何查询字段。 默认情况下，Solr包含许多字段类型，也可以在本地定义。
2.1 字段类型定义和属性
字段类型定义当文档被索引或查询发送到索引时将在字段上发生的分析。
字段类型定义可以包括四种类型的信息：
- 字段类型的名称（必需）。
- 实现类名称（强制性）。
- 如果字段类型为TextField，则说明字段类型的字段分析。
- 字段类型属性，根据实现类，某些属性可能是必需的。
2.1.1 schema.xml中的字段类型定义
字段类型定义在schema.xml中。 每个字段类型都在fieldType元素之间定义。 它们可以可选地分组在一个类型元素中。 以下是一个名为text_general的类型的字段类型定义的示例：
<fieldType name="text_general" class="solr.TextField" positionIncrementGap="100" multiValued="true">
<analyzer type="index">
<tokenizer class="solr.StandardTokenizerFactory"/>
<filter class="solr.StopFilterFactory" words="stopwords.txt" ignoreCase="true"/>
<filter class="solr.LowerCaseFilterFactory"/>
</analyzer>
<analyzer type="query">
<tokenizer class="solr.StandardTokenizerFactory"/>
<filter class="solr.StopFilterFactory" words="stopwords.txt" ignoreCase="true"/>
<filter class="solr.SynonymGraphFilterFactory" expand="true" ignoreCase="true" synonyms="synonyms.txt"/>
<filter class="solr.LowerCaseFilterFactory"/>
</analyzer>
</fieldType>
上面示例中的第一行包含字段类型名称text_general和实现类solr.TextField的名称。
定义的其余部分是关于现场分析，在了解分析仪，令牌和过滤器中描述。
实现类负责确保字段处理正确。 在schema.xml中的类名中，字符串solr是org.apache.solr.schema或org.apache.solr.analysis的缩写。 因此，solr.TextField实际上是org.apache.solr.schema.TextField.
2.1.2 字段类型属性
字段类型类确定字段类型的大部分行为，但也可以定义可选属性。 例如，日期字段类型的以下定义定义了两个属性sortMissingLast和omitNorms。
<fieldType name="date" class="solr.TrieDateField"
sortMissingLast="true" omitNorms="true"/>
可以为给定字段类型指定的属性分为三大类：
- 特定于字段类型类的属性。
- 常规属性Solr支持任何字段类型。
- 字段默认属性，可以在字段类型上指定，该类型将由使用此类型而不是默认行为的字段继承。
一般属性
| 属性 | 描述 | 值 |
|---|---|---|
| name | fieldType的名称。 该值在“类型”属性中用于字段定义。强烈建议， 名称仅由字母数字或下划线字符组成，而不是以数字开头。 目前尚未严格执行。 |
|
| class | 用于存储和索引此类型的数据的类名称。 请注意，您可以将包含的类名称与“solr”进行前缀。 而Solr会自动找出哪些包来搜索该类-所以solr.TextField将会工作。 如果您正在使用第三方类，则可能需要具有完全限定的类名。 solr.TextField的完全限定等价物是org.apache.solr.schema.TextField。 |
|
| positionIncrementGap | 对于多值字段，指定多个值之间的距离， 以防止虚假的短语匹配. |
integer |
| autoGeneratePhraseQueries | 对于text fields, 如果为true，Solr会自动生成相邻项的短语查询。 如果是虚假的，术语必须用双引号括起来作为短语处理。 |
true or false |
| enableGraphQueries | 对于text fields，当使用sow = false进行查询时适用。 例如,对于具有查询分析器的字段类型，使用true（默认值），包括图形感知过滤器。 同义词图形滤波器和字分隔符图形滤波器。 对于具有查询分析器的字段类型，使用false，包括当缺少某些令牌时可以匹配文档的过滤器， 例如Shingle Filter。 |
true or false |
| docValuesFormat | 定义用于此类型的字段的自定义DocValuesFormat。 这要求在solrconfig.xml中配置了一个支持架构的编解码器，如SchemaCodecFactory。 |
n/a |
| postingsFormat | 定义用于此类型字段的自定义PostingsFormat。 这要求在solrconfig.xml中配置了一个支持架构的编解码器，如SchemaCodecFactory。 |
n/a |
字段默认属性
这些属性可以在字段类型或各个字段上指定，以覆盖字段类型提供的值。 每个属性的默认值取决于底层的FieldType类，它们又可能取决于<schema />的版本属性。 下表包含由Solr提供的大多数FieldType实现的默认值，假定一个schema.xml声明版本=“1.6”。
| 属性 | 描述 | 值 | 隐含默认值 |
|---|---|---|---|
| indexed | 如果为true，则该字段的值可用于查询匹配文档的查询。 | true or false | true |
| stored | 如果为ture，则可以通过查询来检索该字段的实际值。 | true or false | true |
| docValues | 如果为true，则该字段的值将被放置在面向列的DocValues结构中。 | true or false | false |
| sortMissingFirst sortMissingLast |
当排序字段不存在时控制文档的放置。 | true or false | false |
| multiValued | 如果为true，则表示单个文档可能包含此字段类型的多个值 | true or false | flase |
| omitNorms | 如果为true，则省略与此字段相关联的规范（这将禁用字段的长度归一化，并节省一些内存）。 所有原始（未分析）字段类型的默认值为true，例如int，float，data，bool和string。 只有全文字段或字段需要规范。 |
true or false | * |
| omitTermFreqAndPositions | 如果为真，则从该字段的帖子中省略术语频率，位置和有效载荷。 这可以是不需要该信息的字段的性能提升。 它还减少了索引所需的存储空间。 依赖于使用此选项的字段上发布的位置的查询将无法找到文档。 对于不是文本字段的所有字段类型，此属性默认为true。 |
true or false | * |
| omitPositions | 类似于omitTermFreqAndPositions，但保留术语频率信息。 | true or false | * |
| termVectors termPositions termOffsets termPayloads |
这些选项指示Solr维护每个文档的全字段向量， 可选地包括这些向量中每个词出现的位置，偏移量和有效载荷信息。 这些可用于加速突出显示和其他辅助功能，但在索引大小方面施加了相当大的成本。 它们对Solr的典型用途不是必需的。 |
true or false | false |
| required | 指示Solr拒绝添加不具有该字段值的文档的任何尝试。 此属性默认为false。 |
true or false | false |
| useDocValuesAsStored | 如果该字段启用了docValues，则将其设置为true将允许返回该字段， 就像在fl参数中匹配“*”时一样，它是一个存储字段（即使它具有存储= false）. |
true or false | true |
| large | large字段总是懒惰加载，如果实际值<512KB，将只占用文档缓存中的空间。 此选项需要stored =“true”和multiValued =“false”。 它适用于可能具有非常大的值的字段，以便它们不会缓存在内存中。 |
true or false | false |
2.2 Solr包含的字段类型
下表列出了Solr中可用的字段类型。 org.apache.solr.schema包中包含此表中列出的所有类。
| 类 | 描述 |
|---|---|
| BinaryField | 二进制数据。 |
| BoolField | 包含true或false。 第一个字符中的“1”，“t”或“T”的值被解释为真。 第一个字符中的任何其他值都被解释为false。 |
| CollationField | 支持排序和范围查询的Unicode归类。 如果可以使用ICU4J，ICUCollationField是一个更好的选择。 请参阅“Unicode排序规则”一节。 |
| CurrencyField | 支持货币和汇率。 请参阅“使用货币和汇率”一节。 |
| DateRangeField | 支持索引日期范围，包括时间点日期实例（单毫秒持续时间）。 有关使用此字段类型的更多详细信息，请参阅“使用日期”部分。 考虑使用此字段类型，即使它仅适用于日期实例， 特别是当查询通常落在UTC年/月/日/小时等边界时。 |
| ExternalFileField | 从磁盘上的文件中拉取值。 请参阅使用外部文件和进程一节。 |
| EnumField | 允许定义一个枚举的值集合， 这些值可能不容易按字母或数字顺序排序（例如，严重性列表）。 此字段类型接受配置文件，其中列出了字段值的正确顺序。 有关详细信息，请参阅使用枚举字段部分。 |
| ICUCollationField | 支持排序和范围查询的Unicode归类。 请参阅“Unicode排序规则”一节。 |
| LatLonPointSpatialField | 空间搜索：纬度/经度坐标对; 可能多值多点。 通常用逗号指定为“lat，lon”。 |
| LatLonType | （已弃用）空间搜索：单值纬度/经度坐标对。 通常用逗号指定为“lat，lon”。 |
| PointType | 空间搜索：单值n维点。 它既用于排序不是lat-lon的空间数据，也用于一些更罕见的用例。 （注意：这与“基于点”的数字字段无关） |
| PreAnalyzedField | 提供一种发送到Solr序列化令牌流的方式，可选地使用字段的独立存储值， 并将此信息存储和编入索引，而不进行任何其他文本处理。 PreAnalyzedField的配置和使用记录在“使用外部文件和进程”页面上。 |
| RandomSortField | 不包含值。 对此字段类型进行排序的查询将以随机顺序返回结果。 使用动态字段来使用此功能。 |
| SpatialRecursivePrefixTreeFieldType | （简称RPT）空间搜索：以WKT格式接受纬度逗号经度字符串或其他形状。 |
| StrField | 字符串（UTF-8编码字符串或Unicode）。 字符串用于小字段，不以任何方式进行标记化或分析。 他们的限制稍低于32K。 |
| TextField | 文字，通常是多个单词或令牌。 |
| TrieDateField | 日期字段。 以毫秒精度表示一个时间点。 请参阅“使用日期”部分。 precisionStep =“0”最小化索引大小; precisionStep =“8”（默认值）可实现更有效的范围查询。 对于单值字段，请使用docValues =“true”进行高效排序。 |
| TrieDoubleField | 双字段（64位IEEE浮点）。 precisionStep =“0”最小化索引大小; precisionStep =“8”（默认值）可实现更有效的范围查询。 对于单值字段，请使用docValues =“true”进行高效排序。 |
| TrieFloatField | 浮点字段（32位IEEE浮点）。 precisionStep =“0”可以进行有效的数字排序并最小化索引大小; precisionStep =“8”（默认值）可实现有效的范围查询。 使用docValues =“true”进行有效的排序。 对于单值字段，请使用docValues =“true”进行高效排序。 |
| TrieIntField | 整数字段（32位有符号整数）。 precisionStep =“0”可以进行有效的数字排序并最小化索引大小; precisionStep =“8”（默认值）可实现有效的范围查询。 对于单值字段，请使用docValues =“true”进行高效排序。 |
| TrieLongField | 长字段（64位有符号整数）。 precisionStep =“0”最小化索引大小; precisionStep =“8”（默认值）可实现更有效的范围查询。 对于单值字段，请使用docValues =“true”进行高效排序。 |
| TrieField | 如果使用此字段类型，还必须指定“类型”属性，有效值为：integer，long，float，double，date。 使用此字段与使用上述任何Trie字段相同 |
| DatePointField | 日期字段。 以毫秒精度表示一个时间点。 请参阅“使用日期”部分。 该类与TrieDateField类似，但是使用“维度点”的数据结构而不是索引条款， 并且不需要配置精确步骤。 对于单值字段，必须使用docValues =“true”来启用排序。 |
| DoublePointField | 双字段（64位IEEE浮点）。 该类与TrieDoubleField类似， 但是使用基于“维度点”的数据结构而不是索引条款，并且不需要配置精度步骤。 对于单值字段，必须使用docValues =“true”来启用排序。 |
| FloatPointField | 浮点字段（32位IEEE浮点）。 该类的功能类似于TrieFloatField， 但是使用基于“维度点”的数据结构而不是索引项，并且不需要配置精确步骤。 对于单值字段，必须使用docValues =“true”来启用排序。 |
| IntPointField | 整数字段（32位有符号整数）。 该类的功能类似于TrieIntField， 但是使用基于“维度点”的数据结构而不是索引项，并且不需要配置精确步骤。 对于单值字段，必须使用docValues =“true”来启用排序。 |
| LongPointField | 长字段（64位有符号整数）。 该类与TrieLongField类似， 但使用基于“维度点”的数据结构而不是索引条款，并且不需要配置精确步骤。 对于单值字段，必须使用docValues =“true”来启用排序。 |
| UUIDField | Universally Unique Identifier (UUID). 传递值为“NEW”，Solr将创建一个新的UUID。 注意：在使用SolrCloud时，大多数用户不建议使用默认值“NEW”的UUIDField实例 （如果UUID值被配置为唯一键字段则不可行）， 因为结果将是每个文档的每个副本 将获得唯一的UUID值。 建议使用UUIDUpdateProcessorFactory在添加文档时生成UUID值。 |
3. 定义字段
字段在schema.xml的fields元素中定义。一旦设置了字段类型，定义字段本身就很简单。
示例以下示例定义一个名为price的名为float的字段，默认值为0.0; 索引和存储的属性显式设置为true，而在float字段类型上指定的任何其他属性都将被继承。
<field name="price" type="float" default="0.0" indexed="true" stored="true"/>
4. 复制字段
您可能想要以多种方式解释一些文档字段。 Solr具有制作字段副本的机制，以便可以将多个不同的字段类型应用于单个传入信息。 您要复制的字段的名称是源，并且副本的名称是目标。 在schema.xml中，复制字段非常简单：
<copyField source="cat" dest="text" maxChars="30000" />
5. 动态字段
动态字段允许Solr索引您在模式中未明确定义的字段。 如果您发现自己忘记定义一个或多个字段，这将非常有用。 通过在可以添加到Solr的文档中提供一些灵活性，动态字段可以使您的应用程序变得更不易碎。 动态字段就像一个常规字段，除了它有一个带有通配符的名称。 当您索引文档时，与任何明确定义的字段不匹配的字段可以与动态字段匹配。 例如，假设您的架构包含名称为* _i的动态字段。 如果您尝试使用cost_i字段索引文档，但在模式中未定义明确的cost_i字段，那么cost_i字段将为* _i定义字段类型和分析。 像常规字段一样，动态字段具有名称，字段类型和选项。
<dynamicField name="*_i" type="int" indexed="true" stored="true"/>
6. schema其它元素
6.1 Unique Key
uniqueKey元素指定哪个字段是文档的唯一标识符。 虽然uniqueKey不是必需的，但几乎总是由您的应用程序设计保证。 例如，如果您将更新索引中的文档，则应使用uniqueKey。
<uniqueKey>id</uniqueKey>
Schema的默认值和copyFields不能用于填充uniqueKey字段。 uniqueKey的fieldType不能被分析。 您可以使用UUIDUpdateProcessorFactory来自动生成uniqueKey值。 此外，如果使用uniqueKey字段，但是多值（或从fieldtype继承多值），则操作将失败。 但是，唯一的键将继续工作，只要该字段正确使用。
6.2 默认搜索字段和查询运算符
虽然它们已经被弃用了相当长的一段时间，但是Solr仍然支持基于Schema的配置，一个<defaultSearchField />（被df参数取代）和<solrQueryParser defaultOperator =“OR”/>（被q取代 .op参数。
6.3 Similarity
相似性(Similarity)是用于在搜索中得分文档的Lucene类。 每个集合都有一个“全局”相似性，默认情况下，Solr使用一个隐式SchemaSimilarityFactory，它允许使用“每类型”特定的相似性来配置各个字段类型，并且对于没有显式相似性的任何字段类型隐式使用BM25相似性。 通过声明schema.xml中的顶级<similarity />元素，可以覆盖此默认行为，不在任何单个字段类型之外。
这种相似性声明可以直接引用具有无参数构造函数的类的名称，例如在本示例中显示BM25Similarity：
<similarity class="solr.BM25SimilarityFactory"/>
<similarity class="solr.DFRSimilarityFactory">
<str name="basicModel">P</str>
<str name="afterEffect">L</str>
<str name="normalization">H2</str>
<float name="c">7</float>
</similarity>
7. Schema API
作为维护暂时没用到就不写了。
