検索シナリオでは、ユーザーは「携帯電話」と「スマートフォン」のように、同じ概念を異なる単語で表現することがよくあります。これにより、検索結果が不完全になる可能性があります。シノニム機能は、これらのタームを等価として扱うことでこの問題に対処し、検索範囲を拡大して再現率を向上させ、ユーザーエクスペリエンスを強化します。
事前準備
シノニムファイルを変更する前に、以下を確認してください。
単一ノードの再起動中にサービスの可用性を維持するために、重要なインデックスに少なくとも 1 つのレプリカシャードがあることを確認してください (辞書を削除すると、クラスターの再起動がトリガーされます)。
クラスターを監視し、その負荷が健全なレベルにあることを確認してください (推奨：CPU 使用率 < 60%、ヒープメモリ使用率 < 50%)。
クラスターに接続し、
GET /_nodes/stats/jvm?filter_path=nodes.*.jvm.mem.heap_*を実行して、すべてのノードの CPU とヒープメモリ使用率を確認してください。
仕組みと意思決定
このガイドでは、シノニムを設定するための 2 つの方法とそれぞれのトレードオフを比較し、ニーズに最適なアプローチを選択するのに役立ちます。
シノニムの構文ルール
シノニムファイルは、UTF-8 でエンコードされた .txt ファイルである必要があります。ファイル内の各行は、次の 2 つの形式のいずれかでシノニムルールを定義します。
等価シノニム (Solr 形式)
カンマで区切られたタームは、完全に等価として扱われます。1 つのタームを検索すると、グループ内のいずれかのタームを含むドキュメントが一致します。# 例：「phone」、「smartphone」、「mobile phone」の検索では、同じ結果になります。 phone,smartphone,mobile phone ipod,i-pod,i pod指向性マッピング (WordNet 形式)
=>を使用して、一連のタームを単一の正規化タームにマッピングします。これは、非標準のタームを推奨されるタームにマッピングする正規化によく使用されます。# 例：「usa」と「us」を「United States」にマッピングします。 usa,us => United States
設定方法の比較
シノニムは、ファイルをアップロードするか、インデックス設定でインラインで定義することで設定できます。次の表は、これら 2 つの方法を比較したものです。
項目 | 方法1：ファイルのアップロード | 方法2：インラインでの定義 |
設定方法 | クラスターに .txt ファイルをアップロードし、 | シノニムルールをインデックス設定内の |
メリット |
|
|
デメリット | 既存のインデックスは新しい辞書を動的にロードできません。 |
|
ユースケース | 辞書が安定しており、変更頻度が低く、複数のインデックスで共有する必要がある場合に使用します。 | 高可用性が重要な場合、またはシノニムを頻繁かつ迅速に更新する必要がある場合に使用します。 |
操作手順
方法1：シノニムファイルのアップロード (再利用可能)
この方法は、変更頻度の低い辞書に最適です。
ステップ1：シノニムファイルのアップロード
この例では、begin, start というエントリを含む aliyun_synonyms.txt という名前のテストファイルを使用してフィルターでシノニムを設定する方法を示します。
Alibaba Cloud Elasticsearch コンソールにログインします。インスタンスが配置されているリージョンとリソースグループを選択し、対象のインスタンスの ID をクリックします。
左側メニューで、設定と管理 > ES クラスターの設定 を選択します。[基本設定] セクションで、[シノニム設定] を見つけ、アップロード をクリックします。
表示されたパネルで、設定 をクリックし、アップロード方法を選択します。
ファイルには .txt 拡張子が必要です。ファイル名には、大文字、小文字、数字、アンダースコア (_) を使用でき、長さは 30 文字以内にする必要があります。
[ファイルのアップロード]：ローカルマシンからシノニムの .txt ファイルを選択します。
[OSSファイルの追加]：バケット名とシノニムファイル名を入力し、[追加] をクリックします。
制限事項：OSS バケットは、Alibaba Cloud Elasticsearch インスタンスと同じリージョンにある必要があります。
Save をクリックし、操作を確認します。
ステップ2：インデックスを作成してファイルを参照
インスタンスがアクティブ状態に戻るのを待ちます。次に、クラスターに接続し、アップロードされたシノニムファイルを使用するインデックスを作成します。
PUT /aliyun-index-test
{
"settings": {
"index":{
"analysis": {
"analyzer": {
"by_smart": {
"type": "custom",
"tokenizer": "ik_smart",
"filter": ["by_tfr","by_sfr"],
"char_filter": ["by_cfr"]
},
"by_max_word": {
"type": "custom",
"tokenizer": "ik_max_word",
"filter": ["by_tfr","by_sfr"],
"char_filter": ["by_cfr"]
}
},
"filter": {
"by_tfr": {
"type": "stop",
"stopwords": [" "]
},
"by_sfr": {
"type": "synonym",
"synonyms_path": "analysis/aliyun_synonyms.txt"
}
},
"char_filter": {
"by_cfr": {
"type": "mapping",
"mappings": ["| => |"]
}
}
}
}
}
}インデックスを作成する構文は、クラスターのバージョンによって異なります。詳細については、「一般的なElasticsearchバージョンのインデックス操作例」をご参照ください。
ステップ3：titleフィールドの設定
Elasticsearch 7.0 より前のバージョン
PUT /aliyun-index-test/_mapping/doc { "properties": { "title": { "type": "text", "analyzer": "by_max_word", "search_analyzer": "by_smart" } } }Elasticsearch 7.0 以降
PUT /aliyun-index-test/_mapping/ { "properties": { "title": { "type": "text", "analyzer": "by_max_word", "search_analyzer": "by_smart" } } }
ステップ4：設定の確認
_analyze API を使用して、アナライザーがシノニムを正しくロードしたことを確認します。この例では、シノニムファイルに begin,start が含まれていることを前提としています。
GET /aliyun-index-test/_analyze
{
"analyzer": "by_smart",
"text":"begin"
}正常なレスポンスには、begin と start の両方のトークンが含まれます。
{
"tokens" : [
{
"token" : "begin",
"start_offset" : 0,
"end_offset" : 5,
"type" : "ENGLISH",
"position" : 0
},
{
"token" : "start",
"start_offset" : 0,
"end_offset" : 5,
"type" : "SYNONYM",
"position" : 0
}
]
}ステップ5：検索結果のテスト
同義のタームをそれぞれ含む 2 つのドキュメントをインデックス登録します。
PUT /aliyun-index-test/doc/1 { "title": "Shall I begin?" }PUT /aliyun-index-test/doc/2 { "title": "I start work at nine." }タームの 1 つ (例：
begin) を検索します。検索すると、beginとstartの両方を含むドキュメントが返されます。GET /aliyun-index-test/_search { "query" : { "match" : { "title" : "begin" }}, "highlight" : { "pre_tags" : ["<red>", "<blue>"], "post_tags" : ["</red>", "</blue>"], "fields" : { "title" : {} } } }レスポンス：
{ "took" : 70, "timed_out" : false, "_shards" : { "total" : 1, "successful" : 1, "skipped" : 0, "failed" : 0 }, "hits" : { "total" : { "value" : 2, "relation" : "eq" }, "max_score" : 0.28247005, "hits" : [ { "_index" : "aliyun-index-test", "_type" : "_doc", "_id" : "1", "_score" : 0.28247005, "_source" : { "title" : "Shall I begin?" }, "highlight" : { "title" : [ "Shall I <red>begin</red>?" ] } }, { "_index" : "aliyun-index-test", "_type" : "_doc", "_id" : "2", "_score" : 0.25069216, "_source" : { "title" : "I start work at nine." }, "highlight" : { "title" : [ "I <red>start</red> work at nine." ] } } ] } }
方法2：インラインでの設定 (再利用不可)
この方法では、シノニムルールをインデックス設定に直接記述し、頻繁な更新が必要な小規模な辞書に最適です。
ステップ1：インデックスを作成してシノニムを定義
クラスターに接続し、インデックス作成時にシノニムルールを synonyms 配列に直接定義します。
PUT /my_index
{
"settings": {
"analysis": {
"analyzer": {
"my_synonyms": {
"filter": [
"lowercase",
"my_synonym_filter"
],
"tokenizer": "ik_smart"
}
},
"filter": {
"my_synonym_filter": {
"synonyms": [
"begin,start"
],
"type": "synonym"
}
}
}
}
}このコマンドは、my_index という名前のインデックスを作成し、カスタムテキスト分析を設定します。仕組みは次のとおりです：
テキストが my_synonyms アナライザーで処理されると、まず ik_smart トークナイザーによってトークンに分割されます。次に、lowercase フィルターがこれらのトークンをすべて小文字に変換し、最後に my_synonym_filter がシノニムルールを適用して、begin や start などのトークンを等価として扱います。
ステップ2：titleフィールドの設定
Elasticsearch 7.0 より前のバージョン
PUT /my_index/_mapping/doc { "properties": { "title": { "type": "text", "analyzer": "my_synonyms" } } }Elasticsearch 7.0 以降
PUT /my_index/_mapping/ { "properties": { "title": { "type": "text", "analyzer": "my_synonyms" } } }
ステップ3：設定の確認
GET /my_index/_analyze
{
"analyzer":"my_synonyms",
"text":"Shall I begin?"
}レスポンス：
{
"tokens" : [
{
"token" : "shall",
"start_offset" : 0,
"end_offset" : 5,
"type" : "ENGLISH",
"position" : 0
},
{
"token" : "i",
"start_offset" : 6,
"end_offset" : 7,
"type" : "ENGLISH",
"position" : 1
},
{
"token" : "begin",
"start_offset" : 8,
"end_offset" : 13,
"type" : "ENGLISH",
"position" : 2
},
{
"token" : "start",
"start_offset" : 8,
"end_offset" : 13,
"type" : "SYNONYM",
"position" : 2
}
]
}シノニム操作の影響
異なるシノニム操作は、クラスターに異なる影響を与えます。これらの違いを理解することで、ビジネス要件に適した更新方法を選択するのに役立ちます。
操作 | クラスターの再起動をトリガー | 説明 |
増分更新 (同じ名前のファイルをアップロード) | いいえ | 既存のファイルと同じ名前のシノニムファイルをアップロードすると増分更新 (ホットアップデート) となり、クラスターの再起動はトリガーされません。 |
シノニム辞書のアップデート でのシノニム辞書の更新 (新しいファイル名またはファイルの削除) | はい | 新しいファイル名でシノニムファイルをアップロードするか、既存のファイルを削除して変更を保存すると、クラスターのローリング再起動がトリガーされます。 |
増分更新 (ホットアップデート)
既存のファイルと同じ名前のシノニムファイルをアップロードすると、システムは増分更新 (ホットアップデート) を実行します。これは、クラスターの再起動をトリガーしません。新しいファイルが元のファイルを上書きし、新しく作成するインデックスは自動的に更新された辞書を使用します。
増分更新後、既存のインデックスは新しい辞書を自動的にロードしません。変更を既存のインデックスに適用するには、インデックスを閉じてから再度開く (Close/Open API) か、インデックスの再構築を行う必要があります。
クラスターの再起動をトリガーするコンソール更新
以下の操作は、クラスターのローリング再起動をトリガーします。
新しい名前でシノニムファイルをアップロードし、変更を保存する操作。
既存のシノニムファイルを削除し、変更を保存する操作。
業務上クラスターの再起動を避ける必要がある場合は、elasticsearch-analysis-dynamic-synonym プラグインを使用して動的更新を実装することを推奨します。
ローリング再起動は、以下の影響を及ぼす可能性があります。
サービスのジッター：ノードが順次再起動されるローリング再起動中、レプリカシャードがある場合でも、クエリのレイテンシが一時的に増加することがあります。
サービス中断のリスク：クラスターの負荷が高い、またはインデックスにレプリカシャードがないなどの極端な状況下では、再起動によって一部のリクエストが失敗したり、短時間サービスが中断したりする可能性があります。
再起動時間：再起動と辞書の配布に必要な合計時間は、クラスターのサイズ、データ量、負荷によって異なります。このプロセスには数分以上かかることがあります。
変更中の読み書きの可用性
シノニム設定を送信すると、インスタンスのステータスは [適用中] に変わります。この期間中：
インスタンスの読み書き操作は影響を受けず、引き続き利用可能です。
シノニム拡張機能は一時的に利用できなくなり、新しいシノニムルールに依存する検索クエリは不完全な結果を返す可能性があります。
変更が有効になると、インスタンスのステータスはアクティブに戻り、新しく作成されたインデックスは自動的に更新されたシノニム辞書を使用します。
よくある質問
Yellow ステータスまたは変更が滞る問題のトラブルシューティング
シノニムを設定または更新した後に、クラスターのステータスが Yellow に変わったり、後続の変更がブロックされたりした場合は、以下の一般的な原因を確認してください。
不適切な形式のシノニムファイル：ファイルに大文字が含まれているため、解析中にアナライザーが失敗します。
OpenStorePluginエラー：シノニムファイル内の異常なコンテンツが OpenStorePlugin エラーをトリガーします。これにより、シャードが正しく割り当てられなくなり、クラスターのステータスが異常になり、後続の変更がブロックされます。
この問題を解決するには、次の手順を実行してください。
シノニムファイルの確認と修正：ファイル内のすべての単語が小文字であることを確認してください。修正後、ファイルを再度アップロードしてください。
小文字フィルターの追加：インデックス設定のアナライザーのフィルター設定で、
lowercaseフィルターを追加して、分析中にトークンが自動的に小文字に変換されるようにしてください。設定例："filter": { "my_synonym_filter": { "type": "synonym", "synonyms_path": "analysis/your-dict-name.txt" } }, "analyzer": { "my_synonyms": { "filter": ["lowercase", "my_synonym_filter"], "tokenizer": "ik_smart" } }動作しないインデックスの回復：アナライザーフィルターの変更に本番環境でインデックスを閉じるか再構築する必要がある場合、または本番環境でアナライザーの変更が不可能な場合は、シャードの再割り当てを強制的に実行してクラスターのステータスを復元してみてください。
POST /_cluster/reroute?retry_failed=true
analysis-dynamic-synonym プラグインのリスク
オープンソースの analysis-dynamic-synonym プラグインを使用すると、リモートまたはローカルファイルからシノニムを動的にロードでき、クラスターを再起動せずに新しいシノニムルールを適用できます。ただし、このプラグインには以下の既知のリスクがあります。
同時実行性の不具合：同時実行性の高い読み書きシナリオでは、このプラグインが Elasticsearch プロセスでデッドロックを引き起こし、CPU 使用率が 100% になり、サービスが利用できなくなる可能性があります。
ユースケースの制限：Serverless インスタンスや厳格な安定性要件を持つ本番環境では、このプラグインを注意して使用してください。有効にする前に、テスト環境で実際のクエリと書き込み負荷のもとでその安定性を十分に評価することを推奨します。シノニムが頻繁に更新されない場合は、サードパーティプラグインの潜在的なリスクを避けるために、増分更新方法 (同じ名前のファイルをアップロード) を使用することを推奨します。