基本 - Elasticsearch Labs

Azure AKS Automatic に Elasticsearch をデプロイする方法

Eduard Martin — Fri, 14 Nov 2025 00:00:00 GMT

この記事は、さまざまなインフラストラクチャを使用して Elasticsearch をインストールする方法を説明するシリーズの一部です。

ECK はマーケットプレイスベースの Elastic Cloud ソリューションよりも大幅に多くの労力を必要としますが、Kubernetes オペレーターがシステムオーケストレーションとノードのスケーリングを処理するため、VM を自分でデプロイするよりも自動化されています。

今回は、Automatic を使用して Azure Kubernetes Service (AKS) を操作します。他の記事では、 Azure VMとAzure Marketplace の使用方法について学習します。

AKS Automatic とは何ですか?

Azure Kubernetes Service (AKS) は、クラスターのセットアップを自動的に管理し、リソースを動的に割り当て、Kubernetes の柔軟性を維持しながらセキュリティのベストプラクティスを統合するため、開発者はコンテナーイメージからデプロイされたアプリケーションまでを数分以内に実行できます。

AKS Automatic は、クラスター管理のオーバーヘッドの大部分を排除し、シンプルさと柔軟性のバランスを適切にとります。適切な選択はユースケースによって異なりますが、次のことを計画すると決定が容易になります。

テスト環境をデプロイする:デプロイは高速かつ簡単なので、簡単な実験や短期間のクラスターに最適です。
厳密な VM、ストレージ、またはネットワーク要件なしで作業: AKS Automatic では定義済みのデフォルトが提供されるため、それがニーズに合えば、追加の構成を行う必要がなくなります。
Kubernetes を初めて使用する場合: AKS Automatic はクラスターのセットアップの大部分を処理するため、学習曲線が短縮され、チームはアプリケーションに集中できるようになります。

Elasticsearch では、Elastic Stack の Kubernetes デプロイメントオーケストレーションを簡素化する公式 Elastic Kubernetes オペレーターであるElastic Cloud on Kubernetes (ECK) を使用します。

AKS Automaticの設定方法

1. Microsoft Azure ポータルにログインします。

2.右上のCloud Shellボタンをクリックし、コンソールにアクセスしてそこから AKS クラスターをデプロイします。あるいは、 Azure Cloud Shell を使用することもできます。

チュートリアル中にプロジェクト ID を自分のものに更新することを忘れないでください。

AKS を開くと、上のスクリーンショットのようになります。

3. aks-preview Azure CLI 拡張機能をインストールします。このプレビューバージョンでは、クラスターの作成時に--sku automaticを選択できるようになり、AKS Automatic 機能が有効になります。

az extension add --name aks-preview

このメッセージが表示された場合、AKS 拡張機能が正しくインストールされたことを意味します。

4. az feature registerコマンドを使用して機能フラグを登録する

az feature register --namespace Microsoft.ContainerService --name AutomaticSKUPreview

作成した機能サブスクリプションの詳細が表示されます。

登録ステータスが「登録中」から「登録済み」に変わるまで確認します。登録が完了するまでに数分かかる場合があります。

az feature show --namespace Microsoft.ContainerService --name AutomaticSKUPreview

変更を伝播するにはaz provider registerを実行します。

az provider register --namespace Microsoft.ContainerService

5. リソースグループを作成する

リソースグループは、管理およびデプロイされる Azure リソースの論理グループです。

az group create --name elastic-resource --location eastus

6. Autopilot クラスターを作成します。これをmyAKSAutomaticCluster に名前を付け、先ほど作成したリソースグループを使用します。AKS がリソースを割り当てるには、 Standard_D4pds_v5 、 Standard_D4lds_v5 、 Standard_D4ads_v5 、 Standard_D4ds_v5 、 Standard_D4d_v5 、 Standard_D4d_v4 、 Standard_DS3_v2 、 Standard_DS12_v2 のいずれかの VM サイズで 16 個の vCPU が使用可能であることを確認してください。

az aks create \ --resource-group elastic-resource \ --name myAKSAutomaticCluster \ --sku automatic \ --generate-ssh-keys

* MissingSubscriptionRegistrationエラーが発生した場合は、不足しているサブスクリプションを使用して手順4に戻ってください。たとえば、 The subscription is not registered to use namespace ' microsoft.insights '実行中のサブスクリプションが必要です。az provider register --namespace Microsoft.Insights.

対話型ログインに従ってください:

「az login」の実行を求めるメッセージが表示されます。そのコマンドを実行してから待つ必要があります。

7. 準備ができるまで待ちます。作成には約10分かかります。

8. kubectl コマンドラインアクセスを構成します。

az aks get-credentials --resource-group elastic-resource --name myAKSAutomaticCluster

インストールした拡張機能によって AKS Automatic が有効になっていることに注意してください。

9. ノードがデプロイされたことを確認します。

kubectl get nodes

禁止エラーメッセージが表示されます。エラーからユーザー ID をコピーします。

10. ユーザーを AKS アクセス制御に追加します。

AKS ID を取得します。コマンドからの出力をコピーします。

az aks show --resource-group elastic-resource --name myAKSAutomaticCluster --query id --output tsv

AKS ID とユーザーのプリンシパル ID を使用してロールの割り当てを作成します。

az role assignment create --role "Azure Kubernetes Service RBAC Cluster Admin" --assignee --scope

11. ノードが再度デプロイされたことを確認します。

kubectl get nodes

12. Kubernetes (ECK) オペレーターに Elastic Cloud をインストールします。

# Install ECK Custom Resource Definitions kubectl create -f https://download.elastic.co/downloads/eck/2.16.1/crds.yaml # Install the ECK operator kubectl apply -f https://download.elastic.co/downloads/eck/2.16.1/operator.yaml

13. デフォルト値を使用して、単一ノードの Elasticsearch インスタンスを作成しましょう。

cat <デフォルトの AKS マシンのvm.max_map_count値が低すぎるため、 nmapを無効にしました。本番環境では無効にすることは推奨されませんが、 vm.max_map_countの値を増やすことは推奨されます。これを行う方法の詳細については、ここを参照してください。

14. Kibana シングルノードクラスターもデプロイしましょう。Kibana の場合は、ロードバランサーを追加します。これにより、デバイスから Kibana にアクセスするために使用できる外部 IP が提供されます。

cat <デフォルトでは、AKS Automatic はロードバランサーをパブリックとして構成します。メタデータアノテーションを設定することで動作を変更できます。

service.beta.kubernetes.io/azure-load-balancer-internal: "true"

15. ポッドが実行中であることを確認します。

kubectl get pods

16.Elasticsearch のバージョン、ノード、健全性などのより具体的な統計情報を取得するには、 kubectl get elasticsearchとkubectl get kibanaを実行することもできます。

17. サービスにアクセスします。

kubectl get svc

これにより、EXTERNAL-IP の下に Kibana の外部 URLが表示されます。ロードバランサーのプロビジョニングには数分かかる場合があります。EXTERNAL-IP の値をコピーします。

18. 'elastic' ユーザーの Elasticsearch パスワードを取得します。

kubectl get secret quickstart-es-elastic-user -o=jsonpath='{.data.elastic}' | base64 --decode

19. ブラウザからKibana にアクセスします。

a. URL: https://:5601

b. ユーザー名:elastic

c. パスワード:c44A295CaEt44D6xIzN6Zs5m (前の手順から)

20.ブラウザから Elastic Cloud にアクセスすると、ようこそ画面が表示されます。

ノードの変更やサイズ変更など、Elasticsearch クラスターの仕様を変更する場合は、新しい設定で YML マニフェストを再度適用できます。

cat <この例では、さらに 1 つのノードを追加し、RAM と CPU を変更します。ご覧のとおり、 kubectl get elasticsearchには 2 つのノードが表示されています。

Kibana にも同じことが当てはまります。

cat <コンテナのCPU/RAMとNode.jsのメモリ使用量（ max-old-space-size ）を調整できます。

既存のボリュームクレームを縮小することはできないことに留意してください。アップデートを適用した後、オペレーターは最小限の中断時間で変更を加えます。

不要なコストを避けるために、テストが完了したらクラスターを忘れずに削除してください。

az aks delete --name myAKSAutomaticCluster --resource-group elastic-resource

まとめ

Azure AKS Automatic を ECK と併用すると、Elasticsearch と Kibana をデプロイするためのバランスの取れたソリューションが提供されます。これにより、運用の複雑さが軽減され、スケーリングと更新が自動化され、Kubernetes の柔軟性が活用されます。このアプローチは、インフラストラクチャの詳細をすべて手動で管理することなく、信頼性が高く、繰り返し可能で、保守可能なデプロイメントプロセスを求めるチームに最適であり、テスト環境と本番環境の両方にとって実用的な選択肢となります。

今後の見通し

Kubernetes について詳しく知りたい場合は、次の公式ドキュメントをご覧ください。

Elasticsearch で構造化ドキュメントの再帰チャンクを構成する

Daniel Rubinstein — Tue, 11 Nov 2025 00:00:00 GMT

8.16 以降、ユーザーは長いドキュメントをセマンティックテキストフィールドに取り込むときに使用するチャンキング戦略を構成できるようになりました。9.1 / 8.19 では、正規表現のリストを使用してドキュメントをチャンク化する、新しい構成可能な再帰チャンク化戦略を導入しました。チャンク化の目的は、長いドキュメントを関連するコンテンツをカプセル化するセクションに分割することです。既存の戦略では、テキストを単語/文の粒度で分割しますが、構造化された形式 (例:Markdown では、区切り文字列で定義されたセクション内に関連コンテンツが含まれることがよくあります (例:ヘッダー)。このような種類のドキュメントでは、構造化ドキュメントの形式を活用してより適切なチャンクを作成するための再帰チャンキング戦略を導入しています。

再帰チャンキングとは何ですか?

再帰チャンク化では、指定されたセクション分離パターンのリストを反復処理して、必要な最大チャンクサイズを満たすまで、ドキュメントを段階的に小さなセグメントに分割します。

再帰チャンクを構成するにはどうすればよいですか?

以下は、再帰チャンク化に対してユーザーが指定できる構成可能な値です。

(必須) max_chunk_size : チャンク内の最大単語数。
次のいずれか:
- separators: ドキュメントをチャンクに分割するために使用される正規表現文字列パターンのリスト。
- separator_group: 特定の種類のドキュメントに使用するために Elastic によって定義された区切り文字のデフォルトリストにマップされる文字列。現在、 markdownとplaintextが利用可能です。

再帰チャンキングはどのように機能しますか?

入力ドキュメント、 max_chunk_size (単語単位で測定)、および区切り文字列のリストが与えられた場合の再帰チャンク化のプロセスは次のとおりです。

入力ドキュメントがすでに最大チャンクサイズ内である場合は、入力全体にわたる単一のチャンクを返します。
区切り文字の出現に基づいてテキストを潜在的なチャンクに分割します。潜在的なチャンクごとに:
1. 潜在的なチャンクが最大チャンクサイズ内である場合は、ユーザーに返すチャンクのリストに追加します。
2. それ以外の場合は、潜在的なチャンクのテキストのみを使用して、リスト内の次のセパレーターを使用して分割し、手順 2 から繰り返します。試す区切り文字がもう残っていない場合は、文ベースのチャンクに戻ります。

再帰チャンクの設定例

チャンクサイズとは別に、再帰チャンク化の主な構成は、ドキュメントを分割するために使用するセパレーターを選択することです。どこから始めればよいかわからない場合は、Elasticsearch では一般的なユースケースに使用できるデフォルトのセパレーターグループがいくつか用意されています。

セパレーターグループの活用

セパレーターグループを利用するには、チャンク設定を構成するときに使用するグループの名前を指定するだけです。例えば：

"chunking_settings": { "strategy": "recursive", "max_chunk_size": 25, "separator_group": "plaintext" }

これにより、区切りリスト["(?を利用する再帰的なチャンク化戦略が提供されます。これは、2 つの改行文字とそれに続く 1 つの改行文字で分割する、一般的なプレーンテキストアプリケーションに適しています。

セパレーターリストを利用するセパレーターグループmarkdownも提供しています。

[
"\n# ",
       "\n## ",
       "\n### ",
       "\n#### ",
       "\n##### ",
       "\n###### ",
       "\n^(?!\\s*$).*\\n-{1,}\\n",
       "\n^(?!\\s*$).*\\n={1,}\\n"
]この区切りリストは、6 つの見出しレベルとセクション区切り文字のそれぞれに分割する一般的なマークダウンの使用例に適しています。
リソース (推論エンドポイント/セマンティック テキスト フィールド) を作成すると、その時点のセパレーター グループに対応するセパレーターのリストが構成に保存されます。セパレーター グループが後日更新されても、既に作成されたリソースの動作は変更されません。
カスタム区切りリストの利用
定義済みの区切り文字グループのいずれかが使用ケースに適していない場合は、ニーズに合った区切り文字のカスタム リストを定義できます。区切りリスト内に正規表現を指定できることに注意してください。以下は、カスタムセパレーターを使用して構成されたチャンク設定の例です。"chunking_settings": {
    "strategy": "recursive",
    "max_chunk_size": 25,
    "separators": ["\n\n", "\n", ""]
}上記のチャンク化戦略では、 2 つの改行文字、続いて 1 つの改行文字、最後に文字列“”で分割されます。
再帰チャンキングの実際の例
再帰チャンキングの実際の例を見てみましょう。この例では、上位 2 つのヘッダー レベルを使用してマークダウン ドキュメントを分割するセパレーターのカスタム リストとともに、次のチャンク設定を使用します。"chunking_settings": {
    "strategy": "recursive",
    "max_chunk_size": 25,
    "separators": ["\n# ", "\n## "]
}単純なチャンクなしの Markdown ドキュメントを見てみましょう。
ここで、上で定義したチャンク設定を使用してドキュメントをチャンク化してみましょう。
注: 各チャンク (チャンク 3 を除く) の末尾の改行は強調表示されませんが、実際のチャンク境界内に含まれます。
今すぐ再帰チャンキングを始めましょう!
この機能の利用方法の詳細については、チャンク設定の構成に関するドキュメントを参照してください。



Kibana に Elasticsearch クエリルール UI を導入
Jhon Guzmán — Fri, 07 Nov 2025 00:00:00 GMT
検索エンジンの役割は、関連性のある結果を返すことです。ただし、セールの強調、季節商品の優先、スポンサー商品の展示など、それ以上のビジネスニーズがあり、開発者は検索クエリでこれを常に実行できるとは限りません。
さらに、これらのユースケースは通常、時間に敏感であり、一般的な開発段階 (コード ブランチを作成してから新しいリリースを待つ) を実行するのは時間のかかるプロセスです。
では、このプロセス全体を API 呼び出しだけで、あるいは Kibana で数回クリックするだけで実行できたらどうなるでしょうか?
クエリルールUI
Elasticsearch 8.10 では、クエリ ルールとルール リトリーバーが導入されました。これらは、ルールに基づいてオーガニック検索結果のランキングに影響を与えずに、ピン留めされた結果をクエリに挿入するように設計されたツールです。宣言的かつシンプルな方法で、結果の上にビジネス ロジックを追加するだけです。
クエリ ルールの一般的な使用例は次のとおりです。
プロモーション対象商品やセール品の強調表示: セール中の商品やスポンサー商品を上部に表示します。
コンテキストまたは地理位置情報による除外: 地域の規制により表示が許可されていない場合は、特定のアイテムを非表示にします。
主要な結果を優先する: オーガニックランキングに関係なく、人気のある検索や固定検索が常に上位に表示されるようにします。
インターフェースにアクセスしてこれらのツールを操作するには、Kibana サイドメニューをクリックし、関連性の下にあるクエリルールに移動する必要があります。
クエリ ルール メニューが表示されたら、最初のルール セットの作成をクリックします。
次に、ルールセットに名前を付ける必要があります。
各ルールを定義するフォームには、次の 3 つの主要コンポーネントがあります。
基準: ルールを適用するために満たす必要がある条件。たとえば、「query_string フィールドに値Christmasが含まれている場合」や「country フィールドにCO の場合」などです。
アクション: これは、条件が満たされたときに発生する動作です。ピン留め（ドキュメントを上位の結果に固定する）したり、除外（ドキュメントを非表示にする）したりできます。
メタデータ: これらはクエリの実行時にクエリに付随するフィールドです。これらには、ユーザーの情報 (場所や言語など) や検索データ (query_string) を含めることができます。これらは、ルールを適用するかどうかを決定するための基準で使用される値です。
例: 人気商品
さまざまな商品を扱う電子商取引サイトがあると想像してみましょう。指標をチェックすると、コンソール カテゴリで最も売れているアイテムの 1 つが「DualShock 4 ワイヤレス コントローラー」であることがわかります。特に、ユーザーが「PS4」または「PlayStation 4」というキーワードを検索した場合に多く見られます。そこで、ユーザーがこれらのキーワードを検索するたびに、この製品を結果の最上位に表示することにしました。
まず、Bulk API リクエストを使用して各アイテムのドキュメントをインデックス化します。POST _bulk
{ "index": { "_index": "products", "_id": "1" } }
{ "id": "1", "name": "PlayStation 4 Slim 1TB", "category": "console", "brand": "Sony", "price": 1200 }
{ "index": { "_index": "products", "_id": "2" } }
{ "id": "2", "name": "DualShock 4 Wireless Controller", "category": "accessory", "brand": "Sony", "price": 250 }
{ "index": { "_index": "products", "_id": "3" } }
{ "id": "3", "name": "PlayStation 4 Camera", "category": "accessory", "brand": "Sony", "price": 200 }
{ "index": { "_index": "products", "_id": "4" } }
{ "id": "4", "name": "PlayStation 4 VR Headset", "category": "accessory", "brand": "Sony", "price": 900 }
{ "index": { "_index": "products", "_id": "5" } }
{ "id": "5", "name": "Charging Station for DualShock 4", "category": "accessory", "brand": "Sony", "price": 80 }クエリに介入しない場合、アイテムは通常 4 番目の場所に表示されます。クエリは次のとおりです。GET products/_search
{
 "query": {
   "match": {
     "name": "PlayStation 4"
   }
 }
}そして結果はこちらです{
 "took": 1,
 "timed_out": false,
 "_shards": {
   "total": 1,
   "successful": 1,
   "skipped": 0,
   "failed": 0
 },
 "hits": {
   "total": {
     "value": 5,
     "relation": "eq"
   },
   "max_score": 0.6973252,
   "hits": [
     {
       "_index": "products",
       "_id": "3",
       "_score": 0.6973252,
       "_source": {
         "id": "3",
         "name": "PlayStation 4 Camera",
         "category": "accessory",
         "brand": "Sony",
         "price": 200
       }
     },
     {
       "_index": "products",
       "_id": "1",
       "_score": 0.6260078,
       "_source": {
         "id": "1",
         "name": "PlayStation 4 Slim 1TB",
         "category": "console",
         "brand": "Sony",
         "price": 1200
       }
     },
     {
       "_index": "products",
       "_id": "4",
       "_score": 0.6260078,
       "_source": {
         "id": "4",
         "name": "PlayStation 4 VR Headset",
         "category": "accessory",
         "brand": "Sony",
         "price": 900
       }
     },
     {
       "_index": "products",
       "_id": "2",
       "_score": 0.08701137,
       "_source": {
         "id": "2",
         "name": "DualShock 4 Wireless Controller",
         "category": "accessory",
         "brand": "Sony",
         "price": 250
       }
     },
     {
       "_index": "products",
       "_id": "5",
       "_score": 0.07893815,
       "_source": {
         "id": "5",
         "name": "Charging Station for DualShock 4",
         "category": "accessory",
         "brand": "Sony",
         "price": 80
       }
     }
   ]
 }
}これを変更するためのクエリ ルールを作成しましょう。まず、次のようにルールセットに追加しましょう。
または同等のAPI リクエスト:PUT _query_rules/my-rules
{
  "rules": [
    {
      "rule_id": "rule-1232",
      "type": "pinned",
      "criteria": [
        {
          "type": "exact",
          "metadata": "query_string",
          "values": [
            "PS4",
            "PlayStation 4"
          ]
        }
      ],
      "actions": {
        "docs": [
          {
            "_index": "products",
            "_id": "2"
          }
        ]
      }
    }
  ]
}クエリでルールセットを使用するには、クエリ ルール タイプを使用する必要があります。この種のクエリは、主に次の 2 つの部分で構成されます。GET /products/_search
{
 "retriever": {
   "rule": {
     "retriever": {
       "standard": {
         "query": {
           "match": { "name": "PlayStation 4" }
         }
       }
     },
     "match_criteria": {
       "query_string": "PlayStation 4"
     },
     "ruleset_ids": ["my-rules"]
   }
 }
}match_criteria : ユーザーのクエリと比較するために使用されるメタデータです。この例では、query_string フィールドの値が「PlayStation 4」の場合にルールセットがアクティブになります。
query : 検索してオーガニック検索結果を取得するために使用される実際のクエリ。
この方法では、最初にオーガニッククエリを実行し、次に Elasticsearch がルールセットのルールを適用します。{
 "took": 17,
 "timed_out": false,
 "_shards": {
   "total": 1,
   "successful": 1,
   "skipped": 0,
   "failed": 0
 },
 "hits": {
   "total": {
     "value": 5,
     "relation": "eq"
   },
   "max_score": 1.7014122e+38,
   "hits": [
     {
       "_index": "products",
       "_id": "2",
       "_score": 1.7014122e+38,
       "_source": {
         "id": "2",
         "name": "DualShock 4 Wireless Controller",
         "category": "accessory",
         "brand": "Sony",
         "price": 250
       }
     },
     {
       "_index": "products",
       "_id": "3",
       "_score": 0.6973252,
       "_source": {
         "id": "3",
         "name": "PlayStation 4 Camera",
         "category": "accessory",
         "brand": "Sony",
         "price": 200
       }
     },
     {
       "_index": "products",
       "_id": "1",
       "_score": 0.6260078,
       "_source": {
         "id": "1",
         "name": "PlayStation 4 Slim 1TB",
         "category": "console",
         "brand": "Sony",
         "price": 1200
       }
     },
     {
       "_index": "products",
       "_id": "4",
       "_score": 0.6260078,
       "_source": {
         "id": "4",
         "name": "PlayStation 4 VR Headset",
         "category": "accessory",
         "brand": "Sony",
         "price": 900
       }
     },
     {
       "_index": "products",
       "_id": "5",
       "_score": 0.07893815,
       "_source": {
         "id": "5",
         "name": "Charging Station for DualShock 4",
         "category": "accessory",
         "brand": "Sony",
         "price": 80
       }
     }
   ]
 }
}例: ユーザーベースのメタデータ
クエリ ルールのもう 1 つの興味深い応用は、メタデータを使用して、ユーザーまたは Web ページからのコンテキスト情報に基づいて特定のドキュメントを表示することです。
たとえば、数値として表されるユーザーのロイヤルティ レベルに基づいて、アイテムやカスタマイズされたセールを強調表示したいとします。
これを実現するには、このメタデータをクエリに直接取り込んで、その値が特定の基準を満たしたときにルールがアクティブになるようにします。
まず、ロイヤルティ レベルの高いユーザーだけが閲覧できるドキュメントをインデックスします。POST _bulk
{ "index": { "_index": "products", "_id": "6" } }
{ "id": "6", "name": "PlayStation Plus Deluxe Card - 12 months", "category": "membership", "brand": "Sony", "price": 300 }ここで、同じルールセット内に新しいルールを作成し、loyalty_level が 80 以上の場合にアイテムが結果の上部に表示されるようにします。
ルールとルールセットを保存します。
同等の REST リクエストは次のとおりです。PUT _query_rules/my-rules
{
  "rules": [
    {
      "rule_id": "pin-premiun-user",
      "type": "pinned",
      "criteria": [
        {
          "type": "gte",
          "metadata": "loyalty_level",
          "values": [
            80
          ]
        }
      ],
      "actions": {
        "docs": [
          {
            "_index": "products",
            "_id": "6"
          }
        ]
      }
    }
  ]
}ここで、クエリを実行するときに、メタデータに新しいパラメータroyality_levelを含める必要があります。ルールの条件が満たされると、新しいドキュメントが結果の上部に表示されます。
たとえば、loyalty_level が 80 のクエリを送信する場合:POST /products/_search
{
  "retriever": {
    "rule": {
      "retriever": {
        "standard": {
          "query": {
            "match": {
              "name": "PlayStation"
            }
          }
        }
      },
      "match_criteria": {
        "query_string": "PlayStation",
        "loyalty_level": 80
      },
      "ruleset_ids": ["my-rules"]
    }
  }
}結果の上部にロイヤルティ ドキュメントが表示されます。{
  "took": 31,
  "timed_out": false,
  "_shards": {
    "total": 1,
    "successful": 1,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": {
      "value": 4,
      "relation": "eq"
    },
    "max_score": 1.7014122e+38,
    "hits": [
      {
        "_index": "products",
        "_id": "6",
        "_score": 1.7014122e+38,
        "_source": {
          "id": "6",
          "name": "PlayStation Plus Deluxe Card - 12 months",
          "category": "membership",
          "brand": "Sony",
          "price": 300
        }
      },
      {
        "_index": "products",
        "_id": "3",
        "_score": 0.5054567,
        "_source": {
          "id": "3",
          "name": "PlayStation 4 Camera",
          "category": "accessory",
          "brand": "Sony",
          "price": 200
        }
      },
      {
        "_index": "products",
        "_id": "1",
        "_score": 0.45618832,
        "_source": {
          "id": "1",
          "name": "PlayStation 4 Slim 1TB",
          "category": "console",
          "brand": "Sony",
          "price": 1200
        }
      },
      {
        "_index": "products",
        "_id": "4",
        "_score": 0.45618832,
        "_source": {
          "id": "4",
          "name": "PlayStation 4 VR Headset",
          "category": "accessory",
          "brand": "Sony",
          "price": 900
        }
      }
    ]
  }
}以下の場合、ロイヤルティ レベルが 70 であるため、ルールは満たされず、アイテムは上部に表示されません。POST /products/_search
{
  "retriever": {
    "rule": {
      "retriever": {
        "standard": {
          "query": {
            "match": {
              "name": "PlayStation"
            }
          }
        }
      },
      "match_criteria": {
        "query_string": "PlayStation",
        "loyalty_level": 70
      },
      "ruleset_ids": ["my-rules"]
    }
  }
}結果は次のとおりです。{
  "took": 7,
  "timed_out": false,
  "_shards": {
    "total": 1,
    "successful": 1,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": {
      "value": 4,
      "relation": "eq"
    },
    "max_score": 0.5054567,
    "hits": [
      {
        "_index": "products",
        "_id": "3",
        "_score": 0.5054567,
        "_source": {
          "id": "3",
          "name": "PlayStation 4 Camera",
          "category": "accessory",
          "brand": "Sony",
          "price": 200
        }
      },
      {
        "_index": "products",
        "_id": "1",
        "_score": 0.45618832,
        "_source": {
          "id": "1",
          "name": "PlayStation 4 Slim 1TB",
          "category": "console",
          "brand": "Sony",
          "price": 1200
        }
      },
      {
        "_index": "products",
        "_id": "4",
        "_score": 0.45618832,
        "_source": {
          "id": "4",
          "name": "PlayStation 4 VR Headset",
          "category": "accessory",
          "brand": "Sony",
          "price": 900
        }
      },
      {
        "_index": "products",
        "_id": "6",
        "_score": 0.3817649,
        "_source": {
          "id": "6",
          "name": "PlayStation Plus Deluxe Card - 12 months",
          "category": "membership",
          "brand": "Sony",
          "price": 300
        }
      }
    ]
  }
}例: 即時除外
DualShock 4 ワイヤレス コントローラー (ID 2)が一時的に入手できず、販売できないとします。そのため、ビジネス チームは、ドキュメントを手動で削除したり、何らかのデータ処理が開始されるのを待ったりする代わりに、当面は検索結果からドキュメントを削除することにしました。
先ほど人気アイテムに適用したのと同様のプロセスを使用しますが、今回は[Pinned]ではなく[Exclude]を選択します。このルールは一種のブラックリストとして機能します。クエリが実行されるたびに除外が機能するように、条件を「常時」に変更します。
ルールは次のようになります。
変更を適用するには、ルールとルールセットを保存します。同等の REST リクエストは次のとおりです。PUT _query_rules/my-rules
{
  "rules": [
    {
      "rule_id": "rule-6358",
      "type": "pinned",
      "criteria": [
        {
          "type": "always"
        }
      ],
      "actions": {
        "docs": [
          {
            "_index": "products",
            "_id": "2"
          }
        ]
      }
    }
  ]
}ここで、クエリを再度実行すると、以前のルールではアイテムをピン留めするはずだったにもかかわらず、アイテムが結果に表示されなくなっていることがわかります。これは、除外がピン留め結果よりも優先されるためです。{
 "took": 6,
 "timed_out": false,
 "_shards": {
   "total": 1,
   "successful": 1,
   "skipped": 0,
   "failed": 0
 },
 "hits": {
   "total": {
     "value": 4,
     "relation": "eq"
   },
   "max_score": 2.205655,
   "hits": [
     {
       "_index": "products",
       "_id": "3",
       "_score": 2.205655,
       "_source": {
         "id": "3",
         "name": "PlayStation 4 Camera",
         "category": "accessory",
         "brand": "Sony",
         "price": 200
       }
     },
     {
       "_index": "products",
       "_id": "1",
       "_score": 1.9738505,
       "_source": {
         "id": "1",
         "name": "PlayStation 4 Slim 1TB",
         "category": "console",
         "brand": "Sony",
         "price": 1200
       }
     },
     {
       "_index": "products",
       "_id": "4",
       "_score": 1.9738505,
       "_source": {
         "id": "4",
         "name": "PlayStation 4 VR Headset",
         "category": "accessory",
         "brand": "Sony",
         "price": 900
       }
     },
     {
       "_index": "products",
       "_id": "5",
       "_score": 0.69247496,
       "_source": {
         "id": "5",
         "name": "Charging Station for DualShock 4",
         "category": "accessory",
         "brand": "Sony",
         "price": 80
       }
     }
   ]
 }
}まとめ
クエリ ルールを使用すると、コードを変更することなく関連性を簡単に調整できます。新しいKibana UIでは、これらの変更を数秒で行うことができるため、お客様とビジネス チームは検索結果をより細かく制御できるようになります。
クエリ ルールは、電子商取引以外にも、サポート ポータルでトラブルシューティング ガイドを強調表示したり、ナレッジ ベースで重要な社内ドキュメントを表示したり、ニュース サイトで最新ニュースを宣伝したり、期限切れの求人やコンテンツの一覧を除外したりするなど、さまざまなシナリオで活用できます。ユーザーの役割や地域によって制限されたコンテンツを非表示にするなど、コンプライアンス ルールを適用することもできます。


AWS MarketplaceでElasticsearchをデプロイする方法
Eduard Martin — Fri, 03 Oct 2025 00:00:00 GMT
この記事では、Marketplaceの提供を利用してAWS上でElasticsearchをデプロイする方法を学びます。
Elastic Cloud Service on AWSを使用します。これは、AWSのネイティブインフラストラクチャーを介してすべてのElastic Stackコンポーネントの導入とオーケストレーションを簡素化するオフィシャルのマネージドElasticsearch Serviceです。
AWS EC2でのElasticsearchのインストールと設定方法を学びたい方は、このブログをご覧ください。
AWS Marketplaceとは？
Elastic on AWS Marketplaceは、完全マネージド型の検索・分析エクスペリエンスを提供します。インフラの提供、security、スケーリングは AWS が処理し、開発者は検索アプリケーションの構築に集中できます。これにより、チームは搭載のAWS統合を使用して、エンタープライズグレードのElasticsearchクラスターを数分でデプロイできるようになります。
Elastic on AWS Marketplaceを使用するのはどのような場合ですか？
Elastic on AWS Marketplaceは、既存のAWSインフラストラクチャを持ち、運用オーバーヘッドなしでマネージドサービス、組み込みセキュリティ、シームレスなAWS統合を備えたElasticsearchを導入したいと考えている組織に最適です。
AWSマーケットプレイスでElastic Cloudをセットアップする方法
ステップ1 : AWS Marketplaceにアクセスする
1。AWSにログインしてください。
検索バーでAWS Marketplaceを検索します。
2. 左側のナビゲーションパネルでDiscover productsをクリックし、「Elasticsearch」を検索します。
3. Elastic Cloud (Elasticsearch Service)をクリックします。
ステップ 2: サービスに登録する
1. 購入オプションを選択するか、無料で試すをクリックします。
2.価格の詳細、利用規約、購入の詳細を確認します。
3. 登録ボタンをクリックします。
4. 次に、Elasticアカウントをセットアップする必要があります。AWSの手順に従います。
a. 「統合を有効にする」ボタンをクリックします
b.「サインインまたはベンダーアカウントを作成」ボタンをクリックします。
c. 「テンプレートを起動」ボタンをクリックします。
d. 「ソフトウェアを起動」ボタンをクリックします。
ステップ3. Elasticで新しいアカウントを設定する
1. Elasticアカウントを作成してください。
2. メールアドレスを確認する
3.お名前と会社情報をインプットしてください。
4. Elasticの簡単なアンケートに回答する
5. Elastic Cloudをマネージド環境でホストする地域を選択する（デフォルトで実際のAWSリージョンが選択されます）
6. Elasticがデプロイされるのを待つ
7. 導入がAWS Marketplaceサブスクリプションに接続される
サブスクリプションをキャンセルする
サブスクリプションをキャンセルするには以下の手順に従います。
1. AWSコンソールに移動します。
検索バーで「AWS Marketplace」と検索してください。AWS Marketplaceをクリックします。
2．Elastic Cloudサブスクリプションをクリックします。
3. アクションボタンをクリックし、次にサブスクリプションをキャンセルをクリックします。
4．キャンセルを確認し、はいをクリックして、サブスクリプションをキャンセルボタンをクリックします。
5. 確認メッセージがページ上部に表示されます。
次のステップ
単一の導入と3つのプロジェクトが含まれ 7日間のElastic Cloud (Elasticsearch Service) 無料トライアルでElastic Cloudの旅を始めましょう。AWSアカウントにサインインし、「購入オプションを表示」をクリックして、Elastic Cloud (Elasticsearch Service)でElasticのSearch AI Platformをすぐに使い始められます。このトライアルでは、インフラストラクチャ管理のオーバーヘッドなしで、検索、セキュリティ、および監視ソリューションに完全にアクセスできます。


Elasticsearch のシャードとレプリカ: 実践ガイド
Piotr Przybyl — Thu, 14 Aug 2025 00:00:00 GMT
Elasticsearch は、スケーラビリティとフォールト トレランスの問題に対処する分散システムを Lucene 上に構築することで、Lucene のパワーを強化します。また、JSON ベースの REST API も公開されているため、他のシステムとの相互運用性が非常に簡単になります。
Elasticsearch のような分散システムは非常に複雑になる可能性があり、パフォーマンスと安定性に影響を与える要因が多数あります。シャードはElasticsearch の最も基本的な概念の 1 つであり、その仕組みを理解することで Elasticsearch クラスターを効果的に管理できるようになります。
この記事では、プライマリ シャードとレプリカ シャードとは何か、それらが Elasticsearch クラスターに与える影響、さまざまな需要に合わせてそれらを調整するためのツールについて説明します。
破片を理解する
Elasticsearch インデックス内のデータは膨大な量にまで増大する可能性があります。管理しやすいように、すべてのデータはインデックスに保存され、インデックスはいくつかのシャードに分割されます。各 Elasticsearch シャードは Apache Lucene インデックスであり、個々の Lucene インデックスには Elasticsearch インデックス内のドキュメントのサブセットが含まれています。このようにインデックスを分割すると、リソースの使用量を制御できます。Apache Lucene インデックスには、2,147,483,519 (2³¹ - 129) ドキュメントの制限があります。
場合によっては、再バランス調整のためにインデックスをノード間で移動する必要があります。このプロセスは時間とリソースの両方を大量に消費する可能性があるため、インデックスが大きくなりすぎないようにする必要があります。これにより、回復時間を管理しやすい状態に保つことができます。さらに、インデックスは常に結合する必要がある Lucene セグメントで構成されているため、セグメントが大きくなりすぎないことが重要です。これらの理由から、Elasticsearch はインデックス データをプライマリ シャードと呼ばれるより小さく管理しやすいチャンクに分割し、複数のマシン間でより簡単に分散できるようにします。レプリカシャードは、対応するプライマリ シャードの正確なコピーであり、その機能についてはこの記事の後半で説明します。
適切な数のシャードを持つことはパフォーマンスにとって重要です。したがって、事前に計画を立てるのが賢明です。クエリが異なるシャード間で並列に実行されると、各シャードが異なるノードに配置され、クラスター内に十分なノードがある場合に限り、単一のシャードで構成されたインデックスよりも高速に実行されます。ただし同時に、シャードはインデックス化されたデータとクラスター メタデータの両方に関して、メモリとディスク領域を消費します。シャードが多すぎると（オーバーシャーディングとも呼ばれます）、クエリ、インデックス要求、および管理操作が遅くなる可能性があるため、適切なバランスを維持することが重要です。
プライマリ シャードの数は、特定のインデックス インスタンスのインデックス作成時に定義されます。後でプライマリ シャードの数を変更する必要がある場合は、サイズ変更 API を使用できます (分割(プライマリ シャードを増やす)、縮小(プライマリ シャードを減らす)、または複製(レプリカの新しい設定でプライマリ シャードの数は同じ))。これらの操作は、Lucene セグメントをコピーし、すべてのドキュメントの完全な再インデックスを回避します。インデックスを作成するときに、インデックスの設定としてプライマリ シャードとレプリカ シャードの数を設定できます。PUT /sensor
{
   "settings" : {
       "index" : {
           "number_of_shards" : 6,
           "number_of_replicas" : 2
       }
   }
}(シャードまたはレプリカの数を指定しない場合、Elasticsearch 7.0 以降、両方のデフォルト値は 1 になります)。理想的なシャードの数は、インデックス内のデータ量に基づいて決定する必要があります。一般的に、最適なシャードは 10 ～ 50 GB のデータを保持し、シャードあたりのドキュメント数は 2 億未満である必要があります。たとえば、1 日に約 300 GB のアプリケーション ログが蓄積されると予想される場合、それらをホストするのに十分な数のノードがあれば、そのインデックスに約 10 個のシャードを持つことが妥当です。
シャードは、その存続期間中に、次のようなさまざまな状態を経る可能性があります。
初期化中:シャードが使用される前の初期状態。
開始済み:シャードがアクティブでリクエストを受信できる状態。
再配置中:シャードが別のノードに移動されている途中に発生する状態。これは、たとえば、ノードのディスク容量が不足している場合など、特定の状況下では必要になることがあります。
未割り当て:割り当てに失敗したシャードの状態。これが発生すると理由が提供されます。たとえば、シャードをホストしているノードがクラスター内になくなった場合(NODE_LEFT) 、または閉じたインデックスに復元された場合(EXISTING_INDEX_RESTORED) などです。
すべてのシャード、その状態、およびその他のメタデータを表示するには、次のリクエストを使用できます。
GET _cat/shards特定のインデックスのシャードを表示するには、URL にインデックスの名前を追加します (例: sensor)。
GET _cat/shards/sensorこのコマンドは、次の例のような出力を生成します。デフォルトでは、表示される列にはインデックスの名前、名前（つまりシャードの数、プライマリ シャードかレプリカか、シャードの状態、ドキュメント数、ディスク上のサイズ、シャードが配置されているノードの IP アドレスとノード ID が表示されます。sensor 5 p STARTED    0  283b 127.0.0.1 ziap
sensor 5 r UNASSIGNED                  
sensor 2 p STARTED    1 3.7kb 127.0.0.1 ziap
sensor 2 r UNASSIGNED                  
sensor 3 p STARTED    3 7.2kb 127.0.0.1 ziap
sensor 3 r UNASSIGNED                  
sensor 1 p STARTED    1 3.7kb 127.0.0.1 ziap
sensor 1 r UNASSIGNED                  
sensor 4 p STARTED    2 3.8kb 127.0.0.1 ziap
sensor 4 r UNASSIGNED                  
sensor 0 p STARTED    0  283b 127.0.0.1 ziap
sensor 0 r UNASSIGNEDレプリカを理解する
各シャードにはデータのコピーが 1 つ含まれますが、インデックスにはシャードの複数のコピーが含まれる場合があります。したがって、シャードには、プライマリ シャードとコピー、またはレプリカの 2 種類があります。プライマリ シャードの各レプリカは常に異なるノードに配置されるため、ノード障害が発生した場合でもデータの高可用性が確保されます。冗長性とデータ損失やダウンタイムの防止の役割に加えて、レプリカはクエリをプライマリ シャードと並行して処理できるため、検索パフォーマンスが向上し、処理速度が向上します。
プライマリ シャードとレプリカ シャードの動作にはいくつかの重要な違いがあります。どちらもクエリを処理できますが、インデックスリクエスト（つまりインデックスにデータを追加するなどの処理は、レプリカ シャードに複製される前に、まずプライマリ シャードを通過する必要があります。前述のように、プライマリ シャードが使用できなくなった場合 (たとえば、ノードの切断やハードウェア障害などにより)、レプリカが昇格してその役割を引き継ぎます。
レプリカはノード障害の際に役立ちますが、インデックス作成時にメモリ、ディスク容量、計算能力を消費するため、レプリカを多くしすぎないことが重要です。プライマリ シャードとレプリカのもう 1 つの違いは、インデックスの作成後はプライマリ シャードの数を変更できないのに対し、レプリカの数はインデックス設定を更新することでいつでも動的に変更できることです。
レプリカに関して考慮すべきもう 1 つの要素は、利用可能なノードの数です。同じノードに同じデータのコピーが 2 つあると、ノードに障害が発生した場合に保護が提供されないため、レプリカは常にプライマリ シャードとは異なるノードに配置されます。その結果、システムがn 個のレプリカをサポートするには、クラスター内に少なくともn + 1 個のノードが必要になります。たとえば、クラスター内に 2 つのノードがあり、インデックスが 6 つのレプリカで構成されている場合、割り当てられるレプリカは 1 つだけです。一方、7 つのノードを持つシステムは、1 つのプライマリ シャードと 6 つのレプリカを完全に処理できます。
シャードとレプリカの最適化
プライマリ シャードとレプリカ シャードの適切なバランスを持つインデックスが作成された後でも、インデックスの周囲のダイナミクスは時間の経過とともに変化するため、これらを監視する必要があります。たとえば、時系列データを扱う場合、最近のデータを持つインデックスは、一般的に古いデータを持つインデックスよりもアクティブになります。これらのインデックスを調整しないと、要件が大きく異なるにもかかわらず、すべて同じ量のリソースを消費することになります。
ロールオーバー インデックス API を使用すると、新しいインデックスと古いインデックスを分離できます。特定のしきい値（ディスク上のインデックスのサイズ、ドキュメントの数、または年齢）に達すると、新しいインデックスを自動的に作成するように設定できます。この API は、シャードのサイズを制御するのにも役立ちます。インデックス作成後はシャードの数を簡単に変更できないため、ロールオーバー条件が満たされない限り、シャードにはデータが蓄積され続けます。アクセス頻度が低い古いインデックスの場合、インデックスの縮小と強制マージは、メモリとディスクのフットプリントを削減する 2 つの異なる方法です。前者はインデックス内のシャードの数を減らし、後者は Lucene セグメントの数を減らし、削除されたドキュメントによって使用されていたスペースを解放します。
Elasticsearchの基盤となるプライマリシャードとレプリカシャード
Elasticsearch は、膨大な量のデータのための分散ストレージ、検索、分析プラットフォームとして高い評価を得ています。しかし、このような規模で事業を展開する場合、必然的に課題が生じます。そのため、プライマリ シャードとレプリカ シャードの仕組みを理解することは、Elasticsearch にとって非常に重要かつ基本的なことであり、プラットフォームの信頼性とパフォーマンスを最適化するのに役立ちます。
これらがどのように機能し、どのように最適化するかを知ることは、より堅牢でパフォーマンスの高い Elasticsearch クラスターを実現するために重要です。クエリ応答が遅くなったり、頻繁に停止したりする場合は、この知識がこれらの障害を克服する鍵となる可能性があります。
クラスター、ノード、シャード、シャードのサイズ設定方法、シャードの割り当てと回復の詳細については、Elasticsearch の公式ドキュメントを参照してください。
このトピックは、 Elastic コミュニティ YouTube チャンネルの入門コースとしてもご利用いただけます。
最後に、ノード、シャード、レプリカについて心配したくない場合は、 Elastic Cloud Serverless を試してみてください。この Elastic Cloud オファリングは Elastic によって完全に管理され、ワークロードに合わせて自動的に拡張されます。無料トライアルを利用すると、サーバーレス アプローチのその他の利点を理解するのに役立ちます。


ユニークなパターンを明らかにする: Elasticsearch における重要な用語の集約ガイド
Alexander Dávila — Mon, 07 Jul 2025 00:00:00 GMT
Elasticsearch では、重要な用語の集約により、最も一般的な用語を超えて、データセット内の統計的に異常な値を見つけます。これにより、貴重な洞察や明らかでないパターンを発見することができます。重要な用語の集約により、次の 2 つの便利なパラメータを含む応答が提供されます。
bg_count (背景カウント):親データセットで見つかったドキュメントの数
doc_count:結果データセットで見つかったドキュメントの数
たとえば、携帯電話の販売データセットでは、次のようにして iPhone 16 の販売に関する重要な用語を探すことができます。GET phone_sales_analysis/_search
{
 "size": 0,
 "query": {
   "term": {
     "phone_model": {
       "value": "iPhone 16"
     }
   }
 },
 "aggs": {
   "significant_cities": {
     "significant_terms": {
       "field": "city_region",
       "size": 1
     }
   }
 }
}すると、応答は次のようになります。{
 "aggregations": {
   "significant_cities": {
     "doc_count": 122,
     "bg_count": 424,
     "buckets": [
       {
         "key": "Houston",
         "doc_count": 12,
         "score": 0.1946481360617346,
         "bg_count": 14
       }

     ]
   }
 }
}ヒューストンは、データセット全体の都市のトップ 10 にも、iPhone 16 のトップ都市にも入っていません。しかし、重要な用語の集約により、この都市では他のデータと比較して iPhone 16 が不均衡に多く購入されていることが示されました。数字を詳しく見てみましょう:
最上位レベル:
doc_count: 122 —クエリは合計122の文書と一致しました
bg_count: 424 —背景セット（すべての販売文書）には424の文書が含まれています
ヒューストンのバケット:
doc_count: 12 —ヒューストンは122件の検索結果のうち12件に出現します
bg_count: 14 —ヒューストンは、背景データセット内の合計424の文書のうち14に登場します。
これは、合計 424 件の購入のうち、ヒューストンで発生したのは 14 件のみであり、これは全購入の 3.3% であることを示しています。しかし、iPhone 16の販売だけに注目すると、122件中12件がヒューストンで発生しており、これは9.8%で、データセット全体の3倍にあたります。これは大きな数字です。
これを視覚的に表すと次のようになります: city_region ごとの総売上高。
ヒューストンには 14 件の売上があり、データセット内で売上高が 14 番目に多い都市であることがわかります。
ここで、フィルターを適用して iPhone 16 の販売のみを調べると、ヒューストンでの販売数が 12 件となり、この特定のモデルの販売数が最も多い都市として 2 番目に多い都市になります。
重要な用語の理解
Elasticのドキュメントによると、重要な用語の集約は次のとおりです。
「前景セットと背景セット間で測定された人気度に大きな変化があった用語を検索します。」
つまり、統計メトリックを使用して、データのサブセット (フォアグラウンド セット) 内の用語の頻度を、データの親セット (バックグラウンド セット) 内の同じ用語の頻度と比較します。この方法では、スコアリングはデータ内での用語の出現頻度ではなく、統計的有意性を反映します。
重要な用語の集約と通常の用語の集約の主な違いは次のとおりです。
重要な用語はデータのサブセットを比較しますが、用語の集約はクエリの結果のデータセットに対してのみ機能します。
用語の集約から得られる結果はデータセット内で最も一般的な用語ですが、重要な用語から得られる結果はデータセットを一意にする要素を見つけるために一般的な用語を無視します。
用語の集約と同様に、メモリではなくディスクからデータを取得する必要があるため、重要な用語はパフォーマンスに大きな影響を与える可能性があります。
実践応用（消費者行動分析）
分析のためのデータの準備
この分析のために、価格、携帯電話の仕様、購入者の人口統計、フィードバックを含む合成携帯電話販売データセットを生成しました。また、後でセマンティッククエリを実行できるように、ユーザーのフィードバックから埋め込みを生成しました。Elasticsearch ですぐに使用できる多言語 e5 小型モデルを使用しました。
このデータセットを Elasticsearch で使用するには:
Kibana の データファイルアップロード 機能を使用して、CSV ファイル ( ここ からダウンロード可能) をアップロードします。
このブログで紹介されている「埋め込み」と呼ばれるセマンティックフィールドを設定します。 multilingual-e5-small model
フィールド タイプのデフォルト ( purchase_dateとuser_feedback)を除くすべてのフィールドのキーワード) を使用してインポートを終了します。ここで提示されたクエリをそのまま実行できるようにするには、インデックス名phone_sales_analysisを必ず追加してください。
この分析の主な焦点は、 「iPhone 16 の購入者と他の人口セグメントの違いは何か」を発見し、マーケティング目的で購入者をセグメント化することです。
これはデータセットからのサンプルドキュメントです。{
         "customer_type": "Returning",
         "user_feedback": "I have to say, quality is great for the price. The battery life is really good.",
         "upgrade_frequency": "2 years",
         "storage_capacity": "256GB",
         "occupation": "Technology & Data",
         "color": "Phantom Black",
         "gender": "Male",
         "price_paid": 899,
         "previous_brand_loyalty": "Mixed",
         "location_type": "Urban",
         "phone_model": "Samsung Galaxy S24",
         "city_region": "San Francisco Bay Area",
         "@timestamp": "2024-03-15T00:00:00.000-05:00",
         "income_bracket": "75000-100000",
         "purchase_channel": "Online",
         "feedback_sentiment": "positive",
         "education_level": "Bachelor",
         "embedding": "I have to say, quality is great for the price. The battery life is really good.",
         "customer_id": "C001",
         "purchase_date": "2024-03-15",
         "age": 34,
         "trade_in_model": "iPhone 13"
}人口動態パターンの理解
ここでは、一般人口を対象に分析を実行し、iPhone 16 ユーザーにとって重要な用語の集計から得られた興味深い結果と比較します。
通常のパターン
通常の購入パターンを理解するために、さまざまなフィールドにわたるすべてのドキュメントのデータを集計できます。簡単にするために、携帯電話を購入した人の職業に焦点を当てて調査します。Elasticsearch へのリクエストでこれを実行できます。GET phone_sales_analysis/_search
{
 "aggs": {
   "occupation_distribution": {
     "terms": {
       "size": 5,
       "field": "occupation"
     }
   }
 },
 "size": 0
}これにより、データセット内の主な職業（レコード数別）は次のようになります。
iPhone 16ユーザーのパターン
iPhone 16 を購入した人々の違いを理解するために、次のように、クエリ内の人々を見つけるためのフィルターを使用して、同じフィールドで用語の集計を実行してみましょう。GET phone_sales_analysis/_search
{
  "query": {
    "term": {
      "phone_model": "iPhone 16"
    }
  },
  "aggs": {
    "occupation_distribution": {
      "terms": {
        "size": 5,
        "field": "occupation"
      }
    }
  },
  "size": 0
}つまり、iPhone 16ユーザーの主な職業は次のようになります。
iPhone 16 ユーザーは、他の電話モデルのユーザーと比べて、使用パターンが異なっていることがわかります。Kibana を使用して結果を簡単に視覚化してみましょう。
このグラフでは、iPhone 16 の傾向が全体の傾向と異なることがわかります。
この分析全体をスキップして、1つの重要な用語の集計を実行することで、iPhone 16ユーザーが一般ユーザーと何が違うのかを確認できます。GET phone_sales_analysis/_search
{
  "query": {
    "term": {
      "phone_model": "iPhone 16"
    }
  },
  "aggs": {
    "occupation_distribution": {
      "significant_terms": {
        "size": 5,
        "field": "occupation"
      }
    }
  },
  "size": 0
}つまり、次のような応答が得られます。
iPhone 16の職業の価値
ドキュメント数
bg_count
職業分布（最上位レベル）
122
424
医療・ヘルスケア分野
45
57
この回答は、iPhone 16 ユーザーが珍しい (つまり重大な) 状況にあることを明確に示しています。一般人口と比較した医療・ヘルスケア分野に従事する人の数。応答内の数字が何を意味するか見てみましょう。
最上位レベル:
doc_count: 122 —クエリは合計122の文書と一致しました
bg_count: 424 —背景セット（すべての販売文書）には424の文書が含まれています
医療・ヘルスケア分野:
doc_count: 45 — 122件の検索結果のうち45件に「医療とヘルスケア」が出現
bg_count: 57 —背景データセット内の合計424の文書のうち57に「医療とヘルスケア」が出現します
424 人の購入者のうち 57 人が医療・ヘルスケア分野で働いており、割合は 13.44% です。しかし、iPhone 16の購入者を見てみると、122人中45人が医療・ヘルスケア分野で働いており、その割合は36.88%です。つまり、iPhone 16 ユーザーの中に医療・ヘルスケアの分野で働く人がいる可能性が 2 倍になるということです。
同じ分析を他のフィールド（年齢、場所、収入層など）に適用すると、iPhone 16 ユーザーの独自性に関する詳細な情報を見つけることができます。
消費者セグメンテーション
重要な用語の集約を使用して、製品、カテゴリ、顧客セグメント間の関係性の洞察を抽出できます。このため、調査したいカテゴリの親集計を構築します。また、重要な用語と通常の用語のサブ集計を使用して、そのカテゴリに関する興味深い洞察を見つけ、その職業のほとんどの人が使用する用語と比較します。
たとえば、いくつかの職種の人々が何を好むかを見てみましょう。
分析をより明確にするために、検索を3つの職種に限定してみましょう: [「管理・サポート」、「テクノロジー・データ」、「医療・ヘルスケア」]
集計側では、職業別の用語集計から始めます。
サブ集計を1つ追加します: 電話モデル別の用語 - 各分野のユーザーがどのモデルを購入しているかを調べます
2番目のサブ集計を追加します: 電話モデル別の重要な用語 - 各作業分野でどのモデルが特別であるかを見つけますGET phone_sales_analysis/_search
{
 "query": {
   "terms": {
     "occupation": [
       "Administrative & Support",
       "Technology & Data",
       "Medical & Healthcare"
     ]
   }
 },
 "aggs": {
   "occupations": {
     "terms": {
       "size": 15,
       "field": "occupation"
     },
     "aggs": {
       "general_models": {
         "terms": {
           "field": "phone_model"
         }
       },
       "significant_models": {
         "significant_terms": {
           "field": "phone_model"
         }
       }
     }
   }
 },
 "size": 0
}集計結果を詳しく見てみましょう。
職業：管理・サポート
用語の集約
重要な用語の集約
この表から、この職業の傾向と人口全体の傾向の間には大きな違いがないことが推測できます。
職業：テクノロジー＆データ
用語の集約
重要な用語の集約
合計文書数: 424
この職業に関する文書: 71
携帯電話のモデル
ドキュメント数 （この職業のこのモデル）
bg_count （すべての文書でこのモデルを使用）
すべての文書の%
この職業における%
グーグルピクセル8
12
22
5.19%
16.90%
ワンプラス11
9
14
3.30%
12.68%
ワンプラス 12 プロ
3
3
0.71%
4.23%
Google Pixel 8 Pro
9
21
4.95%
12.68%
何もない電話2
5
8
1.89%
7.04%
サムスン ギャラクシー Z フォールド5
4
6
1.42%
5.63%
ワンプラス12
8
20
4.72%
11.27%
職業：医療・ヘルスケア
用語の集約
重要な用語の集約
合計文書数: 424
この職業に関する文書: 57
携帯電話のモデル
ドキュメント数 （この職業のこのモデル）
bg_count （すべての文書でこのモデルを使用）
すべての文書の%
この職業における%
iPhone 16
45
122
28.77%
78.95%
iPhone 15 Pro Max
3
13
3.07%
5.26%
iPhone 15
7
40
9.43%
12.28%
このデータが何を伝えているのか見てみましょう。
医療およびヘルスケアの専門家は iPhone 16 を好み、一般的に Apple の携帯電話を使用する傾向が非常に強いです。
テクノロジーおよびデータの専門家はハイエンドの Android スマートフォンを好みますが、必ずしも Samsung ブランドを使用するわけではありません。このカテゴリーでは、iPhone にもかなりのトレンドが見られます。
管理およびサポート担当者は Samsung や Google の携帯電話を好みますが、明確な独自の傾向はありません。
重要語の集約とハイブリッド検索
ハイブリッド検索は、テキスト検索とセマンティック結果を組み合わせて、検索エクスペリエンスを向上させます。この文脈において、重要な用語の集約は、「このデータセットは他のすべての文書と比べて何が特別なのか？」という問いに答えることで、コンテキスト認識検索の結果に関する洞察を提供することができます。この機能を示すために、ユーザーが優れたパフォーマンスについて語る際に、どのモデルが過剰に表現されているかを見てみましょう。 
フィールド埋め込みよりも入力「良いパフォーマンス」に近いトップユーザーフィードバックを見つけるセマンティッククエリを構築してみましょう。
テキストフィールドuser_feedbackで同じ用語を使ったテキスト検索も使用します。
また、完全なデータセットよりもこれらの結果の中でより頻繁に見つかる電話モデルを見つけるために、重要な用語クエリを追加します。
GET phone_sales_analysis/_search
{
 "retriever": {
   "rrf": {
     "retrievers": [
       {
         "standard": {
           "query": {
             "bool": {
               "must": [
                 {
                   "match": {
                     "user_feedback": {
                       "query": "good performance",
                       "operator": "and"
                     }
                   }
                 }
               ]
             }
           }
         }
       },
       {
         "standard": {
           "query": {
             "semantic": {
               "field": "embedding",
               "query": "good performance"
             }
           }
         }
       }
     ],
    "rank_window_size": 20
   }
 },
 "aggs": {
   "Models": {
     "significant_terms": {
       "field": "phone_model"
     }
   }
 }
}一致するドキュメントの例を見てみましょう。
返ってくる応答は次のとおりです。{
  "took": 388,
  "timed_out": false,
  "_shards": {
    "total": 1,
    "successful": 1,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": {
      "value": 20,
      "relation": "eq"
    },
    "max_score": 0.016393442,
    "hits": [...]
  },
  "aggregations": {
    "Models": {
      "doc_count": 20,
      "bg_count": 424,
      "buckets": [
        {
          "key": "iPhone 15",
          "doc_count": 5,
          "score": 0.4125,
          "bg_count": 40
        }
      ]
    }
  }
}
これは、iPhone 15 が合計 424 のドキュメントのうち 40 回 (ドキュメントの 9.4%) 出現している一方で、セマンティック検索「良好なパフォーマンス」に一致した 20 のドキュメント (ドキュメントの 25%) では 5 回見つかるということを示しています。したがって、次のような結論を導き出すことができます。優れたパフォーマンスについて話しているときに、偶然よりも iPhone 15 が見つかる可能性が 2.7 倍高くなります。
まとめ
重要な用語の集約により、データセットをドキュメント全体と比較することで、データセットの固有の詳細を明らかにすることができます。これにより、発生回数を超えて、データ内の予期しない関係が明らかになる可能性があります。さまざまなユースケースで重要な用語を適用して、非常に興味深い機能を実現できます。たとえば、次のようになります。
不正行為検出に取り組む際にパターンを見つけ、盗難されたクレジットカードの一般的な取引を識別します。
ユーザーレビューからのブランド品質の洞察 - 悪いレビューの数が不釣り合いに多いブランドを検出します。
誤分類されたドキュメントの検出- 説明にそのカテゴリに一般的でない単語を使用しているカテゴリ (用語フィルター) に属するドキュメントを検出します (重要な用語の集約)。


GCP GKE AutopilotでElasticsearchをデプロイする方法
Eduard Martin — Thu, 19 Jun 2025 00:00:00 GMT
この記事では、Autopilotを使用してGoogle Cloud Kubernetes（GKE）にElasticsearchをデプロイする方法を学びます。
Elasticsearchでは、Elastic Cloud on Kubernetes（ECK）を使用します。これはElasticsearch Kubernetes公式オペレーターであり、すべてのElastic StackコンポーネントのKubernetes導入のオーケストレーションを簡素化します。
ElasticsearchクラスターをさまざまなGCPインフラストラクチャーにデプロイする方法の詳細は、Google Cloud ComputeとGoogle Cloud Marketplaceの入門記事をご覧ください。
Elasticsearchの導入作業
GKE Autopilotとは何ですか？
Google Kubernetes Engine（GKE）Autopilotは、Googleがクラスター設定、ノード管理、セキュリティ、スケーリングを処理し、開発者がアプリケーションのデプロイに集中できる、完全に管理されたKubernetesエクスペリエンスを提供します。これにより、チームは組み込まれたベストプラクティスを使用し、コードから本番環境まで数分で移行できます。
Google CloudでECKを使用するタイミングは？
Elastic Cloud on Kubernetes（ECK）は、既存のKubernetesインフラを持つ組織が、専用ノードロール、高可用性、自動化などの高度な機能を備えたElasticsearchをデプロイするのに最適です。
Google CloudでECKを設定する方法は？
1. Google Cloud Consoleにログインします。
2. 右上のCloud Shellボタンをクリックし、コンソールにアクセスして、そこから GKEクラスターをデプロイします。あるいは、gcloud CLIを使用することもできます。
チュートリアルでは、必ずプロジェクトIDを自分のプロジェクトIDに更新してください。
3. Google Kubernetes Engine APIを有効にします。
[次へ] をクリックします。
これで、Kubernetes Engine APIを検索すると、Kubernetes Engine APIが有効になっていることが表示されます。
4. Cloud ShellでAutopilotクラスターを作成します。これをautopilot-cluster-1という名前にし、autopilot-testをプロジェクトのIDに置き換えます。
gcloud beta container --project "autopilot-test-457216" clusters create-auto "autopilot-cluster-1" --region "us-central1" --release-channel "regular" --tier "standard" --enable-ip-access --no-enable-google-cloud-access --network "projects/autopilot-test-457216/global/networks/default" --subnetwork "projects/autopilot-test-457216/regions/us-central1/subnetworks/default" --cluster-ipv4-cidr "/17" --binauthz-evaluation-mode=DISABLED5. 準備ができるまで待ちます。作成には10分ほどかかります。
クラスターを正しく設定すると確認メッセージが表示されます。
6. kubectlコマンドラインアクセスを設定します。
gcloud container clusters get-credentials autopilot-cluster-1 --region us-central1 --project autopilot-test-457216次のように表示されます。
autopilot-cluster-1用に生成されたkubeconfigエントリ。
7. Elastic Cloud on Kubernetes（ECK）オペレーターをインストールします。# Install ECK Custom Resource Definitions
kubectl create -f https://download.elastic.co/downloads/eck/2.16.1/crds.yaml

# Install the ECK operator
kubectl apply -f https://download.elastic.co/downloads/eck/2.16.1/operator.yaml8. デフォルト値で単一ノードのElasticsearchインスタンスを作成しましょう。
異なる設定のレシピを確認したい場合はこちらのリンクをご覧ください。
storageClassを指定しない場合、ECKはデフォルトで設定されたものを使用します。GKEの場合はstandard-rwoで、これはCompute Engine persistent disk CSI Driverを使用して1GBのボリュームを作成します。
cat <デフォルトの GKE マシンのvm.max_map_count値が低すぎるため、 nmapを無効にしました。本番環境ではこれを無効にせず、 vm.max_map_countの値を増やすことが推奨されます。詳しくはこちらをご覧ください。
9. Kibanaのシングルノードクラスターもデプロイしましょう。Kibanaの場合、デバイスからKibanaにアクセスするために使用できる外部IPを提供するLoadBalancerを追加します。
cat <注釈に注意してください。 
cloud.google.com/l4-rbs: "enabled"
これは、Autopilotにパブリック向けのLoadBalancerを提供するように指示するため、非常に重要です。設定しない場合、LoadBalancerは内部になります。
10. ポッドが動作していることを確認します。
kubectl get pods11. また、run kubectl get elasticsearchとkubectl get kibanaすることで、Elasticsearchのバージョン、ノード、健全性などのより具体的な統計情報を取得することもできます。
12. サービスにアクセスします。
kubectl get svcこれにより、EXTERNAL-IPのKibanaの外部URLが表示されます。LoadBalancerの提供には数分かかる場合があります。EXTERNAL-IPの値をコピーします。
13 「elastic」ユーザーのElasticsearchパスワードを取得します。
kubectl get secret quickstart-es-elastic-user -o=jsonpath='{.data.elastic}' | base64 --decode14. ブラウザからKibana にアクセスします。
URL: https://:5601
ユーザー名:elastic
パスワード:28Pao50lr2GpyguX470L2uj5（前のステップから）
15. ブラウザからアクセスすると、ウェルカム画面が表示されます。
ノードの変更やサイズ変更など、Elasticsearchクラスターの仕様を変更したい場合は、新しい設定でymlマニフェストを再度適用できます。
cat <この例では、ノードをもう1つ追加して、RAMとCPUを変更します。ご覧のとおり、 kubectl get elasticsearchには2つのノードが表示されています。
Kibanaにも同じことが当てはまります。
cat <コンテナのCPU/RAMとNode.jsのメモリ使用量（max-old-space-size）を調整できます。
既存のボリュームクレームを縮小することはできないことに留意してください。アップデートを適用した後、オペレーターは最小限の中断時間で変更を加えます。
不要なコストを避けるために、テストが完了したらクラスターを忘れずに削除してください。
gcloud container clusters delete autopilot-cluster-1今後の見通し
KubernetesとGoogle Kubernetes Engineについて詳しく知りたい場合は、次の記事をご覧ください。
Elastic Cloud on Kubernetes | Elastic Docs
GKE Autopilotのご紹介 | Google Cloudブログ
Autopilotの概要 | Google Kubernetes Engine（GKE）


JavaScript で Elasticsearch を正しく使う方法、パート II
Jeffrey Rengifo — Mon, 19 May 2025 00:00:00 GMT
これは、JavaScript での Elasticsearch シリーズの第 2 部です。最初の部分では、環境を正しくセットアップし、Node.js クライアントを構成し、データをインデックスして検索する方法を学びました。この第 2 部では、実稼働のベスト プラクティスを実装し、サーバーレス環境で Elasticsearch Node.jsクライアントを実行する方法を学習します。
以下を確認します:
制作のベストプラクティス
エラー処理
テスト
サーバーレス環境
Elastic Serverlessでクライアントを実行する
Function-as-a-Service 環境でクライアントを実行する
ここで 例付きのソースコードを確認できます 。
制作のベストプラクティス
Elasticsearchにおけるエラー処理。
Node.js の Elasticsearch クライアントの便利な機能は、Elasticsearch で発生する可能性のあるエラーのオブジェクトを公開し、さまざまな方法で検証して処理できることです。
すべてを表示するには、次のコマンドを実行します。const { errors } = require('@elastic/elasticsearch')
console.log(errors)検索の例に戻り、起こりうるエラーのいくつかを処理してみましょう。app.get("/search/lexic", async (req, res) => {
 ....
  } catch (error) {
    if (error instanceof errors.ResponseError) {
      let errorMessage =
        "Response error!, query malformed or server down, contact the administrator!";

      if (error.body.error.type === "parsing_exception") {
        errorMessage = "Query malformed, make sure mappings are set correctly";
      }

      res.status(error.meta.statusCode).json({
        erroStatus: error.meta.statusCode,
        success: false,
        results: null,
        error: errorMessage,
      });
    }

    res.status(500).json({
      success: false,
      results: null,
      error: error.message,
    });
  }
});ResponseError 特に、回答が4xxまたは5xx場合に発生します。これは、要求が正しくないか、サーバーが利用できないことを意味します。
このタイプのエラーは、テキストタイプのフィールドで用語クエリを実行するなど、間違ったクエリを生成することでテストできます。
デフォルトエラー: {
    "success": false,
    "results": null,
    "error": "parsing_exception\n\tRoot causes:\n\t\tparsing_exception: [terms] query does not support [visit_details]"
}カスタマイズされたエラー: {
    "erroStatus": 400,
    "success": false,
    "results": null,
    "error": "Response error!, query malformed or server down; contact the administrator!"
}各タイプのエラーを特定の方法でキャプチャして処理することもできます。たとえば、 TimeoutErrorに再試行ロジックを追加できます。app.get("/search/semantic", async (req, res) => {
    try {
  ...
  } catch (error) {
    if (error instanceof errors.TimeoutError) {


     // Retry logic...

      res.status(error.meta.statusCode).json({
        erroStatus: error.meta.statusCode,
        success: false,
        results: null,
        error:
          "The request took more than 10s after 3 retries. Try again later.",
      });
    }
  }
});テスト
テストはアプリの安定性を保証する上で重要です。Elasticsearch から分離された方法でコードをテストするには、クラスターを作成するときにライブラリelasticsearch-js-mock を使用できます。
このライブラリを使用すると、実際のクライアントと非常によく似たクライアントをインスタンス化できますが、クライアントの HTTP レイヤーのみをモックのレイヤーに置き換え、残りは元のレイヤーと同じにすることで、構成に応答します。
自動テスト用に、モック ライブラリとAVAをインストールします。
npm install @elastic/elasticsearch-mock
npm install --save-dev ava
テストを実行するためにpackage.jsonファイルを構成します。次のようになっていることを確認してください:"type": "module",
	"scripts": {
		"test": "ava"
	},
	"devDependencies": {
		"ava": "^5.0.0"
	}それでは、 test.jsファイルを作成し、モッククライアントをインストールしましょう。const { Client } = require('@elastic/elasticsearch')
const Mock = require('@elastic/elasticsearch-mock')

const mock = new Mock()
const client = new Client({
  node: 'http://localhost:9200',
  Connection: mock.getConnection()
})次に、セマンティック検索のモックを追加します。function createSemanticSearchMock(query, indexName) {
  mock.add(
    {
      method: "POST",
      path: `/${indexName}/_search`,
      body: {
        query: {
          semantic: {
            field: "semantic_field",
            query: query,
          },
        },
      },
    },
    () => {
      return {
        hits: {
          total: { value: 2, relation: "eq" },
          hits: [
            {
              _id: "1",
              _score: 0.9,
              _source: {
                owner_name: "Alice Johnson",
                pet_name: "Buddy",
                species: "Dog",
                breed: "Golden Retriever",
                vaccination_history: ["Rabies", "Parvovirus", "Distemper"],
                visit_details:
                  "Annual check-up and nail trimming. Healthy and active.",
              },
            },
            {
              _id: "2",
              _score: 0.7,
              _source: {
                owner_name: "Daniel Kim",
                pet_name: "Mochi",
                species: "Rabbit",
                breed: "Mixed",
                vaccination_history: [],
                visit_details:
                  "Nail trimming and general health check. No issues.",
              },
            },
          ],
        },
      };
    }
  );
}これで、コードのテストを作成し、Elasticsearch 部分が常に同じ結果を返すことを確認できるようになりました。import test from 'ava';

test("performSemanticSearch must return formatted results correctly", async (t) => {
  const indexName = "vet-visits";
  const query = "Which pets had nail trimming?";

  createSemanticSearchMock(query, indexName);

  async function performSemanticSearch(esClient, q, indexName = "vet-visits") {
    try {
      const result = await esClient.search({
        index: indexName,
        body: {
          query: {
            semantic: {
              field: "semantic_field",
              query: q,
            },
          },
        },
      });

      return {
        success: true,
        results: result.hits.hits,
      };
    } catch (error) {
      if (error instanceof errors.TimeoutError) {
        return {
          success: false,
          results: null,
          error: error.body.error.reason,
        };
      }

      return {
        success: false,
        results: null,
        error: error.message,
      };
    }
  }

  const result = await performSemanticSearch(esClient, query, indexName);

  t.true(result.success, "The search must be successful");
  t.true(Array.isArray(result.results), "The results must be an array");

  if (result.results.length > 0) {
    t.true(
      "_source" in result.results[0],
      "Each result must have a _source property"
    );
    t.true(
      "pet_name" in result.results[0]._source,
      "Results must include the pet_name field"
    );
    t.true(
      "visit_details" in result.results[0]._source,
      "Results must include the visit_details field"
    );
  }
});テストを実行してみましょう。
npm run test
完了です！これからは、外部要因ではなくコードに100%重点を置いてアプリをテストできます。
サーバーレス環境
Elastic Serverlessでクライアントを実行する方法
クラウドまたはオンプレミスでの Elasticsearch の実行について説明しましたが、Node.js クライアントはElastic Cloud Serverlessへの接続もサポートしています。
Elastic Cloud Serverless を使用すると、Elastic がインフラストラクチャを内部で処理するためインフラストラクチャについて心配する必要がないプロジェクトを作成でき、インデックスを作成するデータとそのデータにアクセスする期間のみを考慮すれば済みます。
使用の観点から見ると、Serverless はコンピューティングとストレージを切り離し、検索とインデックス作成の両方に自動スケーリング機能を提供します。これにより、実際に必要なリソースのみを増やすことができます。
クライアントは、Serverless に接続するために次の調整を行います。
スニッフィングをオフにし、スニッフィング関連のオプションを無視します
最初のノードを除いて、config で渡されたすべてのノードを無視し、ノードのフィルタリングと選択のオプションも無視します。
圧縮と `TLSv1_2_method` を有効にします（Elastic Cloud 用に構成した場合と同じ）
すべてのリクエストに `elastic-api-version` HTTP ヘッダーを追加します
デフォルトでは `WeightedConnectionPool` ではなく `CloudConnectionPool` を使用します
標準の MIME タイプを優先して、ベンダーの `content-type` および `accept` ヘッダーをオフにします。
サーバーレス プロジェクトを接続するには、パラメーター serverMode: serverless を使用する必要があります。const { Client } = require('@elastic/elasticsearch')
const client = new Client({
  node: 'ELASTICSEARCH_ENDPOINT',
  auth: { apiKey: 'ELASTICSEARCH_API_KEY' },
  serverMode: "serverless",
});Function-as-a-Service環境でクライアントを実行する方法
この例では Node.js サーバーを使用しましたが、AWS lambda、GCP Run などの機能を備えた Function-as-a-Service 環境を使用して接続することもできます。'use strict'

const { Client } = require('@elastic/elasticsearch')

const client = new Client({
  // client initialisation
})

exports.handler = async function (event, context) {
  // use the client
}もう 1 つの例は、同じくサーバーレスである Vercel などのサービスに接続することです。これを実行する方法の完全な例を確認できますが、検索エンドポイントの最も重要な部分は次のようになります。const response = await client.search(
  {
    index: INDEX,
    // You could directly send from the browser
    // the Elasticsearch's query DSL, but it will
    // expose you to the risk that a malicious user
    // could overload your cluster by crafting
    // expensive queries.
    query: {
      match: { field: req.body.text },
    },
  },
  {
    headers: {
      Authorization: `ApiKey ${token}`,
    },
  }
);このエンドポイントは /api フォルダーにあり、サーバー側から実行されるため、クライアントは検索用語に対応する「テキスト」パラメータのみを制御できます。
Function-as-a-Service を使用する意味は、24 時間 365 日稼働するサーバーとは異なり、関数は関数を実行するマシンのみを起動し、関数が終了するとマシンは休止モードになり、消費するリソースが少なくなることです。
この構成は、アプリケーションがあまり多くのリクエストを受け取らない場合には便利ですが、そうでない場合はコストが高くなる可能性があります。また、関数のライフサイクルと実行時間 (場合によっては数秒しかないこともあります) も考慮する必要があります。
まとめ
この記事では、実稼働環境で非常に重要なエラーの処理方法を学びました。また、Elasticsearch サービスをモックしながらアプリケーションをテストする方法についても説明しました。これにより、クラスターの状態に関係なく信頼性の高いテストが提供され、コードに集中できるようになります。
最後に、Elastic Cloud Serverless と Vercel アプリケーションの両方をプロビジョニングして、完全にサーバーレスなスタックを立ち上げる方法を示しました。


Elasticsearch のディスク容量と使用量を最適化する方法
Kofi Bartlett — Fri, 16 May 2025 00:00:00 GMT
ディスク管理はどのデータベースでも重要であり、Elasticsearch も例外ではありません。十分なディスク容量がない場合、Elasticsearch はノードへのシャードの割り当てを停止します。これにより、最終的にはクラスターにデータを書き込むことができなくなり、アプリケーションでデータが失われる潜在的なリスクが生じます。一方、ディスク容量が多すぎる場合は、必要以上のリソースに対して料金を支払うことになります。
透かしの背景
Elasticsearch クラスターには、使用可能なディスク容量を追跡するのに役立つさまざまな「ウォーターマーク」しきい値があります。ノード上のディスクがいっぱいになると、最初に超えるしきい値は「低ディスク ウォーターマーク」になります。2 番目のしきい値は、「高ディスク ウォーターマークしきい値」になります。最終的には、「ディスク洪水段階」に到達します。このしきい値を超えると、クラスターは、ウォーターマークを通過したノード上の 1 つのシャード (プライマリまたはレプリカ) を持つすべてのインデックスへの書き込みをブロックします。読み取り（検索）は引き続き可能です。
ディスクがいっぱいになった場合（過剰使用）の防止と対処方法
Elasticsearch ディスクがいっぱいになった場合の対処方法はいくつかあります。
古いデータ を削除する: 通常、データを無期限に保存しないでください。ディスクがいっぱいになるのを防ぎ、解決する 1 つの方法は、データが一定の期間に達したときに確実にアーカイブされ、削除されるようにすることです。これを行う 1 つの方法は、 ILM を使用することです。
ストレージ容量の追加:データを削除できない場合は、パフォーマンスに悪影響を与えずにすべてのデータを保持するために、データ ノードを追加するか、ディスク サイズを増やす必要がある場合があります。クラスターにストレージ容量を追加する必要がある場合は、ストレージ容量だけを追加するのか、それともストレージ容量に加えて RAM と CPU のリソースも比例して追加するのかを検討する必要があります (以下のディスク サイズ、RAM、CPU の比率に関するセクションを参照)。
Elasticsearch クラスターにストレージ容量を追加する方法
データ ノードの数を増やします。新しいノードは既存のノードと同じサイズで、同じ Elasticsearch バージョンである必要があることに注意してください。
既存のノードのサイズを増やす:クラウドベースの環境では、通常、既存のノードのディスク サイズと RAM/CPU を増やすのは簡単です。
ディスク サイズのみを増やす:クラウドベースの環境では、ディスク サイズを増やすのは比較的簡単です。
スナップショット そして 復元:要求に応じて古いデータを自動プロセスでバックアップから取得できるようにする場合は、古いインデックスのスナップショットを作成し、それらを削除して、要求に応じてスナップショットからデータを一時的に復元できます。
シャードごとのレプリカの数を減らす:データを削減するもう 1 つのオプションは、各シャードのレプリカの数を減らすことです。高可用性を実現するには、シャードごとに 1 つのレプリカを用意する必要がありますが、データが古くなると、レプリカなしでも作業できる可能性があります。これは通常、データが永続的である場合、または必要に応じて復元できるバックアップがある場合に機能します。
アラートを作成する:将来ディスクがいっぱいになるのを防ぎ、積極的に対処するには、ディスクの使用状況に基づいて、ディスクがいっぱいになり始めたときに通知するアラートを作成する必要があります。
ディスク容量が十分に活用されない場合の防止と対処方法
ディスク容量が十分に活用されていない場合は、クラスター上のストレージ ボリュームを削減するさまざまなオプションがあります。
Elasticsearch クラスターのストレージ容量を削減する方法
クラスターのストレージ容量を削減する方法はさまざまです。
1. データノードの数を減らす
データストレージを削減し、RAM と CPU リソースも同じ割合で削減したい場合は、これが最も簡単な戦略です。不要なノードを廃止すると、最大のコスト削減が実現する可能性があります。
ノードを廃止する前に、次の操作を行う必要があります。
廃止するノードが MASTER ノードとして必要ではないことを確認します。常に、MASTER ノード ロールを持つノードが少なくとも 3 つ必要です。
廃止するノードからデータ シャードを移行します。
2. 既存のノードを小さなノードに置き換える
ノードの数をさらに減らすことができない場合 (通常、最小構成は 3 です)、既存のノードのサイズを縮小することが必要になる場合があります。シャードはノードあたりのシャード数に基づいてバランスが取られるため、すべてのデータ ノードが同じ RAM メモリとディスク サイズであることを確認することをお勧めします。
プロセスは次のようになります。
クラスターに新しい小さなノードを追加する
廃止するノードからシャードを移行する
古いノードをシャットダウンする
3. ノード上のディスクサイズを減らす
クラスターの全体的な RAM または CPU を変更せずに、ノード上のディスク サイズのみを削減したい場合は、各ノードのディスク サイズを削減できます。Elasticsearch ノード上のディスク サイズを縮小するのは簡単なプロセスではありません。
最も簡単な方法は通常次のようになります。
ノードからシャードを移行する
ノードを停止する
適切なサイズの新しいデータボリュームをノードにマウントします
古いディスクボリュームから新しいボリュームにすべてのデータをコピーします
古いボリュームAを切り離す
ノードを起動し、シャードをノードに戻す
これには、このプロセス中にノードからの追加シャードを一時的に保存するのに十分な容量が他のノードに必要です。多くの場合、このプロセスの管理にかかるコストは、ディスク使用量の潜在的な節約額を上回る可能性があります。このため、必要なディスク サイズを持つ新しいノードにノード全体を置き換える方が簡単な場合があります (上記の「既存のノードをより小さなノードに置き換える」を参照)。
不要なリソースに料金を支払う場合、リソースの使用率を最適化することでコストを削減できることは明らかです。
ディスクサイズ、RAM、CPUの関係
クラスター内のディスク容量と RAM の理想的な比率は、特定のユースケースによって異なります。このため、ストレージ容量の変更を検討する際には、現在のディスク/RAM/CPU の比率が適切にバランスされているかどうか、また、その結果として RAM/CPU を同じ比率で追加/削減する必要があるかどうかも考慮する必要があります。
RAM と CPU の要件は、インデックス作成アクティビティの量、クエリの数と種類、さらに検索および集約されるデータの量によって異なります。これは多くの場合、クラスターに保存されるデータの量に比例するため、ディスク サイズにも関連している必要があります。
ディスク容量と RAM の比率は、使用事例に応じて変わる可能性があります。ここでいくつかの例をご覧ください:
インデックスアクティビティ
保持
検索アクティビティ
ディスク容量
ラム
エンタープライズ検索アプリ
中程度のログ摂取
長さ
ライト
2TB
32GB
アプリ監視
集中的なログ取り込み
短い
ライト
1TB
32GB
電子商取引
軽量データインデックス
不定
重い
500GB
32GB
ノード マシンの構成の変更は、ノードのダウンタイムが発生する可能性があり、すでに過剰に負荷がかかっている他のノードにシャードが移行しないようにする必要があるため、慎重に行う必要があることに注意してください。


JavaScript で Elasticsearch を正しく使う方法、パート 1
Jeffrey Rengifo — Thu, 15 May 2025 00:00:00 GMT
これは、JavaScript で Elasticsearch を使用する方法を説明するシリーズの最初の記事です。このシリーズでは、JavaScript 環境で Elasticsearch を使用する方法の基本を学習し、検索アプリを作成するための最も関連性の高い機能とベスト プラクティスを確認します。最後には、JavaScript を使用して Elasticsearch を実行するために必要なすべてのことを理解できるようになります。
この最初の部分では、次の点を確認します。
環境
フロントエンド、バックエンド、それともサーバーレス？
クライアントの接続
文書のインデックス作成
Elasticsearchクライアント
セマンティックマッピング
バルクヘルパー
データの検索
語彙クエリ
セマンティッククエリ
ハイブリッドクエリ
ここで 例付きのソースコードを確認できます 。
Elasticsearch Node.js クライアントとは何ですか?
Elasticsearch Node.js クライアントは、Elasticsearch API からの HTTP REST 呼び出しを JavaScript に配置する JavaScript ライブラリです。これにより、処理が容易になり、ドキュメントのインデックス作成などのタスクを一括で簡素化するヘルパーが利用できるようになります。
環境
フロントエンド、バックエンド、それともサーバーレス？
JavaScript クライアントを使用して検索アプリを作成するには、Elasticsearch クラスターとクライアントを実行する JavaScript ランタイムという少なくとも 2 つのコンポーネントが必要です。
JavaScript クライアントはすべての Elasticsearch ソリューション (クラウド、オンプレミス、サーバーレス) をサポートしており、クライアントがすべてのバリエーションを内部で処理するため、ソリューション間に大きな違いはありません。そのため、どれを使用するかについて心配する必要はありません。
ただし、JavaScript ランタイムはブラウザから直接ではなく、サーバーから実行する必要があります。
これは、ブラウザから Elasticsearch を呼び出すと、ユーザーがクラスター API キー、ホスト、クエリ自体などの機密情報を取得する可能性があるためです。Elasticsearch では、クラスターをインターネットに直接公開せず、このすべての情報を抽象化する中間層を使用して、ユーザーがパラメータのみを確認できるようにすることを推奨しています。このトピックの詳細については、ここ をご覧ください。
次のようなスキーマを使用することをお勧めします。
この場合、クライアントは検索用語とサーバーの認証キーのみを送信し、サーバーはクエリと Elasticsearch との通信を完全に制御します。
クライアントの接続
まず、次の手順に従って API キーを作成します。
前の例に従って、シンプルな Express サーバーを作成し、Node.JS サーバーからのクライアントを使用してそのサーバーに接続します。
NPM を使用してプロジェクトを初期化し、Elasticsearch クライアントとExpress をインストールします。後者は、Node.js でサーバーを起動するためのライブラリです。Express を使用すると、HTTP 経由でバックエンドと対話できます。
プロジェクトを初期化しましょう:
npm init -y
依存関係をインストールします:
npm install @elastic/elasticsearch express split2 dotenv
詳しく説明しましょう:
@elastic/elasticsearch : 公式Node.jsクライアントです
express : 軽量なNode.jsサーバーを立ち上げてElasticsearchを公開できるようになります
split2 : テキスト行をストリームに分割します。ndjsonファイルを1行ずつ処理するのに便利です
dotenv : .env を使用して環境変数を管理できるようにしますファイル
.envを作成するプロジェクトのルートにあるファイルを作成し、次の行を追加します。ELASTICSEARCH_ENDPOINT="Your Elasticsearch endpoint"
ELASTICSEARCH_API_KEY="Your Elasticssearch API"この方法では、 dotenvパッケージを使用してこれらの変数をインポートできます。
server.jsファイルを作成します:const express = require("express");
const bodyParser = require("body-parser");
const { Client } = require("@elastic/elasticsearch");
 
require("dotenv").config(); //environment variables setup

const ELASTICSEARCH_ENDPOINT = process.env.ELASTICSEARCH_ENDPOINT;
const ELASTICSEARCH_API_KEY = process.env.ELASTICSEARCH_API_KEY;
const PORT = 3000;


const app = express();

app.listen(PORT, () => {
  console.log("Server running on port", PORT);
});
app.use(bodyParser.json());


let esClient = new Client({
  node: ELASTICSEARCH_ENDPOINT,
  auth: { apiKey: ELASTICSEARCH_API_KEY },  
});

app.get("/ping", async (req, res) => {
  try {
    const result = await esClient.info();

    res.status(200).json({
      success: true,
      clusterInfo: result,
    });
  } catch (error) {
    console.error("Error getting Elasticsearch info:", error);

    res.status(500).json({
      success: false,
      clusterInfo: null,
      error: error.message,
    });
  }
});このコードは、ポート 3000 をリッスンし、認証用の API キーを使用して Elasticsearch クラスターに接続する基本的な Express.js サーバーをセットアップします。これには、GET リクエストを介してアクセスすると、Elasticsearch クライアントの.info()メソッドを使用して Elasticsearch クラスターに基本情報を照会する /ping エンドポイントが含まれています。
クエリが成功した場合は、クラスター情報が JSON 形式で返され、それ以外の場合はエラー メッセージが返されます。サーバーは、JSON リクエスト本体を処理するために body-parser ミドルウェアも使用します。
ファイルを実行してサーバーを起動します。
node server.js
答えは次のようになるはずです:
Server running on port 3000それでは、エンドポイント/pingを参照して、Elasticsearch クラスターのステータスを確認しましょう。curl http://localhost:3000/ping
{
    "success": true,
    "clusterInfo": {
        "name": "instance-0000000000",
        "cluster_name": "61b7e19eec204d59855f5e019acd2689",
        "cluster_uuid": "BIfvfLM0RJWRK_bDCY5ldg",
        "version": {
            "number": "9.0.0",
            "build_flavor": "default",
            "build_type": "docker",
            "build_hash": "112859b85d50de2a7e63f73c8fc70b99eea24291",
            "build_date": "2025-04-08T15:13:46.049795831Z",
            "build_snapshot": false,
            "lucene_version": "10.1.0",
            "minimum_wire_compatibility_version": "8.18.0",
            "minimum_index_compatibility_version": "8.0.0"
        },
        "tagline": "You Know, for Search"
    }
}文書のインデックス作成
接続すると、セマンティック検索用のsemantic_textやフルテキストクエリ用の text などのマッピングを使用してドキュメントのインデックスを作成できます。これら 2 つのフィールド タイプを使用すると、ハイブリッド検索も実行できます。
マッピングを生成し、ドキュメントをアップロードするために、新しいload.jsファイルを作成します。
Elasticsearchクライアント
まずクライアントをインスタンス化して認証する必要があります。const { Client } = require("@elastic/elasticsearch");

const ELASTICSEARCH_ENDPOINT = "cluster/project_endpoint";
const ELASTICSEARCH_API_KEY = "apiKey";

const esClient = new Client({
  node: ELASTICSEARCH_ENDPOINT,
  auth: { apiKey: ELASTICSEARCH_API_KEY },
});セマンティックマッピング
動物病院に関するデータを含むインデックスを作成します。飼い主様、ペット様、訪問の詳細に関する情報を保存します。
名前や説明など、全文検索を実行するデータはテキストとして保存されます。動物の種や品種などのカテゴリのデータは、キーワードとして保存されます。
さらに、すべてのフィールドの値を semantic_text フィールドにコピーして、その情報に対してもセマンティック検索を実行できるようにします。const INDEX_NAME = "vet-visits";

const createMappings = async (indexName, mapping) => {
  try {
    const body = await esClient.indices.create({
      index: indexName,
      body: {
        mappings: mapping,
      },
    });

    console.log("Index created successfully:", body);
  } catch (error) {
    console.error("Error creating mapping:", error);
  }
};

await createMappings(INDEX_NAME, {
  properties: {
    owner_name: {
      type: "text",
      copy_to: "semantic_field",
    },
    pet_name: {
      type: "text",
      copy_to: "semantic_field",
    },
    species: {
      type: "keyword",
      copy_to: "semantic_field",
    },
    breed: {
      type: "keyword",
      copy_to: "semantic_field",
    },
    vaccination_history: {
      type: "keyword",
      copy_to: "semantic_field",
    },
    visit_details: {
      type: "text",
      copy_to: "semantic_field",
    },
    semantic_field: {
      type: "semantic_text",
    },
  },
});バルクヘルパー
クライアントのもう 1 つの利点は、一括ヘルパーを使用してインデックスを一括で作成できることです。バルク ヘルパーを使用すると、同時実行、再試行、関数を通過して成功または失敗した各ドキュメントの処理などを簡単に処理できます。
このヘルパーの魅力的な機能は、ストリームを操作できることです。この機能を使用すると、ファイル全体をメモリに保存して Elasticsearch に一度に送信するのではなく、ファイルを 1 行ずつ送信できます。
Elasticsearch にデータをアップロードするには、プロジェクトのルートに data.ndjson というファイルを作成し、以下の情報を追加します (または、ここからデータセットを含むファイルをダウンロードすることもできます)。{"owner_name":"Alice Johnson","pet_name":"Buddy","species":"Dog","breed":"Golden Retriever","vaccination_history":["Rabies","Parvovirus","Distemper"],"visit_details":"Annual check-up and nail trimming. Healthy and active."}
{"owner_name":"Marco Rivera","pet_name":"Milo","species":"Cat","breed":"Siamese","vaccination_history":["Rabies","Feline Leukemia"],"visit_details":"Slight eye irritation, prescribed eye drops."}
{"owner_name":"Sandra Lee","pet_name":"Pickles","species":"Guinea Pig","breed":"Mixed","vaccination_history":[],"visit_details":"Loss of appetite, recommended dietary changes."}
{"owner_name":"Jake Thompson","pet_name":"Luna","species":"Dog","breed":"Labrador Mix","vaccination_history":["Rabies","Bordetella"],"visit_details":"Mild ear infection, cleaning and antibiotics given."}
{"owner_name":"Emily Chen","pet_name":"Ziggy","species":"Cat","breed":"Mixed","vaccination_history":["Rabies","Feline Calicivirus"],"visit_details":"Vaccination update and routine physical."}
{"owner_name":"Tomás Herrera","pet_name":"Rex","species":"Dog","breed":"German Shepherd","vaccination_history":["Rabies","Parvovirus","Leptospirosis"],"visit_details":"Follow-up for previous leg strain, improving well."}
{"owner_name":"Nina Park","pet_name":"Coco","species":"Ferret","breed":"Mixed","vaccination_history":["Rabies"],"visit_details":"Slight weight loss; advised new diet."}
{"owner_name":"Leo Martínez","pet_name":"Simba","species":"Cat","breed":"Maine Coon","vaccination_history":["Rabies","Feline Panleukopenia"],"visit_details":"Dental cleaning. Minor tartar buildup removed."}
{"owner_name":"Rachel Green","pet_name":"Rocky","species":"Dog","breed":"Bulldog Mix","vaccination_history":["Rabies","Parvovirus"],"visit_details":"Skin rash, antihistamines prescribed."}
{"owner_name":"Daniel Kim","pet_name":"Mochi","species":"Rabbit","breed":"Mixed","vaccination_history":[],"visit_details":"Nail trimming and general health check. No issues."}バルク ヘルパーがファイル行を Elasticsearch に送信する間、split2 を使用してファイル行をストリーミングします。const { createReadStream } = require("fs");
const split = require("split2");
 
const indexData = async (filePath, indexName) => {
  try {
    console.log(`Indexing data from ${filePath} into ${indexName}...`);

    const result = await esClient.helpers.bulk({
      datasource: createReadStream(filePath).pipe(split()),

      onDocument: () => {
        return {
          index: { _index: indexName },
        };
      },
      onDrop(doc) {
        console.error("Error processing document:", doc);
      },
    });

    console.log("Bulk indexing successful elements:", result.items.length);
  } catch (error) {
    console.error("Error indexing data:", error);
    throw error;
  }
};

await indexData("./data.ndjson", INDEX_NAME);上記のコードは.ndjsonを読み取りますファイルを 1 行ずつ読み込み、 helpers.bulkメソッドを使用して各 JSON オブジェクトを指定された Elasticsearch インデックスに一括インデックスします。createReadStreamとsplit2を使用してファイルをストリーミングし、各ドキュメントのインデックス メタデータを設定し、処理に失敗したドキュメントをログに記録します。完了すると、正常にインデックスが作成されたアイテムの数を記録します。
indexData関数を使用する代わりに、Kibana を使用して UI 経由でファイルを直接アップロードし、データ ファイルのアップロード UI を使用することもできます。
ファイルを実行して、ドキュメントを Elasticsearch クラスターにアップロードします。
node load.jsCreating mappings for index vet-visits...
Index created successfully: { acknowledged: true, shards_acknowledged: true, index: 'vet-visits' }
Indexing data from ./data.ndjson into vet-visits...
Bulk indexing completed. Total documents: 10, Failed: 0Elasticsearchでのデータ検索
server.jsファイルに戻って、語彙検索、セマンティック検索、ハイブリッド検索を実行するためのさまざまなエンドポイントを作成します。
簡単に言えば、これらのタイプの検索は相互に排他的ではありませんが、回答する必要がある質問の種類によって異なります。
クエリタイプ
使用事例
例題
語彙クエリ
質問内の単語または語根は、索引文書に表示される可能性があります。質問とドキュメント間のトークンの類似性。
青いスポーツTシャツを探しています。
セマンティッククエリ
質問内の単語は文書には表示されない可能性があります。質問とドキュメント間の概念的な類似性。
寒い季節用の服を探しています。
ハイブリッド検索
質問には語彙や意味の要素が含まれています。質問とドキュメント間のトークンと意味の類似性。
ビーチでの結婚式用にSサイズのドレスを探しています。
質問の語彙部分はタイトルや説明、またはカテゴリ名の一部である可能性が高く、意味部分はそれらの分野に関連する概念です。青はおそらくカテゴリ名または説明の一部であり、ビーチウェディングはそうではないかもしれませんが、意味的にはリネンの衣服に関連している可能性があります。
語彙クエリ (/search/lexic?q=)
語彙検索 (フルテキスト検索とも呼ばれる) とは、トークンの類似性に基づいて検索することを意味します。つまり、分析後、検索内のトークンを含むドキュメントが返されます。
語彙検索の実践チュートリアルは、こちらでご覧いただけます。app.get("/search/lexic", async (req, res) => {
  const { q } = req.query;

  const INDEX_NAME = "vet-visits";

  try {
    const result = await esClient.search({
      index: INDEX_NAME,
      size: 5,
      body: {
        query: {
          multi_match: {
            query: q,
            fields: ["owner_name", "pet_name", "visit_details"],
          },
        },
      },
    });

    res.status(200).json({
      success: true,
      results: result.hits.hits
    });
  } catch (error) {
    console.error("Error performing search:", error);

    res.status(500).json({
      success: false,
      results: null,
      error: error.message,
    });
  }
});爪切りでテストする
curl http://localhost:3000/search/lexic?q=nail%20trimming答え：{
    "success": true,
    "results": [
        {
            "_index": "vet-visits",
            "_id": "-RY6RJYBLe2GoFQ6-9n9",
            "_score": 2.7075968,
            "_source": {
                "pet_name": "Mochi",
                "owner_name": "Daniel Kim",
                "species": "Rabbit",
                "visit_details": "Nail trimming and general health check. No issues.",
                "breed": "Mixed",
                "vaccination_history": []
            }
        },
        {
            "_index": "vet-visits",
            "_id": "8BY6RJYBLe2GoFQ6-9n9",
            "_score": 2.560356,
            "_source": {
                "pet_name": "Buddy",
                "owner_name": "Alice Johnson",
                "species": "Dog",
                "visit_details": "Annual check-up and nail trimming. Healthy and active.",
                "breed": "Golden Retriever",
                "vaccination_history": [
                    "Rabies",
                    "Parvovirus",
                    "Distemper"
                ]
            }
        }
    ]
}セマンティッククエリ (/search/semantic?q=)
セマンティック検索は、語彙検索とは異なり、ベクトル検索を通じて検索用語の意味に類似した結果を見つけます。
セマンティック検索の実践チュートリアルは、こちらでご覧いただけます。app.get("/search/semantic", async (req, res) => {
  const { q } = req.query;

  const INDEX_NAME = "vet-visits";

  try {
    const result = await esClient.search({
      index: INDEX_NAME,
      size: 5,
      body: {
        query: {
          semantic: {
            field: "semantic_field",
            query: q
          },
        },
      },
    });

    res.status(200).json({
      success: true,
      results: result.hits.hits,
    });
  } catch (error) {
    console.error("Error performing search:", error);

    res.status(500).json({
      success: false,
      results: null,
      error: error.message,
    });
  }
});テスト対象:誰がペディキュアをしましたか?
curl http://localhost:3000/search/semantic?q=Who%20got%20a%20pedicure?答え：{
    "success": true,
    "results": [
        {
            "_index": "vet-visits",
            "_id": "-RY6RJYBLe2GoFQ6-9n9",
            "_score": 4.861466,
            "_source": {
                "owner_name": "Daniel Kim",
                "pet_name": "Mochi",
                "species": "Rabbit",
                "breed": "Mixed",
                "vaccination_history": [],
                "visit_details": "Nail trimming and general health check. No issues."
            }
        },
        {
            "_index": "vet-visits",
            "_id": "8BY6RJYBLe2GoFQ6-9n9",
            "_score": 4.7152824,
            "_source": {
                "pet_name": "Buddy",
                "owner_name": "Alice Johnson",
                "species": "Dog",
                "visit_details": "Annual check-up and nail trimming. Healthy and active.",
                "breed": "Golden Retriever",
                "vaccination_history": [
                    "Rabies",
                    "Parvovirus",
                    "Distemper"
                ]
            }
        },
        {
            "_index": "vet-visits",
            "_id": "9RY6RJYBLe2GoFQ6-9n9",
            "_score": 1.6717153,
            "_source": {
                "pet_name": "Rex",
                "owner_name": "Tomás Herrera",
                "species": "Dog",
                "visit_details": "Follow-up for previous leg strain, improving well.",
                "breed": "German Shepherd",
                "vaccination_history": [
                    "Rabies",
                    "Parvovirus",
                    "Leptospirosis"
                ]
            }
        },
        {
            "_index": "vet-visits",
            "_id": "9xY6RJYBLe2GoFQ6-9n9",
            "_score": 1.5600781,
            "_source": {
                "pet_name": "Simba",
                "owner_name": "Leo Martínez",
                "species": "Cat",
                "visit_details": "Dental cleaning. Minor tartar buildup removed.",
                "breed": "Maine Coon",
                "vaccination_history": [
                    "Rabies",
                    "Feline Panleukopenia"
                ]
            }
        },
        {
            "_index": "vet-visits",
            "_id": "-BY6RJYBLe2GoFQ6-9n9",
            "_score": 1.2696637,
            "_source": {
                "pet_name": "Rocky",
                "owner_name": "Rachel Green",
                "species": "Dog",
                "visit_details": "Skin rash, antihistamines prescribed.",
                "breed": "Bulldog Mix",
                "vaccination_history": [
                    "Rabies",
                    "Parvovirus"
                ]
            }
        }
    ]
}ハイブリッド クエリ (/search/hybrid?q=)
ハイブリッド検索により、セマンティック検索と語彙検索を組み合わせることができるため、両方の長所を活用できます。つまり、トークンによる検索の精度と、セマンティック検索の意味の近似性の両方が得られます。app.get("/search/hybrid", async (req, res) => {
  const { q } = req.query;

  const INDEX_NAME = "vet-visits";

  try {
    const result = await esClient.search({
      index: INDEX_NAME,
      body: {
        retriever: {
          rrf: {
            retrievers: [
              {
                standard: {
                  query: {
                    bool: {
                      must: {
                         multi_match: {
             query: q,
            fields: ["owner_name", "pet_name", "visit_details"],
          },
                      },
                    },
                  },
                },
              },
              {
                standard: {
                  query: {
                    bool: {
                      must: {
                        semantic: {
                          field: "semantic_field",
                          query: q,
                        },
                      },
                    },
                  },
                },
              },
            ],
          },
        },
        size: 5,
      },
    });

    res.status(200).json({
      success: true,
      results: result.hits.hits,
    });
  } catch (error) {
    console.error("Error performing search:", error);

    res.status(500).json({
      success: false,
      results: null,
      error: error.message,
    });
  }
});「ペディキュアや歯科治療を受けた人はいますか？」という質問をしてテストします。
curl http://localhost:3000/search/hybrid?q=who%20got%20a%20pedicure%20or%20dental%20treatment対応：{
    "success": true,
    "results": [
        {
            "_index": "vet-visits",
            "_id": "9xY6RJYBLe2GoFQ6-9n9",
            "_score": 0.032522473,
            "_source": {
                "pet_name": "Simba",
                "owner_name": "Leo Martínez",
                "species": "Cat",
                "visit_details": "Dental cleaning. Minor tartar buildup removed.",
                "breed": "Maine Coon",
                "vaccination_history": [
                    "Rabies",
                    "Feline Panleukopenia"
                ]
            }
        },
        {
            "_index": "vet-visits",
            "_id": "-RY6RJYBLe2GoFQ6-9n9",
            "_score": 0.016393442,
            "_source": {
                "pet_name": "Mochi",
                "owner_name": "Daniel Kim",
                "species": "Rabbit",
                "visit_details": "Nail trimming and general health check. No issues.",
                "breed": "Mixed",
                "vaccination_history": []
            }
        },
        {
            "_index": "vet-visits",
            "_id": "8BY6RJYBLe2GoFQ6-9n9",
            "_score": 0.015873017,
            "_source": {
                "pet_name": "Buddy",
                "owner_name": "Alice Johnson",
                "species": "Dog",
                "visit_details": "Annual check-up and nail trimming. Healthy and active.",
                "breed": "Golden Retriever",
                "vaccination_history": [
                    "Rabies",
                    "Parvovirus",
                    "Distemper"
                ]
            }
        },
        {
            "_index": "vet-visits",
            "_id": "9RY6RJYBLe2GoFQ6-9n9",
            "_score": 0.015625,
            "_source": {
                "pet_name": "Rex",
                "owner_name": "Tomás Herrera",
                "species": "Dog",
                "visit_details": "Follow-up for previous leg strain, improving well.",
                "breed": "German Shepherd",
                "vaccination_history": [
                    "Rabies",
                    "Parvovirus",
                    "Leptospirosis"
                ]
            }
        },
        {
            "_index": "vet-visits",
            "_id": "8xY6RJYBLe2GoFQ6-9n9",
            "_score": 0.015384615,
            "_source": {
                "pet_name": "Luna",
                "owner_name": "Jake Thompson",
                "species": "Dog",
                "visit_details": "Mild ear infection, cleaning and antibiotics given.",
                "breed": "Labrador Mix",
                "vaccination_history": [
                    "Rabies",
                    "Bordetella"
                ]
            }
        }
    ]
}まとめ
このシリーズの最初の部分では、クライアント/サーバーのベストプラクティスに従って、環境を設定し、さまざまな検索エンドポイントを持つサーバーを作成し、Elasticsearch ドキュメントをクエリする方法を説明しました。シリーズのパート 2では、本番環境のベスト プラクティスと、サーバーレス環境で Elasticsearch Node.js クライアントを実行する方法について学習します。


Elasticsearchインデックスのレプリカ数の設定方法
Kofi Bartlett — Wed, 14 May 2025 00:00:00 GMT
Elasticsearch は、大量のデータを処理し、高い可用性を提供できる分散システムとして設計されています。これを可能にする重要な機能の 1 つは、 number_of_replicas設定によって制御されるインデックス レプリケーションの概念です。この記事では、この設定の詳細、その影響、および適切な構成方法について詳しく説明します。
Elasticsearchにおけるレプリカの役割
Elasticsearch では、インデックスは複数のプライマリ シャードに分割されたドキュメントのコレクションです。各プライマリ シャードは自己完結型の Apache Lucene インデックスであり、インデックス内のドキュメントはすべてのプライマリ シャードに分散されます。高可用性とデータの冗長性を確保するために、Elasticsearch では各シャードにレプリカと呼ばれる 1 つ以上のコピーを持たせることができます。number_of_replicas設定は、Elasticsearch がインデックス内の各プライマリ シャードに対して作成するレプリカ シャード (コピー) の数を制御します。デフォルトでは、Elasticsearch はプライマリ シャードごとに 1 つのレプリカを作成しますが、これはシステムの要件に応じて変更できます。
number_of_replicas の設定
number_of_replicas設定は、インデックスの作成時に構成することも、後で更新することもできます。インデックス作成時に設定する方法は次のとおりです。PUT /my_index
{
  "settings": {
    "number_of_replicas": 2
  }
}この例では、Elasticsearch はmy_indexインデックス内のプライマリ シャードごとに 2 つのレプリカを作成します。
既存のインデックスのnumber_of_replicas設定を更新するには、 _settings API を使用できます。PUT /my_index/_settings
{
  "number_of_replicas": 3
}このコマンドは、 my_indexインデックスを更新して、プライマリ シャードごとに 3 つのレプリカを作成します。
number_of_replicas設定の影響
number_of_replicas設定は、Elasticsearchクラスターのパフォーマンスと復元力に大きな影響を与えます。考慮すべき重要なポイントは次のとおりです。
データの冗長性と可用性: number_of_replicasを増やすと、各シャードのコピーがさらに作成され、データの可用性が向上します。ノードに障害が発生した場合でも、Elasticsearch は残りのノード上のレプリカ シャードからデータを提供できます。
検索パフォーマンス:レプリカ シャードは読み取り要求を処理できるため、レプリカの数を増やすと、負荷がより多くのシャードに分散され、検索パフォーマンスが向上します。
書き込みパフォーマンス:ただし、各書き込み操作はシャードのすべてのコピーに対して実行する必要があります。したがって、 number_of_replicas大きくすると、書き込みごとに実行する必要がある操作の数が増えるため、インデックス作成のパフォーマンスが低下する可能性があります。
ストレージ要件:レプリカが増えると、ストレージ容量も増えます。追加のレプリカを保存するのに十分な容量がクラスターにあることを確認する必要があります。
ノード障害に対する耐性:クラスター内のノードの数を考慮してnumber_of_replicasを設定する必要があります。number_of_replicasがノード数以上である場合、クラスターはデータ損失なしで複数のノードの障害を許容できます。
number_of_replicas の設定に関するベストプラクティス
最適なnumber_of_replicas設定は、システムの特定の要件によって異なります。ただし、一般的なベストプラクティスをいくつか示します。
単一ノード クラスターの場合、レプリカを保持する他のノードがないため、 number_of_replicas 0 に設定する必要があります。
マルチノード クラスターの場合、データの冗長性と高可用性を確保するために、 number_of_replicas少なくとも 1 に設定する必要があります。
検索パフォーマンスを優先する場合は、 number_of_replicasを増やすことを検討してください。ただし、書き込みパフォーマンスとストレージ要件とのトレードオフに留意してください。
クラスターに追加のレプリカを保存するのに十分な容量があることを常に確認してください。


Elasticsearch のドキュメントからフィールドを削除する
Kofi Bartlett — Fri, 09 May 2025 00:00:00 GMT
Elasticsearch では、ドキュメントからフィールドを削除することが一般的な要件です。これは、インデックスから不要な情報や古い情報を削除する場合に役立ちます。この記事では、Elasticsearch 内のドキュメントからフィールドを削除するさまざまな方法を、例と手順とともに説明します。 
方法1: Update APIを使用する
Update APIを使用すると、ドキュメントのソースを変更するスクリプトを提供することでドキュメントを更新できます。このAPIを使用して、フィールドをnullに設定して、ドキュメントからフィールドを削除できます。以下はその手順のステップ別のガイドです。
1. 更新するドキュメントのインデックス、ドキュメント タイプ (Elasticsearch 6.x 以前を使用している場合)、およびドキュメント ID を特定します。
2. フィールドを null に設定するスクリプト、またはソース ドキュメントからフィールドを削除するスクリプトで Update API を使用します。次の例は、「my_index」インデックス内の ID「1」のドキュメントから「field_to_delete」フィールドを削除する方法を示しています。POST /my_index/_update/1
{
  "script": "ctx._source.remove('field_to_delete')"
}3. リクエストを実行します。成功した場合、Elasticsearch はドキュメントが更新されたことを示す応答を返します。
注: このメソッドは、指定されたドキュメントからフィールドのみを削除します。フィールドはマッピングおよびインデックス内の他のドキュメントに引き続き存在します。
方法2：変更されたソースでの再インデックス
インデックス内のすべてのドキュメントからフィールドを削除したい場合、Reindex APIを使用して、変更されたソースで新しいインデックスを作成できます。方法は以下の通りです。
1. 元のインデックスと同じ設定とマッピングを持つ新しいインデックスを作成します。Get Index API を使用して、元のインデックスの設定とマッピングを取得できます。
2. Reindex API を使用して、ソースからフィールドを削除しながら、元のインデックスから新しいインデックスにドキュメントをコピーします。次の例は、「my_index」インデックス内のすべてのドキュメントから「field_to_delete」フィールドを削除する方法を示しています。POST /_reindex
{
  "source": {
    "index": "my_index"
  },
  "dest": {
    "index": "new_index"
  },
  "script": {
    "source": "ctx._source.remove('field_to_delete')"
  }
}
3. 新しいインデックスに、フィールドが削除された正しいドキュメントが含まれていることを確認します。
4. すべてが問題なければ、元のインデックスを削除し、必要に応じて、元のインデックス名を持つエイリアスを新しいインデックスに追加できます。
方法3：マッピングの更新と再インデックス
マッピングからフィールドとインデックス内のすべてのドキュメントを削除する場合は、マッピングを更新してからドキュメントのインデックスを再作成できます。やり方は次のとおりです:
1. 元のインデックスと同じ設定で新しいインデックスを作成します。
2. Get Mapping API を使用して、元のインデックスのマッピングを取得します。
3. 削除するフィールドを削除してマッピングを変更します。
4. Put Mapping API を使用して、変更したマッピングを新しいインデックスに適用します。
5. 方法 2 の説明に従って、Reindex API を使用して、元のインデックスから新しいインデックスにドキュメントをコピーします。
6. 新しいインデックスに、フィールドが削除された正しいドキュメントが含まれていること、およびマッピングにフィールドが存在しないことを確認します。
7. 問題がなければ元のインデックスを削除し、必要に応じて元のインデックス名でエイリアスを追加できます。
まとめ
この記事では、Elasticsearch のドキュメントからフィールドを削除する 3 つの方法 (Update API の使用、変更されたソースによる再インデックス、マッピングの更新と再インデックス) について説明しました。それぞれの方法には独自の使用例とトレードオフがあるため、要件に最も適したものを選択してください。変更を本番環境に適用する前に、必ず変更をテストし、結果を確認してください。


Elasticsearchで2つのインデックスを結合する方法
Carly Richmond — Wed, 07 May 2025 00:00:00 GMT
Elasticsearch では、2 つのインデックスを結合することは、従来の SQL リレーショナル データベースほど簡単ではありません。ただし、Elasticsearch が提供する特定のテクニックと機能を使用すれば、同様の結果を得ることは可能です。
歴史的に、多くの人々は、異なるインデックスを結合するメカニズムとしてnestedフィールド タイプを使用してきました。しかし、クエリのコストが高く、Kibana、特にLensの視覚化のサポートが不完全であるため、制限がありました。
この記事では、Elasticsearch で 2 つのインデックスを結合するプロセスを詳しく説明し、次のアプローチに焦点を当てます。 
termsクエリの使用
取り込みパイプラインでenrichプロセッサを使用する
Logstash elasticsearchフィルター プラグイン
ES|QL ENRICH
ES|QL LOOKUP JOIN
用語クエリの使用
用語クエリは、Elasticsearch で 2 つのインデックスを結合する最も効果的な方法の 1 つです。このクエリは、特定のフィールドに 1 つ以上の正確な用語を含むドキュメントを取得するために使用されます。ここでは、これを使用して 2 つのインデックスを結合する方法について説明します。
まず、最初のインデックスから必要なデータを取得する必要があります。これは、単純な GET リクエストを使用して_source属性から値を取得することで実行できます。# Simple GET request
GET first_index/_search最初のインデックスからデータを取得したら、それを使用して 2 番目のインデックスをクエリできます。これは、一致させるフィールドと値を指定するtermsクエリを使用して行われます。
次に例を示します。GET second_index/_search
{
  "query": {
    "terms": {
      "field_in_second_index": ["value1_from_first_index", "value2_from_first_index"]
    }
  }
}
この例では、 field_in_second_index 、最初のインデックスの値と一致させる 2 番目のインデックスのフィールドです。value1_from_first_indexとvalue2_from_first_index 、2 番目のインデックスで一致させる最初のインデックスの値です。
用語クエリは、用語ルックアップと呼ばれる手法を使用して、上記の 2 つの手順を 1 回のショットで実行するためのサポートも提供します。Elasticsearch は、別のインデックスから一致する値を透過的に取得します。たとえば、プレーヤーのリストを含むチーム インデックスがある場合:PUT teams/_doc/team1
{
  "players":   ["john", "bill", "michael"]
}
PUT teams/_doc/team2
{
  "players":   ["aaron", "joe", "donald"]
}以下に示すように、team1 でプレイしているすべての人々の人インデックスをクエリすることができます。GET people/_search?pretty
{
  "query": {
    "terms": {
        "name" : {
            "index" : "teams",
            "id" : "team1",
            "path" : "players"
        }
    }
  }
}上記の例では、Elasticsearchはチームインデックス内のID team1 を持つドキュメントからプレーヤー名を透過的に取得します（つまり、たとえば、「john」、「bill」、「michael」など) を検索し、名前フィールドにこれらの値のいずれかを含む人物インデックス内のすべてのドキュメントを検索します。
興味がある方のために、同等の SQL クエリは次のようになります。
エンリッチプロセッサの使用
enrichプロセッサは、Elasticsearch 内の 2 つのインデックスを結合するために使用できるもう 1 つの強力なツールです。このプロセッサは、事前に定義されたエンリッチ インデックスからデータを追加することで、受信ドキュメントのデータをエンリッチします。
エンリッチ プロセッサを使用して 2 つのインデックスを結合する方法は次のとおりです。
1. まず、エンリッチポリシーを作成する必要があります。このポリシーは、エンリッチメントに使用するインデックス、一致させるフィールド、および受信ドキュメントのエンリッチメントに使用するフィールドを定義します。
次に例を示します。PUT _enrich/policy/my_enrich_policy
{
  "match": {
    "indices": "first_index",
    "match_field": "field_in_first_index",
    "enrich_fields": ["field_to_enrich"]
  }
}2. ポリシーが作成されたら、それを実行して、新しく作成されたポリシーからエンリッチ インデックスを作成する必要があります。
PUT _enrich/policy/my_enrich_policy/_executeこれにより、エンリッチメント中に使用される新しい非表示のエンリッチメント インデックスが構築されます。ソース インデックスのサイズによっては、この操作に時間がかかる場合があります。次のステップに進む前に、エンリッチポリシーが完全に構築されていることを確認してください。
3. エンリッチポリシーを構築したら、取り込みパイプラインでエンリッチプロセッサを使用して、受信ドキュメントのデータをエンリッチできます。PUT _ingest/pipeline/my_pipeline
{
  "processors": [
    {
      "enrich": {
        "policy_name": "my_enrich_policy",
        "field": "field_in_second_index",
        "target_field": "enriched_field"
      }
    }
  ]
}この例では、 field_in_second_index 、最初のインデックスのmatch_fieldと一致する必要がある 2 番目のインデックスのフィールドです。enriched_field 、最初のインデックスのenrich_fieldsから拡張されたデータを格納する、2 番目のインデックスの新しいフィールドです。
このアプローチの欠点の 1 つは、 first_indexのデータが変更された場合、エンリッチ ポリシーを再実行する必要があることです。エンリッチされたインデックスは、その構築元となったソース インデックスから自動的に更新または同期されることはありません。ただし、 first_indexが比較的安定している場合は、このアプローチはうまく機能します。
Logstash elasticsearch フィルター プラグイン
Logstash を使用する場合、上記のenrichプロセッサに似た別のオプションとして、 elasticsearchフィルター プラグインを使用して、指定されたクエリに基づいてイベントに関連フィールドを追加する方法があります。Logstash パイプラインの構成は、 my-pipeline.confなどの.confファイルに保存されます。
パイプラインがelasticsearch入力プラグインを使用して Elasticsearch からログを取得し、選択範囲を絞り込むクエリを実行しているとします。input {
  # Read all documents from Elasticsearch matching the given query
  elasticsearch {
    hosts => "localhost"
    query => '{ "query": { "match": { "statuscode": 200 } }, "sort": [ "_doc" ] }'
  }
}特定のインデックスからの情報を使用してこれらのメッセージを拡充したい場合は、 filterセクションのelasticsearchフィルター プラグインを使用してログを拡充できます。filter {
   elasticsearch {
      hosts => ["localhost"]
      index => "index_name"
      query => "type:start AND operation:%{[opid]}"
      fields => { "@timestamp" => "started" }
   }
}上記のコードは、インデックスindex_nameから、 typeが開始され、操作フィールドが指定されたopidと一致するドキュメントを検索し、 @timestampフィールドの値をstartedという名前の新しいフィールドにコピーします。
強化されたドキュメントは適切な出力ソース（この場合はelasticsearch出力プラグインを使用して Elasticsearch ）に送信されます。output {
    elasticsearch {
        hosts => "localhost"
        data_stream => "true"
    }
}すでに Logstash を使用している場合、このオプションは、エンリッチメント ロジックを 1 か所に統合し、新しいイベントが発生したときに処理するのに役立ちます。ただし、そうでない場合は、ソリューションが複雑になり、実行および保守する必要がある別のコンポーネントが追加されることになります。
ES|QL エンリッチ
バージョン 8.14 で GA となったES|QLは、Elasticsearch でサポートされるパイプ クエリ言語であり、データのフィルタリング、変換、分析を可能にします。ENRICH 処理コマンドを使用すると、エンリッチ ポリシーを使用して既存のインデックスからデータを追加できます。
元のエンリッチ プロセッサの例と同じポリシーmy_enrich_policyを使用すると、ES|QL の例は次のようになります。
一致フィールドとエンリッチメント フィールド (この例ではそれぞれfield_in_first_indexとfield_to_enrichをオーバーライドすることもできます。
明らかな制限は、最初にエンリッチポリシーを指定する必要があることですが、ES|QL では、必要に応じてフィールドを微調整できる柔軟性が提供されます。
ES|QL ルックアップ結合
Elasticsearch 8.18 では、Elasticsearch でインデックスを結合する新しい方法、つまりLOOKUP JOINコマンドが導入されました。このコマンドは、結合の右側にある新しいルックアップ インデックス モードを使用して、SQL スタイルの LEFT OUTER JOIN として動作します。
前の例をもう一度見てみると、新しいクエリは次のようになります。ここで、 match_field first_indexとsecond_index両方に存在する必要があります。
LOOKUP JOIN が他のアプローチよりも優れている点は、 enrichポリシーが不要であり、したがってポリシーの設定に関連する追加の処理も必要ないことです。これは、この記事で説明した他のアプローチとは異なり、頻繁に変更されるエンリッチメント データを扱う場合に役立ちます。
まとめ
結論として、Elasticsearch は従来の結合操作をサポートしていませんが、同様の結果を実現するために使用できるさまざまな機能を提供しています。具体的には、以下を使用して結合操作を実現する方法について説明しました。
termsクエリ
取り込みパイプラインのenrichプロセッサ
Logstash elasticsearchフィルター プラグイン
ES|QL ENRICH
ES|QL LOOKUP JOIN
これらの方法には限界があり、特定の要件とデータの性質に基づいて慎重に使用する必要があることに注意することが重要です。


Elasticsearch のスコアリングと Explain API を理解する
Kofi Bartlett — Mon, 05 May 2025 00:00:00 GMT
Elasticsearch は、インデックス内の各ドキュメントのスコアを計算して、高速かつ関連性の高い検索結果を提供する強力な検索エンジンです。このスコアは検索結果の順序を決定する上で重要な要素となります。この記事では、Elasticsearch のスコアリング メカニズムを詳しく説明し、スコアリング プロセスを理解するのに役立つ Explain API について説明します。
Elasticsearchのスコアリングメカニズム
Elasticsearch は、デフォルトで Practical Scoring Function (BM25) と呼ばれるスコアリング モデルを使用します。このモデルは確率的情報検索理論に基づいており、用語頻度、逆文書頻度、フィールド長の正規化などの要素を考慮に入れています。これらの要因について簡単に説明しましょう。
用語頻度 (TF):これは、ドキュメント内で用語が出現する回数を表します。用語の頻度が高いほど、用語とドキュメントの関係が強くなることを示します。
逆文書頻度 (IDF):この要素は、文書コレクション全体における用語の重要度を測定します。多くのドキュメントに出現する用語は重要度が低いとみなされ、より少ないドキュメントに出現する用語は重要度が高いとみなされます。
フィールド長の正規化: この要素は、用語が表示されるフィールドの長さを考慮します。短いフィールドでは用語がより重要であるとみなされるため、短いフィールドにはより大きな重みが与えられます。
Explain APIの使用
Elasticsearch の Explain API は、スコアリング プロセスを理解するための貴重なツールです。特定のドキュメントのスコアがどのように計算されたかについての詳細な説明を提供します。Explain API を使用するには、次のエンドポイントに GET リクエストを送信する必要があります。
GET //_explain/リクエスト本文には、スコアリングを理解したいクエリを指定する必要があります。次に例を示します。{
  "query": {
    "match": {
      "title": "elasticsearch"
    }
  }
}Explain API からの応答には、個々の要素 (TF、IDF、フィールド長の正規化) とそれらが最終スコアに与える影響など、スコアリング プロセスの詳細な内訳が含まれます。応答の例は次のとおりです。{
  "_index": "example_index",
  "_type": "_doc",
  "_id": "1",
  "matched": true,
  "explanation": {
    "value": 1.2,
    "description": "weight(title:elasticsearch in 0) [PerFieldSimilarity], result of:",
    "details": [
      {
        "value": 1.2,
        "description": "score(doc=0,freq=1.0 = termFreq=1.0\n), product of:",
        "details": [
          {
            "value": 2.2,
            "description": "idf, computed as log(1 + (docCount - docFreq + 0.5) / (docFreq + 0.5)) from:",
            "details": [
              {
                "value": 1,
                "description": "docFreq",
                "details": []
              },
              {
                "value": 1,
                "description": "docCount",
                "details": []
              }
            ]
          },
          {
            "value": 0.5,
            "description": "tfNorm, computed as (freq * (k1 + 1)) / (freq + k1 * (1 - b + b * fieldLength / avgFieldLength)) from:",
            "details": [
              {
                "value": 1,
                "description": "termFreq=1.0",
                "details": []
              },
              {
                "value": 1.2,
                "description": "parameter k1",
                "details": []
              },
              {
                "value": 0.75,
                "description": "parameter b",
                "details": []
              },
              {
                "value": 1,
                "description": "avgFieldLength",
                "details": []
              },
              {
                "value": 1,
                "description": "fieldLength",
                "details": []
              }
            ]
          }
        ]
      }
    ]
  }
}この例では、応答は、スコア 1.2 が IDF 値 (2.2) と tfNorm 値 (0.5) の積であることを示しています。詳細な説明は、スコアに影響を与える要因を理解するのに役立ち、検索の関連性を微調整するのに役立ちます。
まとめ
Elasticsearch スコアリングは、関連性の高い検索結果を提供する上で重要な要素です。スコアリング メカニズムを理解し、Explain API を使用することで、検索結果に影響を与える要因についての洞察を得て、検索クエリを最適化し、関連性とパフォーマンスを向上させることができます。


2つのフィールドによるElasticsearch検索
Kofi Bartlett — Wed, 30 Apr 2025 00:00:00 GMT
Elasticsearch で複数のフィールドを検索することは、多くのアプリケーションで一般的な要件です。この記事では、複数一致クエリ、ブールクエリ、クエリ時のフィールドブースティングなど、2 つのフィールドで検索を実行するための高度な手法について説明します。これらのテクニックは、ユーザーにとってより正確で関連性の高い検索結果を作成するのに役立ちます。
2つのフィールドで検索を実行する高度なテクニック
1. 複数一致クエリ
複数一致クエリを使用すると、複数のフィールドにわたって単一のクエリ文字列を検索できます。これは、2 つのフィールドのいずれかに指定されたクエリ文字列を含むドキュメントを検索する場合に便利です。以下は、「title」または「description」フィールドで「example」という用語を検索する複数一致クエリの例です。{
  "query": {
    "multi_match": {
      "query": "example",
      "fields": ["title", "description"]
    }
  }
}2. ブールクエリ
bool クエリを使用すると、ブールロジックを使用して複数のクエリを組み合わせることができます。「should」句を使用すると、2 つのフィールドのいずれかでクエリに一致するドキュメントを検索できます。以下は、フィールド「title」と「description」で「example」という用語を検索するブールクエリの例です。{
  "query": {
    "bool": {
      "should": [
        {"match": {"title": "example"}},
        {"match": {"description": "example"}}
      ]
    }
  }
}3. クエリ時のフィールドブースティング
場合によっては、検索中にあるフィールドを他のフィールドよりも重視したいことがあります。これを実現するには、クエリ時にフィールドにブースト係数を適用します。ブースト値が高いほど、フィールドの重みが増し、最終的な検索スコアに影響を与える可能性が高くなります。以下は、「タイトル」フィールドにブースト係数を適用した複数一致クエリの例です。{
  "query": {
    "multi_match": {
      "query": "example",
      "fields": ["title^3", "description"]
    }
  }
}この例では、「タイトル」フィールドのブースト係数は 3 であり、検索スコアの決定において「説明」フィールドよりも 3 倍重要になります。
4. 異なるブースト係数を持つクエリを組み合わせる
bool クエリを使用して、異なるブースト係数を持つ複数のクエリを組み合わせることもできます。これにより、検索結果の各フィールドの重要性を微調整できます。以下は、「title」フィールドと「description」フィールドに異なるブースト係数を適用したブールクエリの例です。{
  "query": {
    "bool": {
      "should": [
        {"match": {"title": {"query": "example", "boost": 3}}},
        {"match": {"description": {"query": "example", "boost": 1}}}
      ]
    }
  }
}この例では、「タイトル」フィールドのブースト係数は 3 ですが、「説明」フィールドのブースト係数は 1 です。
まとめ
Elasticsearch での 2 つのフィールドによる検索は、マルチマッチ クエリ、ブール クエリ、クエリ時フィールド ブースティングなどの高度な手法を使用して実現できます。これらの技術を組み合わせることで、ユーザーにとってより正確で関連性の高い検索結果を作成できます。さまざまなクエリの組み合わせとブースト係数を試して、特定のユースケースに最適な検索構成を見つけます。


ユースケースにBetter Binary Quantization (BBQ)を実装する方法
Sachin Frayne,Jessica Garson — Wed, 23 Apr 2025 00:00:00 GMT
ベクトル検索は、テキストのセマンティック検索や、画像、ビデオ、オーディオの類似性検索を実装する際の基盤を提供します。ベクトル検索では、ベクトルはデータの数学的表現であり、そのサイズは膨大で、場合によっては遅くなることがあります。Better Binary Quantization (以下、BBQ と呼びます) は、ベクトルの圧縮方法として機能します。これにより、ベクトルを縮小して検索と処理を高速化しながら、適切な一致を見つけることができます。この記事では、BBQ と、ベクトルを自動的に再スコアリングする量子化インデックスにのみ使用可能なフィールドである rescore_vector について説明します。
この記事で説明したすべての完全なクエリと出力は、Elasticsearch Labs コード リポジトリで確認できます。
ユースケースで Better Binary Quantization (BBQ) を実装する理由は何ですか?
注: BBQ の背後にある数学の仕組みを詳しく理解するには、以下の「さらに学ぶ」セクションをご覧ください。このブログでは、実装に重点を置いています。数学は興味深いものですが、ベクトル検索がなぜ正確であり続けるのかを完全に理解したい場合には重要です。結局のところ、現在のベクトル検索アルゴリズムではデータの読み取り速度によって制限されることが判明しているため、これはすべて圧縮に関することです。したがって、そのデータすべてをメモリに収めることができれば、ストレージから読み取る場合と比べて速度が大幅に向上します (メモリは SSD よりも約 200 倍高速です)。
いくつか留意すべき点があります:
HNSW (Hierarchical Navigable Small World) などのグラフベースのインデックスは、ベクター検索では最も高速です。
HNSW: 効率的な高次元類似性検索を可能にする多層グラフ構造を構築する近似最近傍検索アルゴリズム。
HNSW の速度は、基本的にメモリ、または最悪の場合、ストレージからのデータ読み取り速度によって制限されます。
理想的には、保存されているすべてのベクトルをメモリにロードできるようにする必要があります。
埋め込みモデルは通常、浮動小数点数ごとに 4 バイトの float32 精度のベクトルを生成します。
そして最後に、ベクトルや次元の数によっては、すべてのベクトルを保存するためのメモリがすぐに不足する可能性があります。
これを当然のこととして考えると、それぞれが数百、数千の次元を持つ可能性のある数百万、数十億のベクトルを取り込み始めると、すぐに問題が発生することがわかります。「圧縮率のおおよその数値」というセクションでは、おおよその数値が示されています。
始めるには何が必要ですか?
始めるには、次のものが必要です。
Elastic Cloud またはオンプレミスを使用している場合は、Elasticsearch のバージョン 8.18 以降が必要になります。BBQ は 8.16 で導入されましたが、この記事では 8.18 で導入されたvector_rescore使用します。
さらに、クラスター内に機械学習 (ML) ノードがあることも確認する必要があります。(注: モデルをロードするには最低 4 GB の ML ノードが必要ですが、完全な本番環境のワークロードには、はるかに大きなノードが必要になる可能性があります。)
Serverless を使用している場合は、ベクターに最適化されたインスタンスを選択する必要があります。
また、ベクター データベースに関する基本的な知識も必要になります。Elastic のベクトル検索の概念にまだ慣れていない場合は、まず次のリソースを確認することをお勧めします。
弾性ベクトルデータベースのナビゲート
検索拡張生成の背後にある大きなアイデア
より良いバイナリ量子化（BBQ）実装
このブログをシンプルに保つために、組み込み関数が利用可能な場合はそれを使用します。この場合、機械学習ノード上の Elasticsearch 内で直接実行される.multilingual-e5-smallベクトル埋め込みモデルがあります。text_embeddingモデルを、任意の埋め込みツール ( OpenAI 、 Google AI Studio 、 Cohereなど) に置き換えることができることに注意してください。希望するモデルがまだ統合されていない場合は、独自の密なベクトル埋め込みも使用できます。
まず、特定のテキストのベクトルを生成するための推論エンドポイントを作成する必要があります。これらのコマンドはすべて、Kibana Dev Tools コンソールから実行します。このコマンドは.multilingual-e5-smallをダウンロードします。まだ存在しない場合はエンドポイントが設定されます。実行には 1 分ほどかかる場合があります。予想される出力は、Outputs フォルダー内のファイル01-create-an-inference-endpoint-output.jsonで確認できます。 PUT _inference/text_embedding/my_e5_model
{
  "service": "elasticsearch",
  "service_settings": {
    "num_threads": 1,
    "model_id": ".multilingual-e5-small",
    "adaptive_allocations": {
      "enabled": true,
      "min_number_of_allocations": 1
    }
  }
}これが返されると、モデルが設定され、次のコマンドを使用してモデルが期待どおりに動作するかどうかをテストできます。期待される出力は、Outputs フォルダー内のファイル02-embed-text-output.jsonで確認できます。POST _inference/text_embedding/my_e5_model
{
  "input": "my awesome piece of text"
}トレーニング済みのモデルがどのノードにも割り当てられないという問題が発生した場合は、モデルを手動で起動する必要がある場合があります。
POST _ml/trained_models/.multilingual-e5-small/deployment/_startここで、埋め込みモデルからの出力と一致するように、標準テキスト フィールド ( my_field ) と 384 次元の密なベクトル フィールド ( my_vector ) の 2 つのプロパティを持つ新しいマッピングを作成しましょう。index_options.type to bbq_hnswもオーバーライドします。予想される出力は、Outputs フォルダー内のファイル03-create-byte-qauntized-index-output.jsonで確認できます。PUT bbq-my-byte-quantized-index
{
  "mappings": {
    "properties": {
      "my_field": {
        "type": "text"
      },
      "my_vector": {
        "type": "dense_vector",
        "dims": 384,
        "index_options": {
          "type": "bbq_hnsw"
        }
      }
    }
  }
}Elasticsearch がベクトルを生成するようにするには、 Ingest Pipelineを利用できます。このパイプラインには、エンドポイント ( model_id )、ベクトルを作成するinput_field 、およびそれらのベクトルを格納するoutput_fieldの 3 つが必要です。以下の最初のコマンドは、内部で推論サービスを使用する推論取り込みパイプラインを作成し、2 番目のコマンドはパイプラインが正しく動作していることをテストします。予想される出力は、Outputs フォルダー内のファイル04-create-and-simulate-ingest-pipeline-output.jsonで確認できます。PUT _ingest/pipeline/my_inference_pipeline
{
  "processors": [
    {
      "inference": {
        "model_id": "my_e5_model",
        "input_output": [
          {
            "input_field": "my_field",
            "output_field": "my_vector"
          }
        ]
      }
    }
  ]
}

POST _ingest/pipeline/my_inference_pipeline/_simulate
{
  "docs": [
    {
      "_source": {
        "my_field": "my awesome text field"
      }
    }
  ]
}これで、以下の最初の 2 つのコマンドを使用してドキュメントを追加し、3 番目のコマンドで検索が機能することをテストする準備が整いました。予想される出力は、Outputs フォルダー内のファイル05-bbq-index-output.jsonで確認できます。PUT bbq-my-byte-quantized-index/_doc/1?pipeline=my_inference_pipeline
{
    "my_field": "my awesome text field"
}

PUT bbq-my-byte-quantized-index/_doc/2?pipeline=my_inference_pipeline
{
    "my_field": "some other sentence"
}

GET bbq-my-byte-quantized-index/_search
{
  "query": {
    "bool": {
      "must": [
        {
          "knn": {
            "field": "my_vector",
            "query_vector_builder": {
              "text_embedding": {
                "model_id": "my_e5_model",
                "model_text": "my awesome search field"
              }
            },
            "k": 10,
            "num_candidates": 100
          }
        }
      ]
    }
  },
  "_source": [
    "my_field"
  ]
}この投稿で推奨されているように、圧縮の利点を活用しながら高い再現精度を維持するのに役立つため、大量のデータに拡張する場合は、再スコアリングとオーバーサンプリングが推奨されます。Elasticsearch バージョン 8.18 以降では、 rescore_vectorを使用してこの方法で実行できます。予想される出力は、Outputs フォルダー内のファイル06-bbq-search-8-18-output.jsonにあります。GET bbq-my-byte-quantized-index/_search
{
  "query": {
    "bool": {
      "must": [
        {
          "knn": {
            "field": "my_vector",
            "query_vector_builder": {
              "text_embedding": {
                "model_id": "my_e5_model",
                "model_text": "my awesome search field"
              }
            },
            "rescore_vector": {
              "oversample": 3
            },
            "k": 10,
            "num_candidates": 100
          }
        }
      ]
    }
  },
  "_source": [
    "my_field"
  ]
}これらのスコアは、生データで得られるスコアと比べてどうでしょうか?上記のすべてをindex_options.type: hnswを使ってもう一度実行すると、スコアが非常に似ていることがわかります。予想される出力は、Outputs フォルダーのファイル07-raw-vector-output.jsonで確認できます。PUT my-raw-vector-index
{
  "mappings": {
    "properties": {
      "my_field": {
        "type": "text"
      },
      "my_vector": {
        "type": "dense_vector",
        "dims": 384,
        "index_options": {
          "type": "hnsw"
        }
      }
    }
  }
}

PUT my-raw-vector-index/_doc/1?pipeline=my_inference_pipeline
{
    "my_field": "my awesome text field"
}

PUT my-raw-vector-index/_doc/2?pipeline=my_inference_pipeline
{
    "my_field": "some other sentence"
}

GET my-raw-vector-index/_search
{
  "query": {
    "bool": {
      "must": [
        {
          "knn": {
            "field": "my_vector",
            "query_vector_builder": {
              "text_embedding": {
                "model_id": "my_e5_model",
                "model_text": "my awesome search field"
              }
            },
            "k": 10,
            "num_candidates": 100
          }
        }
      ]
    }
  },
  "_source": [
    "my_field"
  ]
}圧縮比のおおよその数値
ベクトル検索を使用する場合、ストレージとメモリの要件がすぐに大きな課題になる可能性があります。次の内訳は、さまざまな量子化手法によってベクター データのメモリ フットプリントがいかに劇的に削減されるかを示しています。
ベクトル（V）
寸法（D）
生（V x D x 4）
int8 (V x (D x 1 + 4))
int4 (V x (D x 0.5 + 4))
バーベキュー（V×（D×0.125+4））
10,000,000
384
14.31GB
3.61GB
1.83GB
0.58GB
50,000,000
384
71.53GB
18.07GB
9.13GB
2.89GB
1億
384
143.05GB
36.14GB
18.25GB
5.77GB
まとめ
BBQ は、精度を犠牲にすることなくベクター データを圧縮するために適用できる最適化です。これはベクトルをビットに変換することで機能し、データを効果的に検索できるようにし、AI ワークフローを拡張して検索を高速化し、データ ストレージを最適化できるようにします。
さらなる学習
バーベキューについてさらに詳しく知りたい場合は、次のリソースをぜひチェックしてください。
LuceneとElasticsearchにおけるバイナリ量子化（BBQ）
より良いバイナリ量子化（BBQ）と積量子化
最適化されたスカラー量子化：さらに優れたバイナリ量子化
より良いバイナリ量子化（BBQ）：バイトからBBQへ、より良いベクトル検索の秘密 by Ben Trent


Elasticsearch ヒープサイズの使用量と JVM ガベージコレクション
Kofi Bartlett — Tue, 22 Apr 2025 00:00:00 GMT
ヒープ サイズは、Elasticsearch ノードの Java 仮想マシンに割り当てられる RAM の量です。
バージョン 7.11 以降、Elasticsearch はデフォルトで、ノードのロールと合計メモリに基づいて JVM ヒープ サイズを自動的に設定します。ほとんどの運用環境では、デフォルトのサイズ設定を使用することをお勧めします。ただし、JVM ヒープ サイズを手動で設定する場合は、一般的なルールとして、-Xms と -Xmx を同じ値に設定する必要があります。これは、使用可能な RAM の合計の 50% で、最大 (約) 31 GB になります。
ヒープ サイズを大きくすると、インデックス作成と検索操作に使用できるメモリがノードに多く割り当てられます。ただし、ノードにはキャッシュ用のメモリも必要なので、50% を使用すると 2 つのメモリのバランスが適切に保たれます。同じ理由から、本番環境では、Elasticsearch と同じノードで他のメモリを大量に消費するプロセスを使用することは避けてください。
通常、ヒープ使用量は鋸歯状のパターンに従い、使用されている最大ヒープの約 30 ～ 70% の間を変動します。これは、ガベージ コレクション プロセスによってメモリが再び解放されるまで、JVM がヒープ使用率を着実に増加させるためです。ガベージ コレクション プロセスが追いつかない場合、ヒープ使用率が高くなります。ヒープ使用量が高いことを示す指標は、ガベージ コレクションでヒープ使用量を約 30% まで削減できない場合です。
上の画像では、JVM ヒープの通常のノコギリ波を見ることができます。
また、ガベージ コレクションには、若い GC と古い GC の 2 種類があることもわかります。
正常な JVM では、ガベージ コレクションは理想的には次の条件を満たす必要があります。
Young GC は迅速に処理されます (50 ミリ秒以内)。
Young GC は頻繁に実行されません (約 10 秒)。
古い GC はすぐに処理されます (1 秒以内)。
古い GC は頻繁に実行されません (10 分に 1 回以上)。
ヒープメモリ使用量が高すぎる場合やJVMパフォーマンスが最適でない場合の解決方法
ヒープ メモリの使用量が増える理由はさまざまです。
オーバーシャーディング
オーバーシャーディングに関するドキュメントはここを参照してください。
大規模な集約サイズ
集約サイズが大きくなるのを避けるには、クエリ内の集約バケットの数 (サイズ) を最小限に抑えます。GET /_search
{
   "aggs" : {
       "products" : {
           "terms" : {
               "field" : "product",
               "size" : 5
                          }
       }
   }
}低速クエリ ログ (スロー ログ) を使用し、次のように特定のインデックスに実装することができます。PUT /my_index/_settings
{
   "index.search.slowlog.threshold.query.warn": "10s",
   "index.search.slowlog.threshold.query.info": "5s",
   "index.search.slowlog.threshold.query.debug": "2s",
   "index.search.slowlog.threshold.query.trace": "500ms",
   "index.search.slowlog.threshold.fetch.warn": "1s",
   "index.search.slowlog.threshold.fetch.info": "800ms",
   "index.search.slowlog.threshold.fetch.debug": "500ms",
   "index.search.slowlog.threshold.fetch.trace": "200ms",
   "index.search.slowlog.level": "info"
}結果を返すのに長い時間がかかるクエリは、リソースを大量に消費するクエリである可能性が高くなります。
バルクインデックスのサイズが大きすぎる
大きなリクエストを送信する場合、ヒープ消費量が多くなる原因となる可能性があります。一括インデックス要求のサイズを小さくしてみてください。
マッピングの問題
特に、「fielddata: true」を使用する場合、これが JVM ヒープの主要なユーザーになる可能性があります。
ヒープサイズが正しく設定されていません
ヒープ サイズは次のように手動で定義できます。
環境変数の設定:
ES_JAVA_OPTS="-Xms2g -Xmx2g"Elasticsearch 構成ディレクトリ内の jvm.options ファイルを編集します。-Xms2g
-Xmx2g環境変数の設定はファイルの設定よりも優先されます。
設定を有効にするにはノードを再起動する必要があります。
JVM の新しい比率が正しく設定されていません
Elasticsearch はデフォルトでこの値を設定するため、通常はこれを設定する必要はありません。このパラメータは、JVM 内の「新世代」オブジェクトと「旧世代」オブジェクトに使用可能なスペースの比率を定義します。
古い GC が非常に頻繁に発生していることがわかった場合は、Elasticsearch 構成ディレクトリの jvm.options ファイルでこの値を具体的に設定してみてください。
-XX:NewRatio=3大規模な Elasticsearch クラスターでヒープサイズの使用量と JVM ガベージコレクションを管理するためのベストプラクティスは何ですか?
大規模な Elasticsearch クラスターでヒープ サイズの使用量と JVM ガベージ コレクションを管理するためのベスト プラクティスは、ヒープ サイズが使用可能な RAM の最大 50% に設定され、JVM ガベージ コレクション設定が特定のユース ケースに合わせて最適化されていることを確認することです。クラスターが最適に実行されていることを確認するには、ヒープ サイズとガベージ コレクション メトリックを監視することが重要です。具体的には、JVM ヒープ サイズ、ガベージ コレクション時間、ガベージ コレクションの一時停止を監視することが重要です。さらに、ガベージ コレクション サイクルの数とガベージ コレクションに費やされた時間を監視することも重要です。これらのメトリックを監視することで、ヒープ サイズやガベージ コレクションの設定に関する潜在的な問題を特定し、必要に応じて修正措置を講じることができます。


Elasticsearchでプライマリシャード数を増やす方法
Kofi Bartlett — Thu, 17 Apr 2025 00:00:00 GMT
既存のインデックスのプライマリ シャード数を増やすことはできません。つまり、プライマリ シャード数を増やす場合は、インデックスを再作成する必要があります。このような状況で一般的に使用される方法は 2 つあります。_reindex API と _split API です。
_split API は、多くの場合、_reindex API よりも高速な方法です。両方の操作の前にインデックス作成を停止する必要があります。そうしないと、source_index と target_index のドキュメント数が異なります。
方法1 – 分割APIを使用する
分割 API は、設定をコピーし、既存のインデックスをマッピングすることで、必要な数のプライマリ シャードを持つ新しいインデックスを作成するために使用されます。作成時に必要なプライマリ シャードの数を設定できます。分割 API を実装する前に、次の設定を確認する必要があります。
ソース インデックスは読み取り専用である必要があります。これは、インデックス作成プロセスを停止する必要があることを意味します。
ターゲット インデックス内のプライマリ シャードの数は、ソース インデックス内のプライマリ シャードの数の倍数である必要があります。たとえば、ソース インデックスに 5 つのプライマリ シャードがある場合、ターゲット インデックスのプライマリ シャードを 10、15、20 などに設定できます。
注: プライマリ シャード番号のみを変更する必要がある場合は、再インデックス API よりもはるかに高速な分割 API が推奨されます。
分割APIの実装
テストインデックスを作成します。POST test_split_source/_doc
{
  "test": "test"
}分割するには、ソース インデックスが読み取り専用である必要があります。PUT test_split_source/_settings
{
  "index.blocks.write": true
}設定とマッピングはソース インデックスから自動的にコピーされます。POST /test_split_source/_split/test_split_target
{
  "settings": {
    "index.number_of_shards": 3
  }
}進捗状況は以下で確認できます:
GET _cat/recovery/test_split_target?v&h=index,shard,time,stage,files_percent,files_total設定とマッピングはソース インデックスからコピーされるため、ターゲット インデックスは読み取り専用になります。ターゲット インデックスへの書き込み操作を有効にしましょう。PUT test_split_target/_settings
{
    "index.blocks.write": null
}元のインデックスを削除する前に、ソース インデックスとターゲット インデックスの docs.count を確認します。
GET _cat/indices/test_split*?v&h=index,pri,rep,docs.countインデックス名とエイリアス名を同じにすることはできません。ソース インデックスを削除し、ソース インデックス名をターゲット インデックスのエイリアスとして追加する必要があります。DELETE test_split_source
PUT /test_split_target/_alias/test_split_sourcetest_split_sourceエイリアスをtest_split_targetインデックスに追加した後、次のようにテストする必要があります。GET test_split_source
POST test_split_source/_doc
{
  "test": "test"
}方法2 – 再インデックスAPIを使用する
Reindex API を使用して新しいインデックスを作成すると、任意の数のプライマリ シャード カウントを指定できます。意図した数のプライマリ シャードで新しいインデックスを作成した後、ソース インデックス内のすべてのデータをこの新しいインデックスに再インデックスできます。
分割 API 機能に加えて、再インデックス AP の ingest_pipeline を使用してデータを操作することもできます。取り込みパイプラインでは、フィルターに適合する指定されたフィールドのみがクエリを使用してターゲット インデックスにインデックス付けされます。データの内容は簡単なスクリプトを使用して変更でき、複数のインデックスを 1 つのインデックスにマージできます。
再インデックスAPIの実装
テストの再インデックスを作成します。POST test_reindex_source/_doc
{
    "test": "test"
}ソース インデックスから設定とマッピングをコピーします。
GET test_reindex_source設定、マッピング、および必要なシャード数を使用してターゲット インデックスを作成します。PUT test_reindex_target
{
  "mappings" : {},
  "settings": {
    "number_of_shards": 10,
    "number_of_replicas": 0,
    "refresh_interval": -1
  }
}*注: number_of_replicas: 0 および refresh_interval: -1 を設定すると、再インデックスの速度が向上します。
再インデックスプロセスを開始します。requests_per_second=-1 および slices=auto を設定すると、再インデックス速度が調整されます。POST _reindex?requests_per_second=-1&slices=auto&wait_for_completion=false
{
  "source": {
    "index": "test_reindex_source"
  },
  "dest": {
    "index": "test_reindex_target"
  }
}再インデックス API を実行すると、task_id が表示されます。それをコピーして、_tasks API で確認します。
GET _tasks/再インデックスが完了したら設定を更新します。PUT test_reindex_target/_settings
{
  "number_of_replicas": 1,
  "refresh_interval": "1s"
}元のインデックスを削除する前に、ソース インデックスとターゲット インデックスの docs.count が同じであることを確認します。
GET _cat/indices/test_reindex_*?v&h=index,pri,rep,docs.countインデックス名とエイリアス名を同じにすることはできません。ソース インデックスを削除し、ソース インデックス名をターゲット インデックスのエイリアスとして追加します。DELETE test_reindex_source
PUT /test_reindex_target/_alias/test_reindex_sourcetest_split_source エイリアスを test_split_target インデックスに追加した後、次のコマンドを使用してテストします。
GET test_reindex_sourceまとめ
既存のインデックスのプライマリ シャード数を増やす場合は、新しいインデックスへの設定とマッピングを再作成する必要があります。これを行うには、主に reindex API と split API という 2 つの方法があります。どちらの方法を使用する前にも、アクティブなインデックス作成を停止する必要があります。


Elasticsearch の異なるバージョン間およびクラスター間でデータを移行する方法
Kofi Bartlett — Mon, 14 Apr 2025 00:00:00 GMT
Elasticsearch クラスターをアップグレードする場合、新しい別のクラスターを作成し、古いクラスターから新しいクラスターにデータを転送する方が簡単な場合があります。これにより、ユーザーは、ダウンタイムやデータ損失のリスクなしに、すべてのアプリケーションを使用して新しいクラスター上のすべてのデータと構成をテストできるという利点が得られます。
このアプローチの欠点は、ハードウェアの重複が必要となり、すべてのデータをスムーズに転送および同期する際に困難が生じる可能性があることです。
アプリケーションをあるデータ センターから別のデータ センターに移行する必要がある場合にも、同様の手順を実行する必要がある場合があります。
この記事では、Elasticsearch クラスター間でデータを転送する 3 つの方法について詳しく説明します。
Elasticsearch クラスター間でデータを移行するにはどうすればよいですか?
Elasticsearch クラスター間でデータを転送する方法は 3 つあります。
リモートクラスタからの再インデックス
スナップショットを使用したデータ転送
Logstash を使用したデータ転送
通常、スナップショットを使用するのが、データを転送する最も高速かつ信頼性の高い方法です。ただし、スナップショットは同等以上のバージョンのクラスターにのみ復元でき、メジャー バージョンが 1 つ以上異なるクラスターには復元できないことに注意してください。つまり、6.x スナップショットを 7.x クラスターに復元することはできますが、8.x クラスターには復元できません。
メジャー バージョンを 1 つ以上増やす必要がある場合は、インデックスを再作成するか、Logstash を使用する必要があります。
ここで、Elasticsearch クラスター間でデータを転送するための 3 つのオプションをそれぞれ詳しく見ていきましょう。
1. リモートクラスタからのデータの再インデックス
再インデックスを開始する前に、新しいクラスター上のすべてのインデックスに対して適切なマッピングを設定する必要があることに注意してください。そのためには、適切なマッピングを使用してインデックスを直接作成するか、インデックス テンプレートを使用する必要があります。
リモートからの再インデックス - 設定が必要
リモートから再インデックスを行うには、データを受信しているクラスターの elasticseearch.yml ファイルに以下の構成を追加する必要があります。Linux システムでは、このファイルは、通常、/etc/elasticsearch/elasticsearch.yml にあります。追加する構成は次のとおりです。
reindex.remote.whitelist: "192.168.1.11:9200"SSL を使用している場合は、各ノードに CA 証明書を追加し、elasticsearch.yml 内の各ノードのコマンドに以下を含める必要があります。
reindex.ssl.certificate_authorities: “/path/to/ca.pem”あるいは、SSL 検証を無効にするために、すべての Elasticsearch ノードに以下の行を追加することもできます。ただし、このアプローチは前のオプションほど安全ではないため、あまりお勧めできません。reindex.remote.whitelist: "192.168.1.11:9200"
reindex.ssl.verification_mode: none
systemctl restart elasticsearch service すべてのノードでこれらの変更を行い、ローリング再起動を実行する必要があります。その方法の詳細については、ガイドをご覧ください。
再インデックスコマンド
elasticsearch.yml ファイルでリモート ホストを定義し、必要に応じて SSL 証明書を追加したら、以下のコマンドでデータの再インデックスを開始できます。POST _reindex
{
  "source": {
    "remote": {
      "host": "http://192.168.1.11:9200",
      "username": "elastic",
      "password": "123456",
     "socket_timeout": "1m",
      "connect_timeout": "1m"

    },
    "index": "companydatabase"
  },
  "dest": {
    "index": "my-new-index-000001"
  }
}その際、タイムアウト エラーが発生する可能性があるため、デフォルトに頼るのではなく、タイムアウトに余裕を持った値を設定すると便利な場合があります。
ここで、リモートから再インデックスするときに発生する可能性のあるその他の一般的なエラーを見てみましょう。
リモートからの再インデックス時によくあるエラー
1. 再インデックスがホワイトリストに登録されていない{
  "error": {
    "root_cause": [
      {
        "type": "illegal_argument_exception",
        "reason": "[192.168.1.11:9200] not whitelisted in reindex.remote.whitelist"
      }
    ],
    "type": "illegal_argument_exception",
    "reason": "[192.168.1.11:9200] not whitelisted in reindex.remote.whitelist"
  },
  "status": 400
}このエラーが発生した場合は、上記のように Elasticsearch でリモート ホストの IP アドレスまたはノード名 DNS を定義しなかったか、Elasticsearch サービスの再起動を忘れたことを示しています。
Elasticsearch クラスターでこの問題を修正するには、リモート ホストをすべての Elasticsearch ノードに追加し、Elasticsearch サービスを再起動する必要があります。
2. SSLハンドシェイク例外{
  "error": {
    "root_cause": [
      {
        "type": "s_s_l_handshake_exception",
        "reason": "PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target"
      }
    ],
    "type": "s_s_l_handshake_exception",
    "reason": "PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target",
    "caused_by": {
      "type": "validator_exception",
      "reason": "PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target",
      "caused_by": {
        "type": "sun_cert_path_builder_exception",
        "reason": "unable to find valid certification path to requested target"
      }
    }
  },
  "status": 500
}このエラーは、上記のように elasticsearch.yml に reindex.ssl.certificate_authorities を追加するのを忘れたことを意味します。追加するには:#elasticsearch.yml
reindex.ssl.certificate_authorities: "/path/to/ca.pem"2. スナップショットを使用したデータ転送
前述のように、スナップショットは同等以上のバージョンのクラスタにのみ復元でき、1つ以上のメジャーバージョンの違いがあるクラスタには復元できないことに注意してください。
メジャー バージョンを 1 つ以上増やす必要がある場合は、インデックスを再作成するか、Logstash を使用する必要があります。
スナップショットを介してデータを転送するには、次の手順が必要です。
ステップ 1. 最初の Elasticsearch クラスターにリポジトリ プラグインを追加する – スナップショットを介してクラスター間でデータを転送するには、新しいクラスターと古いクラスターの両方からリポジトリにアクセスできることを確認する必要があります。通常、AWS、Google、Azure などのクラウド ストレージ リポジトリがこれに最適です。スナップショットを撮るには、ガイドを参照して、そこに記載されている手順に従ってください。
ステップ 2. Elasticsearch サービスを再起動します (ローリング再起動)。
ステップ 3. 最初の Elasticsearch クラスターのリポジトリを作成します。
ステップ 4 - リポジトリ プラグインを 2 番目の Elasticsearch クラスターに追加します。
ステップ 5 - リポジトリを 2 番目の Elasticsearch クラスターに読み取り専用として追加する - 最初の Elasticsearch クラスターを作成するときに実行したのと同じ手順を繰り返して、リポジトリを追加する必要があります。
重要な注意: 2 番目の Elasticsearch クラスターを同じ AWS S3 リポジトリに接続する場合は、リポジトリを読み取り専用リポジトリとして定義する必要があります。PUT _snapshot/my_s3_repository
{
  "type": "s3",
  "settings": {
    "bucket": "my-analytic-data",
    "endpoint": "s3.eu-de.cloud-object-storage.appdomain.cloud",
    "readonly": "true"
  }
}これは、同じスナップショットリポジトリ内で Elasticsearch のバージョンが混在するリスクを回避するために重要です。
ステップ 6 - 2 番目の Elasticsearch クラスターへのデータの復元 - 上記の手順を実行した後、データを復元して新しいクラスターに転送できます。新しいクラスターにデータを復元するには、この記事に記載されている手順に従ってください。
3. Logstash を使用したデータ転送
logstash を使用してデータの転送を開始する前に、新しいクラスター上のすべてのインデックスに対して適切なマッピングを設定する必要があることに注意してください。そのためには、インデックスを直接作成するか、インデックス テンプレートを使用する必要があります。
2 つの Elasticsearch クラスター間でデータを転送するには、一時的な Logstash サーバーをセットアップし、それを使用して 2 つのクラスター間でデータを転送できます。小規模なクラスターの場合、2GB の RAM インスタンスで十分です。より大規模なクラスターの場合は、8GB の RAM を搭載した 4 コア CPU を使用できます。
Logstash のインストールに関するガイダンスについては、こちらをご覧ください。
あるクラスターから別のクラスターにデータを転送するための Logstash 構成
クラスター A からクラスター B に単一のインデックスをコピーするための基本構成は次のとおりです。iinput
{
elasticsearch
      {
        hosts => ["192.168.1.11:9200"]
        index => "index_name"
       docinfo => true      
      }
}

output 
{
  elasticsearch {
        hosts => "https://192.168.1.12:9200"
        index => "index_name"
        
  }
}セキュアな elasticsearch の場合は、以下の構成を使用できます。input
{
  elasticsearch
      {
        hosts => ["192.168.1.11:9200"]
        index => "index_name"
        docinfo => true 
        user => "elastic"
        password => "elastic_password"
        ssl => true
        ssl_certificate_verification => false
            
      }
}

output 
{
  elasticsearch {
        hosts => "https://192.168.1.12:9200"
        index => "index_name"
        user => "elastic"
        password => "elastic_password"
        ssl => true
        ssl_certificate_verification => false
  }
}インデックスメタデータ
上記のコマンドは、単一の名前付きインデックスに書き込みます。複数のインデックスを転送し、インデックス名を保持する場合は、Logstash 出力に次の行を追加する必要があります。
index => "%{[@metadata][_index]}"また、ドキュメントの元の ID を保持したい場合は、以下を追加する必要があります。
document_id => "%{[@metadata][_id]}"ドキュメント ID を設定するとデータ転送速度が大幅に低下することに注意してください。必要な場合にのみ元の ID を保持してください。
更新の同期
上記の方法はすべて比較的長い時間がかかり、プロセスが完了するまでに元のクラスターのデータが更新されている場合があります。
データ転送プロセス中に発生した可能性のある更新を同期できるようにするにはさまざまな戦略があり、そのプロセスを開始する前にこれらの問題について検討する必要があります。特に、次の点を考慮する必要があります。
データ転送プロセスの開始以降に更新/追加されたデータを識別する方法は何ですか (例: データ内の「last_update_time」フィールド)?
最後のデータを転送するにはどのような方法を使用できますか?
記録が重複するリスクはありますか?通常は、使用している方法によって再インデックス中にドキュメント ID が既知の値に設定されない限り、存在します。
更新の同期を有効にするさまざまな方法について以下に説明します。
1. 待ち行列システムの使用
一部の取り込み/更新システムでは、過去 x 日間に受信したデータの変更を「再生」できるキューを使用します。これにより、実行された変更を同期する手段が提供される場合があります。 
2. リモートから再インデックス
「last_update_time」が x 日前を超えるすべてのアイテムに対して、再インデックス処理を繰り返します。これを行うには、再インデックス リクエストに「クエリ」パラメータを追加します。
3. ログスタッシュ
Logstash 入力では、「last_update_time」が x 日前を超えるすべての項目をフィルターするクエリを追加できます。ただし、document_id を設定していない限り、このプロセスでは非時系列データに重複が発生します。
4. スナップショット
インデックスの一部だけを復元することはできないため、データ転送プロセスの実行以降に行われた変更を更新するには、上で説明した他のデータ転送方法のいずれか (またはスクリプト) を使用する必要があります。
ただし、スナップショットの復元は再インデックス/Logstash よりもはるかに高速なプロセスであるため、スナップショットの転送中に更新を短時間一時停止して、問題を完全に回避できる可能性があります。


同義語APIを使用して同義語を自動化し、アップロードする方法
Andre Luiz — Thu, 27 Mar 2025 00:00:00 GMT
効率的なユーザー エクスペリエンスを提供するには、検索結果の品質を向上させることが不可欠です。検索を最適化する 1 つの方法は、同義語を通じて検索対象の用語を自動的に拡張することです。これにより、クエリをより広範囲に解釈できるようになり、言語のバリエーションをカバーして結果の一致が向上します。
このブログでは、大規模言語モデル (LLM) を使用して同義語を自動的に識別および生成し、これらの用語をプログラムで Elasticsearch の同義語 API に読み込むことができる方法について説明します。
同義語はいつ使用すればよいですか?
同義語を使用すると、ベクトル検索に比べて高速かつコスト効率の高いソリューションになります。埋め込みに関する深い知識や複雑なベクトル取り込みプロセスを必要としないため、実装はより簡単です。
さらに、ベクトル検索ではインデックス作成と検索を埋め込むために大きなストレージ容量とメモリが必要になるため、リソースの消費量が少なくなります。
もう一つの重要な側面は、検索の地域化です。同義語を使用すると、現地の言語や習慣に応じて用語を適応させることができます。これは、埋め込みが地域的な表現や国固有の用語と一致しない可能性がある場合に役立ちます。たとえば、一部の単語や頭字語は地域によって意味が異なる場合がありますが、現地のユーザーにとっては当然同義語として扱われます。ブラジルでは、これはかなり一般的です。「アバカシ」と「アナナス」は同じ果物（パイナップル）ですが、北東部の一部の地域では後者の用語の方が一般的に使用されています。同様に、南東部でよく知られている「pão francês」は、北東部では「pão careca」として知られている場合があります。
LLM を使用して同義語を生成するにはどうすればよいでしょうか?
同義語を自動的に取得するには、用語のコンテキストを分析して適切なバリエーションを提案する LLM を使用できます。このアプローチにより、同義語を動的に拡張できるため、固定辞書に依存せずに、より広範で正確な検索が可能になります。
このデモでは、LLM を使用して電子商取引製品の同義語を生成します。多くの検索では、検索語句のバリエーションにより、結果がほとんど返されないか、まったく返されません。同義語を使用すると、この問題は解決できます。たとえば、「スマートフォン」を検索すると、さまざまな種類の携帯電話が検索されるため、ユーザーは探している製品を見つけることができます。
要件
始める前に、環境を設定し、必要な依存関係を定義する必要があります。Elastic が提供するソリューションを使用して、 Elasticsearch と Kibana を Docker でローカルに実行します。コードは Python v3.9.6 で記述され、次の依存関係があります。
pip install openai==1.59.8 elasticsearch==8.15.1製品インデックスの作成
最初は、同義語をサポートしない製品のインデックスを作成します。これにより、クエリを検証し、同義語を含むインデックスと比較できるようになります。
インデックスを作成するには、Kibana DevTools で次のコマンドを使用して製品データセットを一括ロードします。POST _bulk
{"index": {"_index": "products", "_id": 10001}}
{"category": "Electronics", "name": "iPhone 14 Pro"}
{"index": {"_index": "products", "_id": 10007}}
{"category": "Electronics", "name": "MacBook Pro 16-inch"}
{"index": {"_index": "products", "_id": 10013}}
{"category": "Electronics", "name": "Samsung Galaxy Tab S8"}
{"index": {"_index": "products", "_id": 10037}}
{"category": "Electronics", "name": "Apple Watch Series 8"}
{"index": {"_index": "products", "_id": 10049}}
{"category": "Electronics", "name": "Kindle Paperwhite"}
{"index": {"_index": "products", "_id": 10067}}
{"category": "Electronics", "name": "Samsung QLED 4K TV"}
{"index": {"_index": "products", "_id": 10073}}
{"category": "Electronics", "name": "HP Spectre x360 Laptop"}
{"index": {"_index": "products", "_id": 10079}}
{"category": "Electronics", "name": "Apple AirPods Pro"}
{"index": {"_index": "products", "_id": 10115}}
{"category": "Electronics", "name": "Amazon Echo Show 10"}
{"index": {"_index": "products", "_id": 10121}}
{"category": "Electronics", "name": "Apple iPad Air"}
{"index": {"_index": "products", "_id": 10127}}
{"category": "Electronics", "name": "Apple AirPods Max"}
{"index": {"_index": "products", "_id": 10151}}
{"category": "Electronics", "name": "Sony WH-1000XM4 Headphones"}
{"index": {"_index": "products", "_id": 10157}}
{"category": "Electronics", "name": "Google Pixel 6 Pro"}
{"index": {"_index": "products", "_id": 10163}}
{"category": "Electronics", "name": "Apple MacBook Air"}
{"index": {"_index": "products", "_id": 10181}}
{"category": "Electronics", "name": "Google Pixelbook Go"}
{"index": {"_index": "products", "_id": 10187}}
{"category": "Electronics", "name": "Sonos Beam Soundbar"}
{"index": {"_index": "products", "_id": 10199}}
{"category": "Electronics", "name": "Apple TV 4K"}
{"index": {"_index": "products", "_id": 10205}}
{"category": "Electronics", "name": "Samsung Galaxy Watch 4"}
{"index": {"_index": "products", "_id": 10211}}
{"category": "Electronics", "name": "Apple MacBook Pro 16-inch"}
{"index": {"_index": "products", "_id": 10223}}
{"category": "Electronics", "name": "Amazon Echo Dot (4th Gen)"}LLMによる同義語の生成
このステップでは、LLM を使用して同義語を動的に生成します。これを実現するために、OpenAI API を統合し、適切なモデルとプロンプトを定義します。LLM は製品のカテゴリと名前を受け取り、同義語が文脈的に適切であることを確認します。import json
import logging

from openai import OpenAI

def call_gpt(prompt, model):
    try:
        logging.info("generate synonyms by llm...")
        response = client.chat.completions.create(
            model=model,
            messages=[{"role": "user", "content": prompt}],
            temperature=0.7,
            max_tokens=1000
        )
        content = response.choices[0].message.content.strip()
        return content
    except Exception as e:
        logging.error(f"Failed to use model: {e}")
        return None

def generate_synonyms(category, products):
   synonyms = {}

   for product in products:
       prompt = f"You are an expert in generating synonyms for products. Based on the category and product name provided, generate synonyms or related terms. Follow these rules:\n"
       prompt += "1. **Format**: The first word should be the main item (part of the product name, excluding the brand), followed by up to 3 synonyms separated by commas.\n"
       prompt += "2. **Exclude the brand**: Do not include the brand name in the synonyms.\n"
       prompt += "3. **Maximum synonyms**: Generate a maximum of 3 synonyms per product.\n\n"
       prompt += f"The category is: **{category}**, and the product is: **{product}**. Return only the synonyms in the requested format, without additional explanations."

       response = call_gpt(prompt, "gpt-4o")
       synonyms[product] = response

   return synonyms作成された製品インデックスから、「エレクトロニクス」カテゴリ内のすべてのアイテムを取得し、その名前を LLM に送信します。予想される出力は次のようになります。{
  "iPhone 14 Pro": ["iPhone", "smartphone", "mobile", "handset"],
  "MacBook Pro 16-inch": ["MacBook", "Laptop", "Notebook", "Ultrabook"],
  "Samsung Galaxy Tab S8": ["Tab", "Tablet", "Slate", "Pad"],
  "Bose QuietComfort 35 Headphones": ["Headphones", "earphones", "earbuds", "headset"]
}生成された同義語は、Synonyms API を使用して Elasticsearch に登録できます。
Synonyms API による同義語の管理
シノニム API は、システム内でシノニム セットを直接管理する効率的な方法を提供します。各同義語セットは同義語ルールで構成され、検索では単語のグループが同等として扱われます。
同義語セットの作成例PUT _synonyms/my-synonyms-set
{
  "synonyms_set": [
    {
      "id": "rule-1",
      "synonyms": "hello, hi"
    },
    {
      "synonyms": "bye, goodbye"
    }
  ]
}
これにより、「my-synonyms-set」というセットが作成され、そこでは「hello」と「hi」が「bye」と「goodbye」と同様に同等として扱われます。
製品カタログの同義語作成の実装
以下は、同義語セットを構築して Elasticsearch に挿入するメソッドです。同義語ルールは、LLM によって提案された同義語のマッピングに基づいて生成されます。各ルールには、スラッグ形式の製品名に対応する ID と、LLM によって計算された同義語のリストがあります。import json
import logging

from elasticsearch import Elasticsearch
from slugify import slugify

es = Elasticsearch(
    "http://localhost:9200",
    api_key="your_api_key"
)

def mount_synonyms(results):
   synonyms_set = [{"id": slugify(product), "synonyms": synonyms} for product, synonyms in
                   results.items()]

   try:
       response = es.synonyms.put_synonym(id="products-synonyms-set",
                                                 synonyms_set=synonyms_set)

       logging.info(json.dumps(response.body, indent=4))
       return response.body
   except Exception as e:
       logging.error(f"Error create synonyms: {str(e)}")
       return None以下は、同義語セットを作成するためのリクエスト ペイロードです。{
   "synonyms_set":[
      {
         "id": "iphone-14-pro",
         "synonyms": "iPhone, smartphone, mobile, handset"
      },
      {
         "id": "macbook-pro-16-inch",
         "synonyms": "MacBook, Laptop, Notebook, Computer"
      },
      {
         "id": "samsung-galaxy-tab-s8",
         "synonyms": "Tablet, Slate, Pad, Device"
      },
      {
         "id": "garmin-forerunner-945",
         "synonyms": "Forerunner, smartwatch, fitness watch, GPS watch"
      },
      {
         "id": "bose-quietcomfort-35-headphones",
         "synonyms": "Headphones, Earphones, Headset, Cans"
      }
   ]
}クラスターにシノニム セットが作成されたら、次のステップに進み、定義したセットを使用してシノニムをサポートする新しいインデックスを作成します。
LLM によって生成された同義語と、Synonyms API によって定義された同義語セットの作成を含む完全な Python コードは次のとおりです。import json
import logging

from elasticsearch import Elasticsearch
from openai import OpenAI
from slugify import slugify

logging.basicConfig(level=logging.INFO)

client = OpenAI(
   api_key="your-key",
)

es = Elasticsearch(
    "http://localhost:9200",
    api_key="your_api_key"
)


def call_gpt(prompt, model):
   try:
       logging.info("generate synonyms by llm...")
       response = client.chat.completions.create(
           model=model,
           messages=[{"role": "user", "content": prompt}],
           temperature=0.7,
           max_tokens=1000
       )
       content = response.choices[0].message.content.strip()
       return content
   except Exception as e:
       logging.error(f"Failed to use model: {e}")
       return None


def generate_synonyms(category, products):
   synonyms = {}

   for product in products:
       prompt = f"You are an expert in generating synonyms for products. Based on the category and product name provided, generate synonyms or related terms. Follow these rules:\n"
       prompt += "1. **Format**: The first word should be the main item (part of the product name, excluding the brand), followed by up to 3 synonyms separated by commas.\n"
       prompt += "2. **Exclude the brand**: Do not include the brand name in the synonyms.\n"
       prompt += "3. **Maximum synonyms**: Generate a maximum of 3 synonyms per product.\n\n"
       prompt += f"The category is: **{category}**, and the product is: **{product}**. Return only the synonyms in the requested format, without additional explanations."

       response = call_gpt(prompt, "gpt-4o")
       synonyms[product] = response

   return synonyms


def get_products(category):
   query = {
       "size": 50,
       "_source": ["name"],
       "query": {
           "bool": {
               "filter": [
                   {
                       "term": {
                           "category.keyword": category
                       }
                   }
               ]
           }
       }
   }
   response = es.search(index="products", body=query)

   if response["hits"]["total"]["value"] > 0:
       product_names = [hit["_source"]["name"] for hit in response["hits"]["hits"]]
       return product_names
   else:
       return []


def mount_synonyms(results):
   synonyms_set = [{"id": slugify(product), "synonyms": synonyms} for product, synonyms in
                   results.items()]

   try:
       es_client = get_client_es()
       response = es_client.synonyms.put_synonym(id="products-synonyms-set",
                                                 synonyms_set=synonyms_set)

       logging.info(json.dumps(response.body, indent=4))
       return response.body
   except Exception as e:
       logging.error(f"Erro update synonyms: {str(e)}")
       return None


if __name__ == '__main__':
   category = "Electronics"
   products = get_products("Electronics")
   llm_synonyms = generate_synonyms(category, products)
   mount_synonyms(llm_synonyms)同義語サポート付きのインデックスの作成
新しいインデックスが作成され、 productsインデックスのすべてのデータが再インデックスされます。このインデックスは、以前に作成されたproducts-synonyms-setを適用するsynonyms_filterを使用します。
以下はシノニムを使用するように構成されたインデックス マッピングです。PUT products_02
{
  "settings": {
    "analysis": {
      "filter": {
        "synonyms_filter": {
          "type": "synonym",
          "synonyms_set": "products-synonyms-set",
          "updateable": true
        }
      },
      "analyzer": {
        "synonyms_analyzer": {
          "type": "custom",
          "tokenizer": "standard",
          "filter": [
            "lowercase",
            "synonyms_filter"
          ]
        }
      }
    }
  },
  "mappings": {
    "properties": {
      "ID": {
        "type": "long"
      },
      "category": {
        "type": "keyword"
      },
      "name": {
        "type": "text",
        "analyzer": "standard",
        "search_analyzer": "synonyms_analyzer"
      }
    }
  }
}productsインデックスの再インデックス
ここで、 Reindex API を使用して、 productsインデックスからシノニムのサポートを含む新しいproducts_02インデックスにデータを移行します。Kibana DevTools で次のコードが実行されました。
POST _reindex
{
  "source": {
    "index": "products"
  },
  "dest": {
    "index": "products_02"
  }
}移行後、 products_02インデックスが作成され、構成された同義語セットを使用して検索を検証できるようになります。
同義語による検索の検証
2つのインデックス間の検索結果を比較してみましょう。両方のインデックスに対して同じクエリを実行し、結果を取得するために同義語が使用されているかどうかを検証します。
productsインデックスで検索（同義語なし）
Kibana を使用して検索を実行し、結果を分析します。「分析 > 検出」メニューで、作成したインデックスのデータを視覚化するためのデータ ビューを作成します。
Discovery 内で、データ ビューをクリックし、名前とインデックス パターンを定義します。「 products 」インデックスでは、「 products 」パターンを使用します。次に、「 products_02」 パターンを使用して、「 products_02 」インデックスの新しいデータ ビューを作成するプロセスを繰り返します。
データ ビューを構成したら、分析 > 検出に戻り、検証を開始できます。
ここで、DataView 製品を選択し、「タブレット」という用語で検索を実行すると、「Kindle Paperwhite」や「Apple iPad Air」などの製品があることがわかっているにもかかわらず、結果は表示されません。
products_02インデックスで検索 (同義語をサポート)
シノニムをサポートする「 products_synonyms 」データ ビューで同じクエリを実行すると、製品が正常に取得されました。これは、構成された同義語セットが正しく機能していることを示しており、検索された用語のさまざまなバリエーションが期待どおりの結果を返すことが保証されています。
同じクエリを Kibana DevTools で直接実行することで、同じ結果を得ることができます。Elasticsearch Search API を使用して、products_02 インデックスを検索するだけです。
まとめ
Elasticsearch に同義語を実装することで、製品カタログ検索の精度と範囲が向上しました。主な差別化要因はLLMの使用であり、これにより同義語が自動的かつ文脈に応じて生成され、事前定義されたリストの必要性がなくなりました。モデルは製品名とカテゴリを分析し、電子商取引に関連する同義語を確保しました。
さらに、同義語 API により辞書管理が簡素化され、同義語セットを動的に変更できるようになりました。このアプローチにより、検索はより柔軟になり、さまざまなユーザーのクエリ パターンに適応できるようになりました。
このプロセスは、新しいデータとモデルの調整によって継続的に改善され、ますます効率的な研究体験を保証します。
参照資料
Elasticsearchをローカルで実行する
https://www.elastic.co/guide/en/elasticsearch/reference/current/run-elasticsearch-locally.html
同義語API
https://www.elastic.co/guide/en/elasticsearch/reference/current/synonyms-apis.html


ログを活用して繁栄を：Elasticsearchの新しく特化したlogsdbインデックスモード
Mark Settle,George Kobar,Amena Siddiqi — Thu, 12 Dec 2024 00:00:00 GMT
Elasticsearchの新しいインデックスモード、logsdbにより、ログストレージの必要量が最大65%削減
本日、Elasticsearch の新しいインデックス モードである logsdb の一般提供開始を発表しました。これにより、logsdb のない Elasticsearch の最新バージョンと比較して、ログ データのストレージ フットプリントが最大 65% 削減されます。この劇的な改善により、観測性およびセキュリティ チームは、予算を超過することなく可視性を拡張しながら、すべてのデータを分析のためにすぐにアクセスできるようになります。
Logsdbはデータの順序を最適化し、synthetic _sourceで即座に非格納フィールド値を再構築することにより重複を排除します。また、高度なアルゴリズムとコーデックを使用して圧縮を改善するとともに、Elasticsearch内の列型ストレージを活用して、効率的なログのストレージと取得を実現します。
logsdbインデックスモードを使用してストレージ効率を改善し、分析を強化し、コストを削減
ログは、オブザーバビリティとセキュリティの問題を検出し修正するための重要なシグナルを提供します。AIの進歩によりテキストベースのデータの分析が容易になるにつれて、その有用性は増しており、効率的なストレージと高性能なアクセスがこれまで以上に重要になっています。
残念ながら、インフラストラクチャーやアプリケーションによって生成されるログ量の増加はコストを押し上げており、データ収集の制限、保存期間の短縮、最新データをサイロ化されたアーカイブ層に追いやったりといった、分析を妨げる妥協を強いられています。
Logsdbはこれらの課題に直接対処します。ストレージ効率が向上すれば、より多くのデータを収集でき、複雑なデータフィルタリングの手間を避けることができます。脅威ハンティング、インシデント対応、コンプライアンス要件をサポートするために、ログをより長く保持することができます。すべてのデータが常に検索可能であるため、データセットがどれほど大きくなっても、迅速に洞察を得ることができます。
logsdbインデックスモードの背後にある技術的革新
Logsdbインデックスモードは、スマートインデックスソート、synthetic _source、および高度な圧縮を使用して、ログデータのディスクフットプリントを劇的に削減します。これを実装することで、logsdbを使用しない最新バージョンのElasticsearchと比較して、ログストレージの必要量を最大65%削減できます。現在、logsdbはインデキシング時により多くのCPUを使用しますが、その効率的なストレージによって、ほとんどのお客様にとって全体的なコストが削減されます。長期的なデータ保持を必要とするお客様には、総所有コスト（TCO）が最大50%削減されることを見込んでいます。
スマート インデックス ソートにより、類似のデータを近くに配置することで、ストレージ効率が最大 30% 向上し、一部のログ データ セットでのクエリの待機時間が短縮されます。デフォルトでは、インデックスは host.name と @timestamp でソートされます。データにさらに適切なフィールドがある場合は、代わりにそれを指定することもできます。
高度な圧縮により、Zstandard 圧縮 (Zstd)、デルタ エンコーディング、ランレングス エンコーディング、および自動的に選択されるその他のスマート コーデックを通じて、ログなどのテキストを多く含むデータのストレージ要件が大幅に削減されます。圧縮とパフォーマンスが最適化された列形式で保存される Doc-values により、並べ替え、集計、スクリプト用のフィールド値を効率的に保存および取得できます。
合成 _source を使用すると、組織は _source フィールドを破棄し、オンデマンドでそれを完全にまたは部分的に再構築することで、ストレージのニーズをさらに 20 ～ 40% 削減できます。この機能では、インデックス作成と検索により多くの計算が必要になる場合もありますが、テストでは測定可能な純効率の向上がもたらされることが示されています。Synthetic _source は、ほぼ 2 年間のメトリクスを使用した本番環境での使用に基づいて構築されており、ほぼすべてのフィールド タイプのサポートを含む、ログの多数の機能強化が行われています。
結果として得られるストレージの節約は、インデックスライフサイクルの各フェーズに渡って反映されます。ホットティアでのストレージ削減が65％である場合、ウォーム、コールド、フローズンティアでも同様に65%の削減が適用され、スナップショットをバケットストレージに保存する際のフットプリントも削減されます。
可視性を妥協しない：オブザーバビリティとセキュリティのためにすべてのログを保持
ログはインフラストラクチャとアプリケーションの可視性の基盤であり、監視とトラブルシューティングのための最も単純で基本的なシグナルを提供します。しかし、ログの量の増加に伴い、コストが上昇しています。この課題により、お客様は複雑なフィルタリングおよび管理ポリシーを導入する必要に迫られたり、データを早期に削除したり、データを取り出して分析できる状態にするには1日以上かかるストレージに関連ログを格納することを余儀なくされています。完全で、簡単に検索でき、アクセス可能なデータセットがなければ、問題を見つけて解決することは大幅に困難になります。
Logsdb インデックス モードは、検索可能なスナップショットや自動インポートなどの画期的な Elasticsearch 機能を基盤として構築されており、運用チームとセキュリティ チームの次のような問題点に対処します。
コストの削減: Logsdb はログのストレージ フットプリントを最大 65% 削減し、組織がより多くのデータを保持しながらストレージ費用を削減できるようにします。これにより、ホットからフローズンまですべてのストレージ層でコストが削減され、このデータを使用する観測性およびセキュリティ チームの生産性が向上します。
貴重なデータを保存: Logsdb はすべてのログ データを保存し、追加のツールや複雑なフィルターに頼ることなく運用効率を向上させます。合成 _source などの機能を使用すると、ソース ドキュメント全体を保存せずにデータの値を保持できます。
可視性の拡張: Logsdb は、観測性、セキュリティ、履歴データ用の個別のサイロなしで、1 つのプラットフォーム上のすべてのデータへの効率的なアクセスを提供します。サイト信頼性エンジニア (SRE) にとっては、メトリック、トレース、ビジネス データとともにログを分析できるため、問題解決が迅速化されます。同様に、セキュリティ オペレーション センター (SOC) チームにとっては、盲点を排除することで調査と修復が加速されます。
データへのアクセスを合理化: Logsdb を使用すると、SRE チームはトラブルシューティング、傾向分析、分析のために実用的なデータを効率的に保持できます。同様に、SOC チームは、法外なコストをかけずに、調査や脅威ハンティングのためにすべてのデータを迅速に検索できます。
Logsdbはあなたの環境に対応しています
Elasticsearch logsdb インデックス モードは、バージョン 8.17 以降、Elastic Cloud Hosted および Self-Managed のお客様に一般提供され、 Elastic Cloud Serverlessのログではデフォルトで有効になっています。
基本的なlogsdbの機能（スマートインデックスソートや高度な圧縮を含む）は、Standard、Gold、Platinumライセンスをお持ちの組織で利用可能です。ストレージ要件をさらに削減する完全なlogsdb機能（synthetic _sourceを含む）は、サーバーレスのお客様およびエンタープライズライセンスをお持ちの組織で利用可能です。
Elasticsearch logsdb の動作
Logsdbを使用すると、データの収集範囲を狭めたり、データを破棄したりサイロ化したりすることなく、すべてのログデータを保持し、運用効率を向上させることができます。スマートインデックスソート、高度な圧縮、synthetic _sourceなどの機能を活用して、必要なデータを予算内で保持し、分析することができます。
自分で体験してみませんか？Elastic を無料でお試しください。
本記事に記述されているあらゆる機能ないし性能のリリースおよびタイミングは、Elasticの単独裁量に委ねられます。現時点で提供されていないあらゆる機能ないし性能は、すみやかに提供されない可能性、または一切の提供が行われない可能性があります。


セマンティック検索の実装: Elasticsearch を使ったレシピ検索の構築
Andre Luiz — Thu, 07 Nov 2024 00:00:00 GMT
はじめに
多くの電子商取引ウェブサイトは、レシピ検索エクスペリエンスを強化することに関心を持っています。セマンティック検索を正しく適用すると、顧客は「バレンタインデー用の何か」や「感謝祭の食事」など、より自然なクエリに基づいて必要な材料をすばやく見つけることができます。
この記事では、Elasticsearch を使用して、このようなクエリをサポートするセマンティック検索を実装する方法を説明します。スーパーマーケットの食材や製品のカタログを保存するためのインデックスを設定し、このインデックスを使用してレシピ検索を改善する方法を説明します。この記事全体を通して、このデータ構造を作成し、自然言語処理技術を適用して顧客の意図に沿った関連性の高い結果を提供する方法について説明します。
この記事で紹介したコードはすべて Python で開発されており、 GitHubで入手できます。リポジトリにアクセスしてソース コードを確認し、必要に応じて調整し、開発環境に直接ソリューションを実装できます。
セマンティック検索の実装を開始
セマンティック検索の実装を開始するには、まず自然言語モデルを定義する必要があります。Elastic は独自のモデルELSERを提供していますが、Hugging Face など、さまざまなプロバイダーの NLP モデルの統合もサポートしています。この柔軟性により、ニーズに最適なオプションを選択できます。
この記事では、NLP モデルの展開と管理の複雑さを軽減するELSERを使用します。さらに、Elastic はsemantic_text機能を提供しており、これによりプロセスが大幅に簡素化されます。semantic_textを使用すると、埋め込み生成プロセス全体が簡単かつ自動化されます。推論ポイントを定義し、インデックス マッピングで埋め込みを受け取るフィールドを指定するだけです。ドキュメントのインデックス作成中に埋め込みが生成され、指定されたフィールドに自動的に関連付けられます。
セットアップ手順
以下は、セマンティック検索をサポートするインデックスを作成する手順です。以下の手順に従うと、インデックスが設定され、セマンティック検索の準備が整います。
推論ポイント を作成します 。
インデックスを作成し、埋め込みを受け取ることができるように説明フィールドを semantic_text として設定します。
製品カタログを保存する食料品カタログ インデックスにデータをインデックスします。このカタログは、ここにあるデータセットから取得されました。
スーパーマーケットにおけるセマンティック検索の応用
食料品店の製品データがインデックスに入力されたので、セマンティック検索を使用して検索結果を改善するためのクエリをテストおよび検証しています。私たちの目標は、コンテキストとユーザーの意図を理解し、より関連性の高い正確な結果を提供する、よりスマートな検索エクスペリエンスを提供することです。
セマンティック検索が解決する課題
製品カタログに基づいて、従来の語彙検索ではしばしば問題となる語彙とコンテキストの問題に対処することで、セマンティック検索が食料品店での検索エクスペリエンスをどのように変革できるかを探ってみましょう。
1. 料理の意図の解釈
問題 01 : 顧客が「グリル用シーフード」を検索する場合、語彙検索システムはクエリの背後にある意図を完全に理解できない可能性があります。グリルに適したシーフード製品をすべて識別できず、製品名に「シーフード」または「グリル」という正確な用語が含まれる製品のみが返される可能性があります。
まず、語彙検索を実行し、結果を分析します。次に、セマンティック検索で同じことを実行し、同じ検索語の結果を比較します。
クエリ語彙検索 response = client.search(
        index="grocery-catalog",
        size=5,
        source_excludes="description_embedding",
        query={
            "multi_match": {
                "query": "seafood for grilling",
                "fields": [
                    "name",
                    "description"]
            }
        }
    )結果：
検索タイプ
名前
スコア
語彙
北西部の魚 アラスカ産ベアディズワイガニ
10.453125
語彙
吉田さんのソース オリジナルグルメ
7.2289705
語彙
プレミアムシーフードバラエティパック - 20個
7.1924105
語彙
アメリカ産レッドスナッパー - 丸ごと、頭付き、洗浄済み
6.998647
語彙
ロブスターの爪と腕、持続可能な天然漁獲
6.438654
語彙検索により、American Red Snapper や Northwest Fish Alaskan Bairdi Snow Crab など、グリルに適した魚介類がいくつか返されました。しかし、語彙検索では、シーフードではなくミートソースであるミスターヨシダソースなど、関連性の低い商品がリストの上位に表示され、語彙アルゴリズムが「グリル用」の文脈を完全に理解するのに苦労していることが示唆されました。
セマンティック検索ソリューション
「シーフード」という用語と「グリル」などの調理コンテキストを組み合わせたクエリを使用して、商品名に「グリル」や「シーフード」という単語が直接表示されていない場合でも、グリルに最適な魚の切り身、エビ、ホタテなどの包括的なオプションのリストを返します。これにより、検索結果が顧客の意図にさらに一致するようになります。
クエリセマンティック検索:es_client.search(
   index="grocery-catalog-elser",
   size=size,
   source_excludes="description_embedding",
   query={
       "semantic": {
           "field": "description_embedding",
           "query": "seafood for grilling"

       }
   })検索タイプ
名前
スコア
セマンティック
頭付き、スズキの丸ごと一匹
16.175909
セマンティック
アラスカ産クロタラ（セーブルフィッシュ）
15.855331
セマンティック
アメリカ産レッドスナッパー - 丸ごと、頭付き
15.454779
セマンティック
北西部の魚 アラスカ産ベアディズワイガニ
15.855331
セマンティック
アメリカ産レッドスナッパー - 丸ごと、頭付き
15.3892355
セマンティック検索では、「シーフード」という用語に直接関連する製品が返されるだけでなく、「グリル」というコンテキストも理解し、グリルに適した丸ごとの魚や切り身も表示されました。ここで重要なのは結果の精度であり、これにはグリル料理によく使われるスズキやアラスカ産黒タラなどの丸ごとの魚のオプションも含まれていました。
問題 02 : 多くの顧客は、仕事で長い一日を過ごした後、「平日の簡単な食事」などの用語を使用して、手早く簡単に作れる夕食の解決策を検索します。従来の語彙検索では、手軽な食事という概念を完全には捉えることができず、多くの場合、名前に「簡単」という言葉が含まれる商品のみに焦点が当てられます。
前の問題と同様に、まずは語彙検索を実行します。その後、セマンティック検索を使用したソリューションを適用します。
クエリ語彙検索 response = client.search(
        index="grocery-catalog",
        size=5,   
        source_excludes="description_embedding",
        query={
            "multi_match": {
                "query": "easy weeknight meals",
                "fields": [
                    "name",
                    "description"]
            }
        }
    )結果：
検索タイプ
名前
スコア
語彙
Avery イージーピール 住所ラベル 4200枚
8.017723
語彙
Omeals 自己加熱式非常食/携帯食 32
6.592727
語彙
沿岸シーフード キハダマグロの角切りポケ
5.836883
語彙
重量感のある超重量12オンスフォーム
5.8116536
語彙
ヴァニティフェア エブリデイ ナプキン 2枚重ね 110枚入り
5.752989
語彙検索では、Avery Easy Peel Address Labels や Vanity Fair Everyday Napkins など、食事とはまったく関係のないアイテムも含め、関連性の低い結果が返されました。これらの製品は、手早く食事をしたいというユーザーのニーズを満たしていません。語彙検索では確かに 1 つの便利な製品 (Omeals Self Heating Emergency Meals) が返されましたが、ナプキンやラベルなどの他の結果は説明にある「簡単」または「平日の夜」という単語に一致するだけで、素早い食事の解決策を求めるユーザーの意図に真に応えるものではありませんでした。
セマンティック検索ソリューション
手早く簡単に食べられる食事の意図を理解するクエリを実装しました。これは、名前に「簡単」という言葉が明示的に含まれていなくても、調理済みの肉、冷凍パスタ、ミールキットなど、すぐに準備できる製品を関連付けます。このアプローチにより、顧客は平日の夜に素早く夕食をとるのに最適なオプションを見つけられるようになり、利便性のニーズに応えます。
クエリセマンティック検索es_client.search(
   index="grocery-catalog-elser",
   size=size,
   source_excludes="description_embedding",
   query={
       "semantic": {
           "field": "description_embedding",
           "query": "easy weeknight meals"

       }
   })結果：
検索タイプ
名前
スコア
セマンティック
Omeals 自己加熱式非常食/携帯食 32
14.610006
セマンティック
日清カップヌードル、エビ、2.5オンス
13.751424
セマンティック
ナマステ グルテンフリー ワッフル＆パンケーキミックス
13.73376
セマンティック
アイダホポテト、ゴールデングリルハッシュブラウンポテト
12.549422
セマンティック
日清 カップヌードル チキン 24個入り
12.034527
セマンティック検索では、インスタントラーメン（カップヌードル）、調理済みのジャガイモ、パンケーキミックスなど、平日の夜に簡単に作れる夕食の典型的な選択肢である、手軽で便利な食事に明確に関連する製品が返されました。これは、セマンティック検索が「平日の夜に簡単に作れる食事」というフレーズの背後にある概念を理解し、手早く簡単に作れる食事を見つけたいというユーザーの意図を捉えることができることを示しています。興味深いことに、「ソーダ」などの他のカテゴリの製品も、コンテキストに関連がある場合（食事に添える飲み物など）に含まれることがあります。
2. 地域用語と語彙のバリエーション
問題: ある顧客が「ソーダ」を検索する一方で、別の顧客は同じ商品を「ポップ」で検索する可能性があります。従来の語彙検索では、両方の用語が同じ項目を指していることを認識できません。
クエリ語彙検索 response = client.search(
        index="grocery-catalog",
        size=5,
        source_excludes="description_embedding",
        query={
            "multi_match": {
                "query": "refreshing pop drink low sugar",
                "fields": [
                    "name",
                    "description"]
            }
        }
    )結果：
検索タイプ
名前
スコア
語彙
プライムハイドレーション+スティック 電解質ドリンクミックス
14.492869
語彙
カプリサン、100%ジュース、バラエティパック
12.340851
語彙
ジョイバースト エナジードリンク、フローズンローズ、12
11.839179
語彙
ケロッグのポップタルト、フロステッドブラウンシュガーシナモン
9.97788
語彙
カインド ミニバー バラエティパック 0.7
9.336912
語彙検索は、正確な単語の一致に焦点を当てます。Prime Hydration や Capri Sun などの製品が返される一方で、「pop」という用語との直接一致により、飲み物ではなくスナックである Kellogg's Pop-Tarts など、無関係な結果も表示されました。これは、用語に複数の意味がある場合やあいまいな場合、語彙検索の効果が低下する可能性があることを浮き彫りにしています。
セマンティック検索ソリューション
セマンティッククエリでは、語彙検索では解決できない語彙のバリエーションの問題を克服できます。検索用語を拡張することで、文脈上の意味に基づいた結果を得ることができ、より関連性の高い包括的な回答を提供できます。
クエリ:es_client.search(
   index="grocery-catalog-elser",
   size=size,
   source_excludes="description_embedding",
   query={
       "semantic": {
           "field": "description_embedding",
           "query": "refreshing pop drink low sugar"

       }
   })結果：
検索タイプ
名前
スコア
セマンティック
オリポップ 12オンス プレバイオティクスソーダ バラエティ
14.776867
セマンティック
バイ アンチオキシダント ココフュージョン バラエティパック 18個
14.663253
セマンティック
モンスターエナジードリンク、ゼロウルトラ、24
14.486348
セマンティック
ジョイバースト エナジー バラエティ、12液量オンス
14.007214
セマンティック
ジョイバースト エナジードリンク、フローズンローズ、12
13.641038
セマンティック検索では、製品名に「pop」という正確な用語が含まれていない場合でも、「soda」の同義語として「pop」の概念に直接一致する製品 (Olipop Prebiotics Soda など) が返されます。検索では、ユーザーの意図（爽やかな低糖飲料）を理解し、プレバイオティクスソーダ（Olipop）や無糖エナジードリンク（Monster Energy Drink）などのオプションを含む関連商品を返すことができました。
まとめ
食料品店のコンテキストでセマンティック検索を実装すると、「グリル用の魚介類」や「平日の簡単な食事」などの複雑なクエリを理解するのに非常に効果的であることが証明されています。このアプローチにより、ユーザーの意図をより正確に解釈し、関連性の高い商品を返すことができました。
Elasticsearch を使用し、ELSER でプロセスを簡素化することで、セマンティック検索を迅速かつ効率的に適用し、検索結果を大幅に改善し、より機敏でターゲットを絞ったショッピング体験を提供できるようになりました。これにより、検索プロセスが最適化されるだけでなく、顧客に提供される結果の関連性も高まりました。
参照資料
モデル ELSER:
https://www.elastic.co/guide/en/elasticsearch/reference/current/put-inference-api.html
https://www.elastic.co/guide/en/elasticsearch/reference/current/infer-service-elser.html
意味テキスト:
https://www.elastic.co/guide/en/elasticsearch/reference/current/semantic-text.html
https://www.elastic.co/guide/en/elasticsearch/reference/current/semantic-search.html
データセット:
https://www.kaggle.com/datasets/bhavikjikadara/grocery-store-dataset?select=GroceryDataset.csv
セマンティック検索:
https://www.elastic.co/guide/en/elasticsearch/reference/current/semantic-search.html
https://www.elastic.co/guide/en/elasticsearch/reference/current/semantic-search-semantic-text.html

基本 - Elasticsearch Labs

Azure AKS Automatic に Elasticsearch をデプロイする方法

AKS Automatic とは何ですか?

AKS Automaticの設定方法

まとめ

今後の見通し

Elasticsearch で構造化ドキュメントの再帰チャンクを構成する

再帰チャンキングとは何ですか?

再帰チャンクを構成するにはどうすればよいですか?

再帰チャンキングはどのように機能しますか?

再帰チャンクの設定例

セパレーターグループの活用

カスタム区切りリストの利用

再帰チャンキングの実際の例

今すぐ再帰チャンキングを始めましょう!

Kibana に Elasticsearch クエリルール UI を導入

クエリルールUI

例: 人気商品

例: ユーザーベースのメタデータ

例: 即時除外

まとめ

AWS MarketplaceでElasticsearchをデプロイする方法

AWS Marketplaceとは？

Elastic on AWS Marketplaceを使用するのはどのような場合ですか？

AWSマーケットプレイスでElastic Cloudをセットアップする方法

ステップ1 : AWS Marketplaceにアクセスする

ステップ 2: サービスに登録する

ステップ3. Elasticで新しいアカウントを設定する

サブスクリプションをキャンセルする

次のステップ

Elasticsearch のシャードとレプリカ: 実践ガイド

破片を理解する

レプリカを理解する

シャードとレプリカの最適化

Elasticsearchの基盤となるプライマリシャードとレプリカシャード

ユニークなパターンを明らかにする: Elasticsearch における重要な用語の集約ガイド

重要な用語の理解

実践応用（消費者行動分析）

分析のためのデータの準備

人口動態パターンの理解

通常のパターン

iPhone 16ユーザーのパターン

消費者セグメンテーション

重要語の集約とハイブリッド検索

まとめ

GCP GKE AutopilotでElasticsearchをデプロイする方法

Elasticsearchの導入作業

GKE Autopilotとは何ですか？

Google CloudでECKを使用するタイミングは？

Google CloudでECKを設定する方法は？

今後の見通し

JavaScript で Elasticsearch を正しく使う方法、パート II

制作のベストプラクティス

Elasticsearchにおけるエラー処理。

テスト

サーバーレス環境

Elastic Serverlessでクライアントを実行する方法

Function-as-a-Service環境でクライアントを実行する方法

まとめ

Elasticsearch のディスク容量と使用量を最適化する方法

透かしの背景

ディスクがいっぱいになった場合（過剰使用）の防止と対処方法

Elasticsearch クラスターにストレージ容量を追加する方法

ディスク容量が十分に活用されない場合の防止と対処方法

Elasticsearch クラスターのストレージ容量を削減する方法

ディスクサイズ、RAM、CPUの関係

JavaScript で Elasticsearch を正しく使う方法、パート 1

Elasticsearch Node.js クライアントとは何ですか?

環境

フロントエンド、バックエンド、それともサーバーレス？

クライアントの接続

文書のインデックス作成

Elasticsearchクライアント

セマンティックマッピング

バルクヘルパー

Elasticsearchでのデータ検索

語彙クエリ (/search/lexic?q=)

セマンティッククエリ (/search/semantic?q=)

ハイブリッド クエリ (/search/hybrid?q=)

まとめ

ハイブリッドクエリ (/search/hybrid?q=)

Logstash elasticsearch フィルタープラグイン