Lucene ElasticSearch索引大小减小，而docs.count增大

我注意到ElasticSearch（5.5.0版）中有一个奇怪的行为，store.size减少，docs.count增加。为什么会发生这种情况

$ curl 'localhost:9201/_cat/indices/index-name:2017-08-08?bytes=b&v'
health status index                 uuid                   pri rep docs.count docs.deleted store.size pri.store.size
green  open   index-name:2017-08-08 PlpLYu5vTN-HFA_ygHUNwg  17   1    5577181       212434 3827072602     1939889776

$ curl 'localhost:9201/_cat/indices/index-name:2017-08-08?bytes=b&v'
health status index                 uuid                   pri rep docs.count docs.deleted store.size pri.store.size
green  open   index-name:2017-08-08 PlpLYu5vTN-HFA_ygHUNwg  17   1    5581202       204815 3812410150     1927833617

请注意，虽然docs.count从5577181->5581202增加，但store.size和pri.store.size都减少了

在后台，我尝试使用索引大小来限制数据进入ES（即每天xGB）。但是，我注意到，随着我继续索引，索引大小会定期减小（每小时或每分钟左右）。这不是一个好的节流方式，因为存储大小并没有严格地增加

1） 知道为什么索引大小会减小吗？ 2） 我是否应该使用另一个严格增加的尺码

编辑： 实际上，即使没有删除的文档，文档数量仍然会减少。见下文

$curl-s localhost:9200/_cat/index | grep name绿色开放 索引名称：2017-08-11
EIGIDGEZQ5CQSU3TAALRGW11117172010.4mb 109.5mb$curl-s localhost:9200/_cat/index | grep name绿色打开 索引名称：2017-08-11
eIGiDgeZQ5CqSu3tAaLRgw 1 1 132329 0 204.7mb 103.2mb

---

因此，您有4021个额外的文档（=5581202-5577181），但您也可以注意到，已删除文档的计数

docs.deleted

也减少了7619个文档（=212434-204815），因此索引中的文档净计数为-3598。这是由于Lucene在引擎盖下清理已删除的文档并尝试重新获得一些未使用的空间

这就是总索引大小减少14662452字节（~14MB）的最可能原因

---

如果你想限制，你可以使用

docs.count

来代替，如果你一直在索引，这个数字应该会增加。

因此你有4021个额外的文档（=5581202-5577181），但是你也可以注意到，被删除的文档

docs.deleted

的数量也减少了7619个文档（=212434-204815）因此，索引中文档的净计数是-3598。这是由于Lucene在引擎盖下清理已删除的文档并尝试重新获得一些未使用的空间

这就是总索引大小减少14662452字节（~14MB）的最可能原因

---

如果您想限制，可以使用

docs.count

来代替，如果您一直在索引，那么这个数字应该会增加。

Elasticsearch集群会随着时间压缩索引-因此_statsAPI操作可能会显示索引大小缩小（直到停止）。对于类似的文档，索引甚至可能压缩40%

---

编辑：如上所述，只要文档被索引，引擎盖下的段合并就会随着时间的推移而发生。在每个段合并后，新段上似乎（模糊地）发生了压缩，因此假设索引大小可能会减小。

Elasticsearch cluster会随着时间压缩索引-因此_statsAPI操作可能会显示索引大小缩小（直到停止）。对于类似的文档，索引甚至可能压缩40%

---

编辑：如上所述，只要文档被索引，引擎盖下的段合并就会随着时间的推移而发生。在每个段合并之后，新段上似乎（模糊地）发生了压缩，因此假设索引大小可能会减小。

您知道为什么会有删除的文档吗？我只是在索引。如果您再次索引文档（即使用相同ID），则当前文档将标记为已删除且未替换。已删除的文档不一定是通过HTTP DELETE删除的文档，而是现有文档的所有旧版本。这就是为什么Lucene定期通过合并段和删除删除的文档来清理索引。嗯，我不希望有任何更新，因为我应该一直为新文档编制索引，但我可能必须重新查看我的代码才能确保。谢谢很酷，很高兴它有帮助！但是，对于你每天3GB的索引来说，17个主要的碎片听起来比需要的多得多。单个分片可以容纳数GB的数据。当然，我不知道你的用例。你知道为什么会有被删除的文档吗？我只是在索引。如果您再次索引文档（即使用相同ID），则当前文档将标记为已删除且未替换。已删除的文档不一定是通过HTTP DELETE删除的文档，而是现有文档的所有旧版本。这就是为什么Lucene定期通过合并段和删除删除的文档来清理索引。嗯，我不希望有任何更新，因为我应该一直为新文档编制索引，但我可能必须重新查看我的代码才能确保。谢谢很酷，很高兴它有帮助！但是，对于你每天3GB的索引来说，17个主要的碎片听起来比需要的多得多。单个分片可以容纳数GB的数据。当然，我不知道你的用例。