このトピックでは、オープンソース Elasticsearch に関するよくある質問への回答を提供します。
概要
インデックスのスレッドプールサイズを設定するにはどうすればよいですか?
Elasticsearch クラスタの YML 設定ファイルで、thread_pool.write.queue_size パラメーターを指定してスレッドプールサイズを設定します。詳細については、「YML ファイルの設定」をご参照ください。
6.X より前のバージョンの Elasticsearch クラスタの場合は、thread_pool.index.queue_size パラメーターを使用してスレッドプールサイズを設定します。
OOM が発生した場合はどうすればよいですか?
次のコマンドを実行してキャッシュをクリアします。次に、原因を分析し、Elasticsearch クラスタの構成をアップグレードするか、ビジネスを調整します。クラスタ構成のアップグレード方法の詳細については、「クラスタ構成のアップグレード」をご参照ください。
curl -u elastic:<password> -XPOST "localhost:9200/<index_name>/_cache/clear?pretty"
パラメーター | 説明 |
| Elasticsearch クラスタへのアクセスに使用するパスワード。パスワードは、クラスタの作成時または Kibana の初期化時に指定します。 |
| インデックスの名前。 |
シャードを手動で管理するにはどうすればよいですか?
reroute API または Cerebro を使用します。詳細については、「Cluster reroute API」および「Cerebro」をご参照ください。
Elasticsearch のキャッシュクリアポリシーとは何ですか?
Elasticsearch は、次のキャッシュクリアポリシーをサポートしています。
すべてのインデックスのキャッシュをクリアする
curl localhost:9200/_cache/clear?pretty
特定のインデックスのキャッシュをクリアする
curl localhost:9200/<index_name>/_cache/clear?pretty
複数インデックスのキャッシュをクリアする
curl localhost:9200/<index_name1>,<index_name2>,<index_name3>/_cache/clear?pretty
インデックスシャードを再ルーティングするにはどうすればよいですか?
一部のシャードが失われた場合、または不適切に割り当てられている場合は、次のコマンドを実行してシャードを再ルーティングできます。
curl -XPOST 'localhost:9200/_cluster/reroute' -d '{
"commands" : [ {
"move" :
{
"index" : "test", "shard" : 0,
"from_node" : "node1", "to_node" : "node2"
}
},
{
"allocate" : {
"index" : "test", "shard" : 1, "node" : "node3"
}
}
]
}'
インデックスをクエリすると、「statusCode: 500
」というエラーメッセージが表示されます。どうすればよいですか?
Cerebro などのサードパーティ製プラグインを使用してインデックスをクエリすることをお勧めします。
クエリが成功した場合、問題は無効なインデックス名によって発生しています。この場合は、インデックス名を変更します。インデックス名には、文字、アンダースコア(_)、数字のみを含めることができます。
クエリが失敗した場合、問題はインデックスまたはクラスタのエラーによって発生しています。この場合は、クラスタにインデックスが保存されているかどうか、およびクラスタが正常な状態で実行されているかどうかを確認します。
auto_create_index
パラメーターの値を変更するにはどうすればよいですか?
次のコマンドを実行します。
PUT /_cluster/settings
{
"persistent" : {
"action": {
"auto_create_index": "false"
}
}
}
auto_create_index
パラメーターのデフォルト値は false です。この値は、システムがインデックスを自動的に作成しないことを示します。ほとんどの場合、このパラメーターの値を変更しないことをお勧めします。そうしないと、過剰なインデックスが作成され、インデックスのマッピングまたは設定が期待どおりにならない可能性があります。
OSS に保存されるスナップショットの作成にはどのくらいの時間がかかりますか?
クラスタのシャード数、メモリ使用量、ディスク使用量、CPU 使用率が正常な場合、80 GB のインデックスデータのスナップショットを作成するには約 30 分かかります。
インデックスを作成するときに、シャードの数を指定するにはどうすればよいですか?
合計データサイズを各シャードのデータサイズで割ることで、シャードの数を求めることができます。各シャードのデータサイズを 30 GB に制限することをお勧めします。各シャードのデータサイズが 50 GB を超えると、クエリのパフォーマンスに大きな影響が出ます。
シャードの数を適切に増やすと、インデックスの作成速度を上げることができます。シャードの数が少ないか多いかに関係なく、クエリのパフォーマンスは影響を受けます。
シャードは異なるノードに保存されます。シャードの数が大きい値に設定されている場合、開く必要があるファイルが増え、ノード間のやり取りが増えます。これにより、クエリのパフォーマンスが低下します。
シャードの数が小さい値に設定されている場合、各シャードにより多くのデータが保存されます。これにより、クエリのパフォーマンスも低下します。
elasticsearch-repository-oss プラグインを使用して自己管理型 Elasticsearch クラスタからデータを移行すると、次のエラーメッセージが表示されます。どうすればよいですか?
エラーメッセージ:ERROR: This plugin was built with an older plugin structure. Contact the plugin author to remove the intermediate "elasticsearch" directory within the plugin zip
。
解決策:ZIP プラグインパッケージの名前を elasticsearch から elasticsearch-repository-oss に変更し、パッケージを plugins ディレクトリにコピーします。
Kibana コンソールでのデータ視覚化のタイムゾーンを変更するにはどうすればよいですか?
Kibana コンソールでタイムゾーンを変更できます。この例では、Elasticsearch 6.7.0 クラスタを使用しています。次の図は、選択されたタイムゾーンを示しています。
Elasticsearch タームクエリを実行できるデータ型は何ですか?
タームクエリは単語レベルのクエリであり、数値、日付、テキスト以外のキーワードなどの構造化データに対して実行できます。
全文クエリを実行すると、システムはテキスト内の単語を分割します。単語レベルのクエリを実行すると、システムは関連フィールドを含む転置インデックスを直接検索します。単語レベルのクエリは、一般に数値または日付データ型のフィールドに対して実行されます。
Elasticsearch でエイリアスを使用する場合の注意事項は何ですか?
同じエイリアスを持つインデックスのシャードの合計数は 1,024 未満である必要があります。
クエリ中に too_many_buckets_exception
エラーメッセージが返された場合はどうすればよいですか?
エラーメッセージ:"type": "too_many_buckets_exception", "reason": "Trying to create too many buckets. Must be less than or equal to: [10000] but was [10001]
。
解決策:バケット集計の size パラメーターの値を変更できます。詳細については、「Limit the number of buckets that can be created in an aggregation」をご参照ください。「Increasing max_buckets for specific Visualizations」に記載されている手順に基づいてこの問題を解決することもできます。
複数のインデックスを一度に削除するにはどうすればよいですか?
デフォルトでは、Elasticsearch で複数のインデックスを一度に削除することはできません。削除を有効にするには、次のコマンドを実行します。次に、ワイルドカードを使用して複数のインデックスを一度に削除します。
PUT /_cluster/settings
{
"persistent": {
"action.destructive_requires_name": false
}
}
script.painless.regex.enabled パラメーターの値を変更できますか?
ほとんどの場合、script.painless.regex.enabled パラメーターにはデフォルト値の false が使用され、値を変更しないことをお勧めします。Painless スクリプトで正規表現を使用する場合は、elasticsearch.yml 設定ファイルで script.painless.regex.enabled パラメーターを true に設定できます。正規表現は大量のリソースを消費します。オープンソース Elasticsearch では、script.painless.regex.enabled パラメーターに true 値は推奨されません。したがって、不要な場合は、パラメーターを true に設定しないことをお勧めします。
Elasticsearch クラスタ内のインデックスのマッピング設定、プライマリシャードの数、レプリカシャードの数を変更するにはどうすればよいですか?
既存のインデックスのマッピング設定を変更する場合は、データを再インデックスすることをお勧めします。
説明マッピング設定でサポートされているフィールドタイプの詳細については、「データフィールドタイプ」をご参照ください。
既存のインデックスのプライマリシャードの数を変更することはできません。プライマリシャードの数がビジネス要件を満たせない場合は、reindex API を呼び出してデータを再インデックスできます。
説明インデックスの作成後に調整を防ぐために、インデックスを作成する前にプライマリシャードとレプリカシャードの数を計画することをお勧めします。
既存のインデックスの各プライマリシャードのレプリカシャードの数を変更する場合は、次のコマンドを実行できます。
PUT test/_settings { "number_of_replicas": 0 }
フィールドの値を保存したい場合はどうすればよいですか?
デフォルトでは、Elasticsearch は _source
フィールド以外のフィールドの値を保存しません。フィールドの値を保存する場合は、関連インデックスのマッピング設定の store プロパティをフィールドに対して true に設定できます。
_source
フィールドには元の JSON ドキュメントが含まれており、ドキュメントから任意のフィールドを検索できます。使用されるディスク容量を削減するために、フィールド値の保存を有効にしないことをお勧めします。
次のコードは、my_field
フィールドの値を保存する方法の例を示しています。
PUT / my_index {
"mappings": {
"properties": {
"my_field": {
"type": "text",
"store": true
}
}
}
}
特定のフィールドを集計したい場合、または集計したくない場合はどうすればよいですか?特定のフィールドを集計したい場合、または集計したくない場合はどうすればよいですか?
フィールドを集計できるかどうかは、フィールドのデータ型と、関連するフィールドデータ(doc_values または fielddata)が存在するかどうかによって異なります。
デフォルトでは、数値型、日付型、またはキーワード型のフィールドは、doc_values に基づいて集計できます。
説明doc_values は、並べ替え、集計、およびスクリプト操作用に最適化された列指向のストレージモデルを示します。
デフォルトでは、テキスト型のフィールドは集計できません。このようなフィールドを集計する必要がある場合は、マッピング設定で fielddata を有効にする必要があります。
説明fielddata を有効にすると、すべてのテキストデータがメモリにロードされます。これにより、メモリ使用量が大幅に増加します。
PUT /my_index{ "mappings": { "properties": { "my_text_field": { "type": "text", "fielddata": true } } } }
フィールドを集計したくない場合は、次のいずれかの方法を使用してこれを実装できます。アプリケーションロジックに基づいて方法を選択できます。
フィールドの enabled プロパティを false に設定します。
関連ドキュメントからフィールドを除外します。
どうすればよいですか?"Unknown char_filter type [stop] for **"
エラーメッセージが表示された場合はどうすればよいですか?Elasticsearch を構成するときにエラーメッセージが表示されるのはなぜですか?
Elasticsearch を設定するときに「Unknown char_filter type [stop] for **
」というエラーメッセージが表示された場合は、char_filter
部分に stop タイプが指定されています。ただし、stop タイプのフィルターは、character filter
ではなく token filter
です。
解決策:
設定場所を修正する:ストップワードフィルターを使用する場合は、stop 設定を
char_filter
からアナライザー設定の filter 部分に移動します。ストップワードフィルターは、指定されたストップワードをトークンストリームから削除するために使用されます。例:
"settings": { "analysis": { "analyzer": { "my_custom_analyzer": { "type": "custom", "tokenizer": "standard", "filter": [ // filter 配列に filter タイプを指定します。 "lowercase", "stop" // stop タイプのトークンフィルターを使用します。 ] } }, "filter": { // 必要に応じて、stop タイプのトークンフィルターの設定を定義します。 "stop": { "type": "stop", "stopwords": "_english_" // ビジネス要件に基づいてストップワードを定義します。 } } } }
フィルタータイプ名を確認する:
tokenizer
やchar_filter
などの設定で有効なフィルタータイプ名が指定されているかどうかを確認します。ビジネス要件に基づいて設定を変更し、
char_filter
、tokenizer
、filter
の設定で有効なコンポーネントタイプが指定されていることを確認できます。