ELK,萌萌哒
ES应用场景

ES应用场景

实际项目的ES性能问题,大家看看该场景是否适合用ES,如何提高?

Elasticsearchkennywu76 回复了问题 • 9 人关注 • 4 个回复 • 9038 次浏览 • 2017-03-21 16:08 • 来自相关话题

条新动态, 点击查看
根据范例里给的mapping定义来看,每个内嵌类型tab_x内部并非用于存放一个object,而是只有一个属性code,这种情况下完全没有必要用nested type,直接用object type就可以了,比如:

{
   "index1&quo... 显示全部 »
根据范例里给的mapping定义来看,每个内嵌类型tab_x内部并非用于存放一个object,而是只有一个属性code,这种情况下完全没有必要用nested type,直接用object type就可以了,比如:

{
   "index1": {
      "mappings": {
         "tag_type": {
            "dynamic": "false",
            "_all": {
               "enabled": false
            },
            "properties": {
               "tab_a": {
                  "properties": {
                     "code": {
                        "type": "string",
                        "index": "not_analyzed"
                     }
                  }
               },
               "tab_b": {
                  "properties": {
                     "code": {
                        "type": "string",
                        "index": "not_analyzed"
                     }
                  }
               },
               ......
            }
         }
      }
   }

 

其效果等同于一系列扁平的属性:
tab_a.code
tab_b.code
....
 
nested documents主要应用于外层文档和内层文档有需要join,并且需要维护内层object的独立性的场景。 在索引上实际每个内嵌的object都是单独成一条文档,因此实际生成索引的文档数会远大于外层文档数量。 而使用普通的object类型,内嵌的object被flatten成文档的一条属性而已,实际生成的文档数量小得多。 查询和聚合速度都会快很多。

实际项目的ES性能问题,大家看看该场景是否适合用ES,如何提高?

回复

Elasticsearchkennywu76 回复了问题 • 9 人关注 • 4 个回复 • 9038 次浏览 • 2017-03-21 16:08 • 来自相关话题