Elasticsearch技术选型：新增type还是新建index？

嘿，我之前刚好做过一套用Twitter API爬取推文、再索引到Elasticsearch的系统，太懂你说的object数组处理痛点了！毕竟Elasticsearch默认的object类型对数组的处理确实坑——比如你想找「包含twitter.com链接且提及了@jack」的推文，用默认类型的话，可能会匹配到一条推文中既有twitter.com的链接，又有另一个提及@jack的用户，但这俩其实根本不相关，完全不符合你的分析需求。

下面针对你提到的几个场景，分享我实际用过的解决方案：

1. 用Nested类型存储需关联分析的数组 #

这是最常用的解决方案，专门解决object数组字段关联错位的问题。比如你提到的「提及用户列表」，可以把mapping定义成nested类型：

{
  "mappings": {
    "properties": {
      "mentioned_users": {
        "type": "nested",
        "properties": {
          "user_id": {"type": "keyword"},
          "join_date": {"type": "date"},
          "username": {"type": "keyword"}
        }
      }
    }
  }
}

查询的时候必须用nested查询语法，才能保证数组内字段的关联性：

{
  "query": {
    "nested": {
      "path": "mentioned_users",
      "query": {
        "bool": {
          "must": [
            {"match": {"mentioned_users.username": "jack"}},
            {"range": {"mentioned_users.join_date": {"lt": "2010-01-01"}}}
          ]
        }
      }
    }
  }
}

这个方案特别适合需要保持数组元素内字段关联分析的场景，比如你要分析「被早期注册用户提及的推文特征」这类需求。

2. 拆分父子文档（适合超大数组或独立分析场景） #

如果你的数组元素特别多（比如一条推文里带了十几个URL），或者你需要单独对数组元素做聚合分析（比如统计所有推文中出现的域名Top10），可以把数组拆成父子文档：

• 父文档：存储推文核心信息（推文ID、发布时间、正文内容等）
• 子文档：每个子文档对应一个数组元素（比如一条子文档对应一个URL，包含域名、关联的推文ID等）
  这种方式的好处是子文档可以独立更新、聚合，不会影响父文档，查询时用has_parent/has_child语法关联即可。不过要注意，父子文档会增加索引的复杂度，更适合数据量较大的场景。

3. 分词/语义分析结果的特殊处理 #

针对推文的分词或语义分析结果，分两种情况处理：

• 如果只是需要做全文检索：直接把分词结果拼接成字符串，存在text类型字段里就行，Elasticsearch的全文检索会自动处理；
• 如果需要保留每个分词的位置、权重等细节：还是用nested类型存储每个分词的详情（比如词项、权重、出现位置），这样能支持更精细的语义分析。

4. Kibana可视化适配技巧 #

如果要在Kibana里展示这些数组数据：

• 用nested类型的话，要在Kibana的Discover面板开启「Nested Fields」支持，聚合时选择「Nested」聚合类型；
• 如果是拆分的父子文档，可以通过Kibana的数据视图关联父子索引，用关联查询展示父文档和子文档的对应数据。

最后给你提个醒：导入Twitter数据前一定要提前规划好mapping，别让Elasticsearch自动推断类型！自动推断的话，数组会被当成普通object，后续再改成nested类型就得重新建索引，非常麻烦！

内容的提问来源于stack exchange，提问作者salvob