java - Elasticsearch映射: is there a disadvantage in using type text for properties which are keyword by nature?

标签 java elasticsearch elasticsearch-5 kibana-5

我的堆栈: Elasticsearch 5.4(带有相应版本的java客户端和kibana)

您好,我在创建新索引时使用动态映射,并且在映射中使用以下部分来获取未知属性。

    {
      "string_fields": {
        "match": "*",
        "match_mapping_type": "string",
        "mapping": {
          "type": "text",
          "fields": {
            "keyword": {
              "type": "keyword",
              "ignore_above": 256
            }
          }
        }
      }
    }

我每秒索引大约 30k 个文档,并且独特的未知属性的数量可能很大(所有索引中大约 5k)。

问题:
将属性索引为文本时,我应该担心性能是否受到任何影响(延迟/计算/内存/磁盘),而实际上它们本质上应该只是关键字?

我是否应该在应用程序逻辑中努力确定每个新的未知属性是否最适合映射为文本或仅映射为关键字?

最佳答案

您绝对应该尝试识别这些字段,而不是将它们映射为文本。当文本字段通过分析管道时,会产生相关的负担。它们的值被标记、过滤和索引。

如果您需要对它们执行全文搜索,那么一定要将它们作为文本索引,否则尽量不要这样做。您将在索引时节省 CPU 周期和磁盘空间、在查询时节省堆空间以及在重新启动集群时节省时间(因为您的索引会更小)。

我在这里只触及了表面,但底线是文本带来了负担,关键字更不用说。

关于java - Elasticsearch映射: is there a disadvantage in using type text for properties which are keyword by nature?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/56152927/

相关文章:

java - android中除了数字和逗号之外,如何将TextView中的任何字母设置为白色?

elasticsearch - Elasticsearch :匹配其数组包含此字段的文档

elasticsearch - Fluent Bit Filter 将 Unix Epoch 时间戳转换为人类可读的时间格式

ruby-on-rails - 带 Elasticsearch 的Select_tag

node.js - Elasticsearch 分页来源 - 大小结果窗口太大

java - Elasticsearch 5 在长索引期间停止

java - 使用 Java 重放 post 请求

java - 功能检查是否有足够的库存来满足要求

java - 不带容器的 JAX-RS

elasticsearch - Sankt和St的同义词