【问题标题】:Elasticsearch index size is 40% larger in 5.x than in 1.x5.x 中的 Elasticsearch 索引大小比 1.x 大 40%
【发布时间】:2017-03-17 07:50:00
【问题描述】:

我有一个运行 Elasticsearch 1.4.4 的旧集群。 我的集群包含约 110 亿个文档,所有初选的大小约为 4TB

我现在正在升级到 Elasticsearch 5.2.2,这当然意味着要重新索引我的数据。我有一个单独的集群,目前正在发生这种情况。我正在从我的源数据库重新索引,因为我在原始索引上禁用了 _all_source

我现在已经重新索引了大约 7.5 亿个文档,并注意到我的新索引大小已经是 350GB。我做了一些数学运算,看起来索引在完全索引时会增长到 5.5TB 左右。这比1.4.4 索引多1.5TB。我没想到会这样。相反,我预计尺寸会减小,因为我已经删除了几个属性。这是正常的事情还是我做错了什么? 5.2.2 中是否有不同的默认设置可以促进这种增长?

1.4.4 索引设置:

{
  "index": {
    "refresh_interval": "30s",
    "number_of_shards": "20",
    "creation_date": "1426251049131",
    "analysis": {
      "analyzer": {
        "default": {
          "filter": [
            "icu_folding",
            "icu_normalizer"
          ],
          "type": "custom",
          "tokenizer": "icu_tokenizer"
        }
      }
    },
    "uuid": "WdgnCLyITgmpb4DROegV3Q",
    "version": {
      "created": "1040499"
    },
    "number_of_replicas": "1"
  }
}

1.4.4 索引映射:

{
  "article": {
    "_source": {
      "enabled": false
    },
    "_all": {
      "enabled": false
    },
    "properties": {
      "date": {
        "format": "dateOptionalTime",
        "type": "date",
        "doc_values": true
      },
      "has_enclosures": {
        "type": "boolean"
      },
      "feed_subscribers": {
        "type": "integer",
        "doc_values": true
      },
      "feed_language": {
        "index": "not_analyzed",
        "type": "string"
      },
      "author": {
        "norms": {
          "enabled": false
        },
        "analyzer": "keyword",
        "type": "string"
      },
      "has_pictures": {
        "type": "boolean"
      },
      "title": {
        "norms": {
          "enabled": false
        },
        "type": "string"
      },
      "content": {
        "norms": {
          "enabled": false
        },
        "type": "string"
      },
      "has_video": {
        "type": "boolean"
      },
      "url": {
        "index": "not_analyzed",
        "type": "string"
      },
      "feed_canonical": {
        "type": "boolean"
      },
      "feed_id": {
        "type": "integer",
        "doc_values": true
      }
    }
  }
}

5.2.2 索引设置:

{
  "articles": {
    "settings": {
      "index": {
        "refresh_interval": "-1",
        "number_of_shards": "40",
        "provided_name": "articles",
        "creation_date": "1489604158595",
        "analysis": {
          "analyzer": {
            "default": {
              "filter": [
                "icu_folding",
                "icu_normalizer"
              ],
              "type": "custom",
              "tokenizer": "icu_tokenizer"
            }
          }
        },
        "number_of_replicas": "0",
        "uuid": "LOeOcZb_TMCX6E_86uMyXQ",
        "version": {
          "created": "5020299"
        }
      }
    }
  }
}

5.2.2 索引映射:

{
  "articles": {
    "mappings": {
      "article": {
        "_all": {
          "enabled": false
        },
        "_source": {
          "enabled": false
        },
        "properties": {
          "author": {
            "type": "text",
            "norms": false,
            "analyzer": "keyword"
          },
          "content": {
            "type": "text",
            "norms": false
          },
          "date": {
            "type": "date"
          },
          "feed_canonical": {
            "type": "boolean"
          },
          "feed_id": {
            "type": "integer"
          },
          "feed_subscribers": {
            "type": "integer"
          },
          "title": {
            "type": "text",
            "norms": false
          },
          "url": {
            "type": "keyword"
          }
        }
      }
    }
  }
}

任何帮助都将不胜感激,因为在此集群上完全重新索引大约需要 30 天...谢谢!

【问题讨论】:

    标签: elasticsearch


    【解决方案1】:

    我的猜测是 doc_values。 从 elastic 2.0 开始,默认启用 doc_values,这意味着您的 5.2 映射为比 1.4 映射更多的字段创建 doc_values,这会消耗磁盘空间。

    【讨论】:

    • 这是我最初的想法,因为它看起来很常见。但是,如果您看到我的 1.4.4 索引,我已经在我保留在新索引中的相同字段上显式启用了 doc_values。上一个索引中只有一个布尔字段没有 doc_values,但我非常怀疑这种开销是否来自它。如果是这样,那么我将重新开始重新索引过程,但我已经 3 天了......如何确定?
    • 我计算了 2 个字段在 1.4 中没有 doc 值,在 5 中:url、feed_canonical。它可以解释大小的增长,即使删除了 4 个布尔属性(它们可能是高度可压缩的,并且不需要太多空间)。除此之外,了解集群中有多少节点、多少索引、分片大小、是否有任何文档路由等会很有用。
    • 如果可能的话,也许开始第二个摄取过程 - 与第一个并行 - 使用修改后的 5 映射,以获得“足够好”数量的文档(100 - 2 亿),并且然后再次估计新尺寸
    • 我不认为 URL 是 not_analyzed 字段。这可能真的是罪魁祸首。我已经开始了并行索引,并会在一两天内报告新索引增长到足够的情况。我没有提到我的集群的规格,以便将重点放在索引大小上,而不是性能上。如果你有兴趣,可以查看我对@asettouf 的回复。
    • 您将问题集中在索引大小上是正确的,但我没有要求机器规格,而是其他相关配置参数,例如索引数、分片数(它们是否与1.4 集群)、文档路由等。这些参数会影响数据的压缩率...
    【解决方案2】:

    我看到你修改了刷新间隔,将副本数设置为0,如果使用旋转磁盘,可以添加到 elasticsearch.yml 以提高索引速度:

    index.merge.scheduler.max_thread_count: 1
    

    如果您还不关心搜索,您的 ES5 集群上的以下内容也可能会有所帮助:

    PUT /_cluster/settings
    {
        "transient" : {
            "indices.store.throttle.type" : "none" 
        }
    }
    

    确保您已禁用交换。 ES5 集群中的节点分配了多少内存? (由于 Elasticsearch 的内存寻址限制,您应该使用节点总可用内存的一半,上限为 32 GB)。

    此外,这种大小的增加可能是因为 Elasticsearch 不经常合并其段,并且会等待更平静的时期来合并它们,从而减少磁盘上的大小。只要重新索引没有结束,判断新索引的整体规模还为时过早。

    以下几篇文章可能会有所帮助:

    【讨论】:

    • 感谢您的建议。索引速度不是我关心的。它做得很好。服务器非常强大,并且针对 ES 进行了优化。你所说的段合并是有道理的,我确实注意到了一些波动,但指数仍然大得多。我怀疑它只会在段合并的情况下最终缩小这么多。
    • 我知道 30 天对于您拥有的大小来说是很多天(虽然我也不知道您的集群的大小)关于磁盘空间,这篇文章分享了一个有趣的经验方式:blog.discordapp.com/…
    • 集群在 3 台服务器上运行良好(现在增加了第 4 台),每台服务器都有 64G RAM,4x900GB SSD。源数据在价值 11TB 的 MySQL 数据库中,它们是运行繁忙服务的生产数据库,所以显然我不能将它们推到极限。瓶颈不是ES。我唯一关心的是最后的整体索引大小。
    • 必须同意 asettouf 的意见。 30 天对于索引 110 亿份文档来说是一段很长的时间,尽管它们很小。除非您对自己的摄取过程非常有信心,否则我会设法提高从您的源数据库读取的速度。
    猜你喜欢
    • 2018-07-08
    • 2017-03-29
    • 2021-05-02
    • 1970-01-01
    • 1970-01-01
    • 2017-04-04
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多