[Elasticsearch] Elasticsearchは、特定の期間の履歴データをどのように物理的に削除しますか?

ここに写真の説明を挿入

1。概要

転載:https://blog.csdn.net/laoyang360/article/details/80038930

1.碑文
削除について考えると、基本的な認識は削除であり、ドキュメントの削除とインデックスの削除に細分されます。履歴データを削除するには、基本的な認識は次のとおりです。特定の条件でデータを削除するには、delete_by_queryを使用します。
実際の操作が見つかりました:

  • ドキュメントを削除した後、ディスク容量はすぐには減少しませんでしたが、増加しましたか?
  • 時限タスク+ delete_by_queryとは別に、より良い方法はありますか?

2.一般的な削除操作
2.1単一のドキュメントを削除します

DELETE /twitter/_doc/1

2.2指定された条件を満たすドキュメントを削除する

POST twitter/_delete_by_query
{
    
    
  "query": {
    
     
    "match": {
    
    
      "message": "some message"
    }
  }
}

注:バッチ削除を実行すると、バージョンの競合が発生する可能性があります。削除を強制する方法は次のとおりです。

POST twitter/_doc/_delete_by_query?conflicts=proceed
{
    
    
  "query": {
    
    
    "match_all": {
    
    }
  }
}

2.3単一のインデックスを削除する

DELETE /twitter

2.4すべてのインデックスを削除する

DELETE /_all

または

DELETE /*

すべてのインデックスを削除することは非常に危険な操作なので、注意してください。

3.舞台裏でドキュメントを削除するために何をしましたか?
削除後の戻り結果:

{
    
    
  "_index": "test_index",
  "_type": "test_type",
  "_id": "22",
  "_version": 2,
  "result": "deleted",
  "_shards": {
    
    
    "total": 2,
    "successful": 1,
    "failed": 0
  },
  "_seq_no": 2,
  "_primary_term": 17
}

解釈:

インデックス内のすべてのドキュメントはバージョン管理されています。
ドキュメントを削除するときに、バージョンを指定して、削除しようとしている関連ドキュメントが実際に削除され、この期間中に変更されていないことを確認できます。

削除を含め、ドキュメントに対して実行されるすべての書き込み操作により、そのバージョンが増加します。

削除するリアルタイム:

ドキュメントを削除しても、ドキュメントはディスクからすぐには削除されません。削除済みとしてマークするだけです。Elasticsearchは、さらに多くのデータのインデックスを作成し続けると、バックグラウンドで削除されたドキュメントをクリーンアップします。

4.インデックスの削除とドキュメントの削除の違いは何ですか?
1)インデックスを削除すると、すぐにスペースが解放され、いわゆる「マーキング」ロジックはありません。

2)ドキュメントを削除すると、新しいドキュメントが書き込まれ、古いドキュメントに削除済みのマークが付けられます。ディスクスペースが解放されるかどうかは、新しいドキュメントと古いドキュメントが同じセグメントファイルにあるかどうかによって異なります。したがって、ESバックグラウンドのセグメントマージにより、セグメントファイルのマージプロセス中に古いドキュメントが物理的に削除される場合があります。

ただし、シャードには数百のセグメントファイルが含まれている可能性があるため、古いドキュメントと新しいドキュメントが異なるセグメントに存在し、物理的に削除できない可能性が高くなります。手動でスペースを解放したい場合は、定期的に強制マージを実行し、max_num_segmentsを1に設定する必要があります。

POST /_forcemerge

5.過去100日間のデータのみを保存するにはどうすればよいですか?
上記の知識により、100日近くのデータを保存するタスクは次のように分類されます。

  • 1)100日近くのデータを取得するためのdelete_by_query設定。
  • 2)forcemerge操作を実行して、手動でディスク領域を解放します。

削除スクリプトは次のとおりです。

#!/bin/sh
curl -H'Content-Type:application/json' -d'{
    
    
    "query": {
    
    
        "range": {
    
    
            "pt": {
    
    
                "lt": "now-100d",
                "format": "epoch_millis"
            }
        }
    }
}
' -XPOST "http://192.168.1.101:9200/logstash_*/
_delete_by_query?conflicts=proceed"

マージスクリプトは次のとおりです。

#!/bin/sh
curl -XPOST 'http://192.168.1.101:9200/_forcemerge?
only_expunge_deletes=true&max_num_segments=1'

6.より一般的な方法はありますか?
はい、ES公式ウェブサイトツールキュレーターツールを使用してください。

6.1キュレーターの概要
主な目的:ESインデックスの計画と管理。一般的な操作をサポートします:作成、削除、マージ、インデックスの再作成、スナップショット、その他の操作。

6.2キュレーターの公式ウェブサイトアドレス
http://t.cn/RuwN0oM

Gitアドレス:https://github.com/elastic/curator

6.3キュレーターインストールウィザード
アドレス:http://t.cn/RuwCkBD

注:
キュレーターのブログとチュートリアルは無限ですが、古いバージョンと新しいバージョンのキュレーターには大きな違いがあります。公式Webサイトで最新の手動展開を参照することをお勧めします。
古いバージョンのコマンドラインメソッドは、新しいバージョンではサポートされなくなりました。

6.4キュレーターのコマンドライン操作

$ curator --help
Usage: curator [OPTIONS] ACTION_FILE

  Curator for Elasticsearch indices.

  See http://elastic.co/guide/en/elasticsearch/client/curator/current

Options:
  --config PATH  Path to configuration file. Default: ~/.curator/curator.yml
  --dry-run      Do not perform any changes.
  --version      Show the version and exit.
  --help         Show this message and exit.

芯:

  • 構成ファイルconfig.yml:接続するESアドレス、ログ構成、ログレベルなどを構成します。

実行ファイルaction.yml:実行する操作を構成し(バッチ処理可能)、インデックス形式を構成します(プレフィックスマッチング、通常のマッチングなど)
。6.5キュレーターの適用可能なシナリオ
最も重要なことは次のとおりです。

削除操作を例にとると、キュレーターはx日後に非常に簡単にインデックスを削除できます。前提として、インデックスの名前付けは特定の名前付けパターンに従う必要があります。たとえば、その日の名前が付けられたインデックス:logstash_2018.04.05。

命名パターンは、action.ymlのdelete_indicesの下のタイムストリングに対応している必要があります。

7.まとめ
公式ウェブサイトの最新のドキュメントを参照してください。履歴バージョンの履歴ドキュメントは誤解を招きやすいです。
知っているだけでなく、もっと練習してください
。medcl:ES 6.3の新しいバージョンには、インデックスストレージを簡単に管理できるインデックスライフサイクル管理があります。用語。

おすすめ

転載: blog.csdn.net/qq_21383435/article/details/109280911