在Lucene中索引文档时,原始字段信息经过分词、转换处理后形成倒排索引,而原始内容本身并不直接保留。因此,为了检索时能够获取到字段的原始值,我们需要依赖额外的数据结构。Lucene提供了两种解决方案:Stored Field和doc_values。
Stored Field的设计初衷就是为了存储那些未经分词的字段原始值。这样,在执行查询操作时,除了能够获取到文档ID之外,我们还能够方便地检索到这些原始字段信息。
es中每个文档都被视为一个JSON对象,包含多个字段。当文档被索引时,其原始数据或特定字段可以被存储在es中,以便后续能够检索到原始的字段值。这种存储方式类似于传统的行存储数据库,因为它存储了每个文档的所有字段。
然而,需要注意的是,es并不建议大量使用Stored Fields。这是因为存储原始字段值会增加磁盘使用量,并可能降低性能。相反,es更倾向于使用Doc Values和倒排索引来高效地检索和分析数据。因此,Stored Fields通常只用于存储那些需要在搜索结果中直接返回的字段。
那么,什么时候应该使用Stored Fields呢?
可以通过映射(Mapping)来定义哪些字段应该被存储为Stored Fields。映射是定义文档结构和字段属性的过程。
PUT order
{
"mappings": {
"_doc": {
"properties": {
"counter": {
"type": "integer",
"store": false //默认值就是false
},
"tags": {
"type": "keyword",
"store": true //修改值为true
}
}
}
}
}
我们创建了一个名为order的索引,并定义了两个字段:counter和tags。我们将tags字段的store属性设置为true,这意味着tags字段的值将被存储为Stored Fields。而counter字段的store属性设置为false,表示不存储该字段的值。
PUT order/_doc/1
{
"counter" : 1,
"tags" : ["red"]
}
GET twitter/_doc/1?stored_fields=tags,counter
以上get操作的结果是:
{
"_index": "twitter",
"_type": "tweet",
"_id": "1",
"_version": 1,
"found": true,
"fields": { //此时多了名称为fields的字段,并且没有了_source
"tags": [ //tags的stroe属性设置为true,因此显示在结果中
"red"
]
}
}
从 document 中获取的字段的值通常是array。
由于counter字段没有存储,当尝试获取stored_fields时get会将其忽略。
在Elasticsearch中,不论将字段的store属性设置为true还是false,这些字段都会被存储。但存储的方式有所不同:
那么,在什么情况下需要将字段的store属性设置为true呢?通常有两种情况:
行存储中,占比最大的通常是_source字段,它负责保存文档的原始数据。在数据写入阶段,Elasticsearch会将整个文档的JSON结构体作为字符串存储在_source字段中。在查询时,我们可以通过_source字段检索到原始写入的完整JSON结构体。
{
"_index": "order",
"_type": "_doc",
"_id": "1",
"_version": 1,
"_seq_no": 0,
"_primary_term": 1,
"found": true,
"_source": { //默认查询数据,返回的属性字段都在_source中
"user": "kimchy",
"post_date": "2009-11-15T14:12:12",
"message": "trying out Elasticsearch"
}
}
行存储有几个重要的优点:
然而,行存储也有一些潜在的开销和限制:
在使用ES时,开发者需要根据具体的应用场景和需求来权衡行存储的利弊,并合理地配置和优化索引结构。例如,在某些场景下,可能只需要存储文档的部分字段而不是完整的JSON结构体,这可以通过在映射中关闭_source字段或只包含必要的字段来实现。然而,需要注意的是,关闭_source字段后将无法使用依赖于_source字段的ES功能,如更新、重新索引等。因此,在做出决策时需要仔细考虑。
术因分享而日新,每获新知,喜溢心扉。 诚邀关注公众号 『 码到三十五 』 ,获取更多技术资料。