ElasticSearch多字段存储问题

问题背景 由于term和match查询分别对应了keyword和text类型, 一般情况下一个字段属性只需要设置单独类型，但是由于应用场景不同, 经常会涉及到多属性的设置,本次主要测试在单字段属性多个类型条件下,对ES存储容量的影响占用情况。

文章目录

• • • 1. 步骤一: 新建两个测试库
    • 2. 步骤二：测试查询效果
    • 3. 步骤三：查看集群的存储信息/集群状况
    • 4. 步骤四：10000 文章样本量下的存储差异
    • 5. 结论总结与推测

1. 步骤一: 新建两个测试库

• [9200端口text1]：content字段仅包含text属性

• [9201端口text2]：content字段包含text和keyword属性

  

2. 步骤二：测试查询效果

# 往 text1,text2库中分别插入一篇文章  content = 
托塔李天王家的三太子，最早传说来自古波斯和古印度教的神话，随着本土化的传教，宋代起就从古盛传至今，由佛教护法军神“那咤”演变而成 
[6]  ，故事已在唐末有之，主要定型于闹海传说与屠龙之说的内容，以及降魔伏妖再成仙成圣等古籍文献，出生奇异，一身神器，能变化三头六臂又或三头八臂，百邪不侵专克摄魂夺魄的莲花化身。在中国各地成为世代传奇且家喻户晓的著名艺术形象；后期影响民间奉祀为保护神，并渐被道教所吸纳，将其遵崇供为中央祭坛的大罗天神，地位高贵鼎盛；神仙谱中被归类为“忠武战神”之位，属于武神一系。在民俗被尊为护世护民的“五营神将”之首；乃统领天兵天将的元帅之神，又称“太子元帅”，还被敬作“天帅领袖”和“火轮天王”，常以娃娃或者少年儿童的模样登场，终成神话史上独特无双、神通广大的天庭童神。在儒释道三体合流相融的文化传承中，得享华人的普遍崇拜与信仰。更因为其鲜明精彩的古老形象与经典传说故事名气响亮，从而吸引现代众多动漫和影视剧都将哪吒设定为主角，加以儿童化的少年英雄方式传扬，深受诸多孩子们的欢迎和喜爱。
           

1.在text1中，插入的content文本应该是以分词结果存储

2.在text2中, 插入的content文本应该是以分词结果存储,content.keyword文本应该是以完整段落存储

3.如果某个词，比如"在民俗"的分词结果不是连续的,则text1中无法通过term的正则方式查询到,而在text2中可以content.keyword则可以查询到,符合我们对其的存储理解

4.测试结果确实如此

• text1 text属性分词查询结果,为null

• text2 text属性分词查询结果,为null

• text2 keyword 属性不分词查询结果,查询到值,能符合全部场景的查询

3. 步骤三：查看集群的存储信息/集群状况

/_cat/indices?v

• text1 9200 单文本8.7K

• text1 9201 单文本14.4K

猜测 多字段存储会占用更多的存储空间,说明其本地存储是存为了 分词结果 和 不分词结果 两部分信息， 加大样本量再试一次

4. 步骤四：10000 文章样本量下的存储差异

• text1 9200 单文本2.8M

• text1 9201 单文本2.7M

5. 结论总结与推测

结论分析 这个结论基本完全颠覆了之前的猜测, 加上text和keyword多字段属性的存储量为2.7MB，而仅仅设置为text字段的属性竟然还比之多了0.1MB,为2.8MB

结论推测:

1. keyword 不分词的存储方式比分词的存储方式更省存储空间
2. ES内部对数据的存储做了高度压缩和优化,多个fields的属性存储空间可能更优于单fields存储
3. ES内部对数据的存储方式并不是我们以为的那样对分词数据和不分词数据做分开存储,应该是有一种特殊的数据存储格式,并且它兼容了term查询和text查询
4. 在实际应用中,不用去担心由于属性设置多个字段可能引起的数据存储量疯狂爆炸的情况.可以完全放心的去为属性设置多个fields，以此来满足不同业务场景下的需求, 尤其是在进行数据文本检索的时候。
   • tips1:这也是做本次实验的初衷, 现在业务数据量比较大业务场景多变, 需要在原有text属性上扩充多个属性,怕占用太多存储因此做了这个实验,毕竟ES的存储就是钱。
   • tips2:设置多字段属性之后, 只会对新插入的数据生效,对已有的旧数据不会生效,毕竟底层存储形式发生了改变

----------------------------------- >

如有其它问题,也可以咨询本人

微信:w63594021