我最近开始使用ElasticSearch 2.当我在映射中找不到已分析 vs not_analyzed 时,not_analyzed在存储方面应该更好(https://www.elastic.co/blog/elasticsearch-storage-the-true-story-2.0和{{ 3}})。 出于测试目的,我创建了一些索引,其中包含所有String字段(默认情况下),然后我创建了一些其他索引,其中所有字段都是not_analyzed,当我检查索引的大小并且我看到索引时出现了not_analyzed字符串是40%更大 !!我在每个索引中插入相同的文档(35000个文档)。
知道为什么会这样吗?我的文档是简单的JSON文档。我在每个文档中有60个字符串字段,我想将其设置为not_analyzed,我尝试将每个字段设置为未分析并创建动态模板。
我编辑添加映射,虽然我觉得它没什么特别的:
{
"mappings": {
"my_type" : {
"_ttl" : { "enabled" : true, "default" : "7d" },
"properties" : {
"field1" : {
"properties" : {
"field2" : {
"type" : "string", "index" : "not_analyzed"
}
more not_analyzed String fields here
...
...
...
}
答案 0 :(得分:6)
await await
个字段仍然已编入索引。他们事先没有对他们进行过任何转换("分析" - 用Lucene的说法)。
举个例子:
(文件1)"快速的棕色狐狸跳过懒狗"
(Doc 2)"像狐狸一样懒惰"
- 标准分析器创建的简化发布列表(
醇>not_analyzed
字符串字段的默认值 - 标记化,小写,删除停用词):
analyzed
30个字符的字符串数据
- 醇>
"brown": [1] "dog": [1] "fox": [1,2] "jumped": [1] "lazy": [1,2] "over": [1] "quick": [1]
创建的简化发布列表:
"index": "not_analyzed"
62个字符的字符串数据
分析导致输入被标记化并标准化,以便能够使用术语查找文档。
但结果是,文本单位缩减为标准化术语(与"The quick brown fox jumped over the lazy dog": [1]
"Lazy like the fox": [2]
)的整个字段相对应,以及所有冗余(标准化)术语所有文档都会折叠为单个逻辑列表,为您节省重复术语和停用词通常会占用的所有空间。
答案 1 :(得分:1)
从the documentation开始,not_analyzed
似乎使该字段的行为类似于"关键字"而不是"全文" field - 让我们比较这两个!
分析这些字段,即在索引之前将它们传递给分析器以将字符串转换为单个术语列表。
关键字字段未经过分析。相反,确切的字符串值将作为单个术语添加到索引中。
毫不奇怪,将整个字符串存储为术语,而不是将其分成术语列表,并不一定能转化为节省的空间。老实说,它可能取决于索引的分析器和被索引的字符串。
作为旁注,我只重新索引了大约一百万份生产数据文档,并将索引磁盘空间使用量减少了约95%。我做的主要区别是修改了源中实际保存的内容(存储了AKA)。我们将PDF索引用于搜索,但不需要返回它们,这样我们就可以用两种不同的方式保存这些信息(分析和原始)。但是,有一些very real downsides,所以要小心!
答案 2 :(得分:0)
Doc1 { “名称”:“我的名字是mayank kumar” }
Doc2。{ “名称”:“ mayank” }
Doc3。{ “名称”:“玛雅克” }
我们有3个文档。
因此,如果字段'name'为'not_analyzed'并且我们搜索'mayank',则仅返回第二个文档。如果我们搜索'Mayank',则仅返回第三个文档。
如果字段“名称”被分析器“小写字母分析器”“分析”(仅作为示例)。我们搜索“ mayank”,将返回所有3个文档。 如果我们搜索“ kumar”,则会返回第一个文档。这是因为在第一个文档中,字段值被标记为“我”,“名称”,“是”,“ mayank”,“ kumar”
“ not_analyzed”基本上用于“全文本”搜索(主要用于通配符匹配除外)。磁盘上的空间更少。索引期间所需的时间更少。
'analyzed'主要用于匹配文档。磁盘上有更多空间(如果分析字段很大)。在索引过程中花费更多时间。(由于分析字段而导致更多字段)