SIOS Technology, Inc. Saman 目次 はじめに：この記事で解決できること 問題の本質：フルスキャン前提の設計 解決策の発想：Elasticsearch Transformsとは何か Transformの構造を理解する サンプルデータで効果を検証する 実験①：高cardinalityキーでの集約（clientip × 1時間） 実験②：低cardinalityキーでの集約（response × 1時間） Transformが生む2種類の圧縮 ① 縦方向の圧縮（行を減らす） ② 横方向の圧縮（列を減らす） 実行手順 まとめと設計指針 はじめに：この記事で解決できること 数十億件規模のElasticsearchで、ダッシュボード表示のたびに数十秒待つ、そんな問題を抱えているなら、原因はクエリではなく 設計 にあるかもしれません。 本記事では、SIOS Technologyのサマンが実務で直面した問題とその解決策として、 Elasticsearch Transforms を使った事前計算パターンを説明します。サンプルデータを使った実験結果も含め、実際に得られる効果を再現できる手順を紹介します。 問題の本質：フルスキャン前提の設計 以前担当したプロジェクトでは、Kibanaダッシュボードを開くたびにタイムアウトが発生していました。最初はクエリチューニングやノード増強を検討しましたが、根本原因は runtime fieldを使ったフルスキャン前提の設計 にありました。 実装していたES|QLクエリはこのようなものです。 FROM <巨大インデックス> | EVAL metric = GREATEST(fieldA, fieldB) | STATS MAX(metric) BY group_id 理論上は正しいクエリです。しかし数十億件に対してこれを毎回実行すると、全期間スキャン→全行で演算→高cardinalityフィールドで集約という処理をダッシュボード表示のたびに繰り返すことになります。 「これはクエリの問題ではなく、設計の問題だ」 と気づいたことが解決の出発点でした。 解決策の発想：Elasticsearch Transformsとは何か Elasticsearch Transformsは、生データを別インデックスに事前集計して保存する機能です。 生データインデックス → Transform → サマリーインデックス ダッシュボードやアラートは軽量なサマリーインデックスだけを参照するため、検索のたびに重い計算を繰り返す必要がなくなります。 重要な点として、**Transformは「クエリを速くするツール」ではなく「データ構造を再設計するツール」**です。効果の大小は、 group_by の設計——何をキーにまとめるか——に直接依存します。 Transformの構造を理解する 実験の前に、Transformがどういう構造を持つかを把握しておきましょう。 PUT _transform/<name> { "source": { ... }, "pivot": { ... }, "dest": { ... }, "settings": { ... } } source ：読み込むインデックスを指定します。クエリフィルターを加えることで、不要なデータを事前に除外できます。 "source": { "index": "kibana_sample_data_logs", "query": { "range": { "@timestamp": { "gte": "now-90d" } } } } pivot ：最も重要なブロックです。group_byでどの粒度にまとめるかを、aggregationsで何を計算するかを定義します。設計ミスはほぼここで起きます。 "pivot": { "group_by": { "timestamp_hour": { "date_histogram": { "field": "@timestamp", "calendar_interval": "1h" } }, "response": { "terms": { "field": "response.keyword" } } }, "aggregations": { "request_count": { "value_count": { "field": "bytes" } }, "total_bytes": { "sum": { "field": "bytes" } } } } dest ：出力先インデックスを指定します。以後のダッシュボードやアラートはこのインデックスだけを参照します。 settings ：大規模環境では必須の安全装置です。max_page_search_sizeは一度に処理するドキュメント数を制御し、メモリ枯渇を防ぎます。値はクラスタのヒープメモリに応じて調整が必要です（デフォルトは500。余裕がなければ100〜200程度から始めるのが無難です）。 "settings": { "max_page_search_size": 100 } サンプルデータで効果を検証する ここからはElasticでデフォルトで入っているkibana_sample_data_logs（約14,000件、約8.4MB）を使って、group_by設計の違いがどれほど結果に影響するかを確認します。 実験①：高cardinalityキーでの集約（clientip × 1時間） clientipはほぼリクエストごとに異なるIPアドレスです。これを1時間単位と組み合わせてgroup_byに使うと、グループがほとんど1件ずつになり、まとめる対象がありません。 PUT _transform/sample-ip-hourly-v1 { "source": { "index": "kibana_sample_data_logs" }, "pivot": { "group_by": { "timestamp_hour": { "date_histogram": { "field": "@timestamp", "calendar_interval": "1h" } }, "clientip": { "terms": { "field": "clientip" } } }, "aggregations": { "total_bytes": { "sum": { "field": "bytes" } }, "request_count": { "value_count": { "field": "bytes" } }, "error_count": { "filter": { "term": { "response.keyword": "404" } } }, "error_rate": { "bucket_script": { "buckets_path": { "errors": "error_count._count", "total": "request_count" }, "script": "params.total > 0 ? (params.errors / params.total) * 100 : 0" } } } }, "dest": { "index": "summary-ip-hourly" } } POST _transform/sample-ip-hourly-v1/_start 結果： ドキュメント数：13,844件（元データとほぼ同数） サイズ：約2.7MB Transformは実行されていますが、圧縮効果はほぼゼロです。 cardinalityが高いキーは、まとめるべき単位として機能しません。 実験②：低cardinalityキーでの集約（response × 1時間） response（HTTPステータスコード）は200、404、503など数種類しかありません。これを1時間単位でまとめると、同じ時間帯の同じレスポンスコードが大量にひとつのドキュメントに集約されます。 PUT _transform/sample-response-hourly-v1 { "source": { "index": "kibana_sample_data_logs" }, "pivot": { "group_by": { "timestamp_hour": { "date_histogram": { "field": "@timestamp", "calendar_interval": "1h" } }, "response": { "terms": { "field": "response.keyword" } } }, "aggregations": { "request_count": { "value_count": { "field": "bytes" } }, "total_bytes": { "sum": { "field": "bytes" } }, "error_flag_count": { "filter": { "range": { "response.keyword": { "gte": "400" } } } }, "error_rate": { "bucket_script": { "buckets_path": { "errors": "error_flag_count._count", "total": "request_count" }, "script": "params.total > 0 ? (params.errors / params.total) * 100 : 0" } } } }, "dest": { "index": "summary-response-hourly" } } POST _transform/sample-response-hourly-v1/_start 結果： ドキュメント数：2,005件（ 約85%削減 ） サイズ：約405KB（ 約95%削減 ） サイズを確認するには、summary-response-hourly/*stats を実行し、レスポンス内の “store” フィールドにある “size_in_bytes” の値を確認できます。 この劇的な差はどこから来るのでしょうか。 Transformが生む2種類の圧縮 Transformが実現する圧縮は、実は2方向で同時にやります。 ① 縦方向の圧縮（行を減らす） 元ログ： 時刻 response bytes 10:01 200 1000 10:05 200 2000 10:10 200 1500 10:15 404 300 10:20 404 500 5行あります。 これを 1時間 × response でまとめると： 時間 response total_bytes 10:00 200 4500 10:00 404 800 5行 → 2行 これが縦方向の圧縮です。 同じカテゴリが繰り返し出るほど効果は大きくなります。 ② 横方向の圧縮（列を減らす） 元ログには多くのフィールドがあります。 message agent geo request referer tags …… でも、集約に必要なのは： 時間 response bytes だけ。 Transform後のインデックスには、不要なフィールドは存在しません。 つまり、列が消える。 今回サイズが95%削減された理由はここにあります。 実行手順 # 1. Transformを作成 PUT _transform/summary-response-hourly { ... } # 2. 実行前にプレビューで確認（大規模環境では必須） POST _transform/summary-response-hourly/_preview # 3. 起動 POST _transform/summary-response-hourly/_start # 4. 状態確認 GET _transform/summary-response-hourly/_stats # 5. 必要に応じて停止・削除 POST _transform/summary-response-hourly/_stop DELETE _transform/summary-response-hourly まとめと設計指針 Transformsを導入する前に、以下の問いに答えてみてください。 この計算は、本当に検索時にやる必要がありますか？ 答えがNoであれば、Transformは有効な選択肢です。設計時には以下の点に注意してください。 group_byのcardinalityを下げる ことが効果の前提条件。高cardinalityキーは原則として避ける 必要なフィールドだけを残す 設計にすることで、横方向の圧縮も最大化できる _preview で必ず事前検証 してから本番適用する max_page_search_sizeはクラスタのリソースに合わせて調整する スケールが大きくなるほどTransformの効果は大きくなります。数億・数十億件規模の時系列データを扱っているなら、「事前計算+サマリーインデックス」という設計パターンは真っ先に検討すべき選択肢です。 The post Elasticsearch Transforms入門ガイド｜重い集計クエリを事前計算で解決する方法 first appeared on Elastic Portal .

目次 はじめに 開発環境 構成図 事前準備 リポジトリの取得と展開 環境変数の設定 コンテナの起動 EDOT Collector の設定 5.1. Python コンテナへの接続 5.2. EDOT Collector のダウンロード Elasticsearch との連携設定 6.1. System OpenTelemetry Assets の有効化 6.2. API Key の生成 6.3. otel.yml の編集 6.4. EDOT Collector の起動 Python アプリのトレース取得 7.1 appuser で Python コンテナへ接続する 7.2. 計装 (Instrumentation) の準備 7.3. Python アプリの実行 観測データの確認 8.1. Dashboard の表示 8.2. Logs の表示 8.3. トレースの表示 まとめ 参考URL はじめに これまで Elastic Observability でフルスタックな観測を実現するには、Fleet Server や Elastic Agent、および各 Integration（System, APM等）の個別設定が必要でした。 しかし、最新の Elastic Observability (v9.2以降) では、OpenTelemetry (OTel) をネイティブにサポート。 これにより、独自エージェントの複雑な管理をスキップして、より標準的かつ柔軟にデータを集約できるようになりました。 本記事では、この新しい機能の使い方を解説します。 開発環境 Elasticsearch / Kibana: v9.2.4 Basic License Python : v3.14 Docker環境 : 筆者は Windows 上の Rancher Deskop 1.20.1 を利用 ※ステータス: OpenTelemetry Integration は、Elasticsearch 9.2 時点で Preview です。 構成図 今回の構成では、Pythonアプリケーションが稼働するコンテナ内に EDOT (Elastic Distribution of OpenTelemetry) Collector を配置し、そこから直接 Elasticsearch へデータを送信します。 事前準備 リポジトリの取得と展開 まずは検証用コードをダウンロードします。 https://github.com/SIOS-Technology-Inc/elastic-blogs/tags  にアクセスします。 release-2026-02-02 をクリックします。 Assets の Source code (zip) をクリックします。 elastic-blogs-release-2026-02-02.zip がダウンロードされます。 elastic-blogs-release-2026-02-02.zip を解凍します。 環境変数の設定 Windows などでターミナルを開きます。 2026-02-otel/app フォルダに移動します。 cd 2026-02-otel/app .env.sample をコピーして、パスワードやメモリ制限などの環境変数を設定します。 cp .env.sample .env メモ帳などで .env ファイルを編集します。 ... ELASTIC_PASSWORD=... (Elasticsearchのパスワードを設定します。) KIBANA_PASSEORD=... (Kibana用の内部パスワードを設定します。) ... SAVEDOBJECTS_ENCRYPTIONKEY=... (SavedObjects用の暗号化キーを設定します。) ... ES01_MEM_LIMIT=... (Elasticsearchのメモリ上限を設定します。) KB_MEM_LIMIT=... (Kibanaのメモリ上限を設定します。) コンテナの起動 docker compose -f docker-compose-es-kibana-python.yml up -d EDOT Collector の設定 5.1. Python コンテナへの接続 ※今回は、Python を動かすコンテナに Elastic Distribution of OpenTelemetry (EDOT) Collector をインストールするので、Python コンテナへ接続します。 root 権限でインストールおよび実行するので、-u 0 を指定します。 docker exec -itu 0 app-python-app-1 /bin/bash 5.2. EDOT Collector のダウンロード 下記で Elastic 9.2.4 用の EDOT Collector をダウンロードします。 wget https://artifacts.elastic.co/downloads/beats/elastic-agent/elastic-agent-9.2.4-linux-x86_64.tar.gz tar xvfz elastic-agent-9.2.4-linux-x86_64.tar.gz cd elastic-agent-9.2.4-linux-x86_64 # 設定用ディレクトリの作成とサンプルのコピー mkdir data/otel cp ../otel.yml.sample otel.yml otel.yml.sample は、あらかじめ elastic-agent-9.2.4-linux-x86_64 内の otel.yml.sample を抽出し、改変したものです。 exporters/elasticsearch/otel/tls などを改変しています。 ※otel.yml の編集は、後で行います。 Elasticsearch との連携設定 6.1. System OpenTelemetry Assets の有効化 Web ブラウザから  http://localhost:5601  へアクセスし、 ユーザーID: elastic パスワード: 4.2. で ELASTIC_PASSWORD に設定した文字列 で Kibana にログインします。 Management / Integrations 画面を表示します。 Display: beta integrations を ON にします(※System OpenTelemetry Assets は、Elastic 9.2.4 の時点では Preview 版のため)。 System OpenTelemetry Assets を検索し、クリックします。 右上の [↓ Install System OpenTelemetry Assets] ボタンをクリックします。 Install System OpenTelemetry Assets のダイアログが表示されるので、右下の [Install System OpenTelemetry Assets] ボタンをクリックします。 ※Assets欄にあるダッシュボードがインストールされます。 6.2. API Key の生成 EDOT Collector から Elasticsearch へ書き込むための API Key を生成し、控えておきます。 Kibana の Home 画面から Elasticsearch アイコンをクリックします。 [Create API key ] ボタンをクリックします。 Name : otel と入力し、[Create API key] をクリックします。 API Key が生成されるので、コピーしておきます（メモ帳などに一時的にペーストしておきます）。 6.3. otel.yml の編集 Python を動作させているコンテナ上で作業します。 vi otel.yml 取得した API Key を 5.2. で配置した otel.yml に反映させます。 ... exportes: elasticsearch/otel: endpoints: ["https;//es01:9200"] api_key: "YOUR_API_KEY_HERE" ... 6.4. EDOT Collector の起動 今回は、あくまでも検証用のための実行なので、ターミナルからバックグラウンドで実行します。 ./otelcol --config ./otel.yml >> /var/log/otelcol.log 2>&1 & これで、Python コンテナのログやメトリクスが Elasticsearch へ送信されるようになります。 このコンテナからは、exit して OK です。 Python アプリのトレース取得 7.1 appuser で Python コンテナへ接続する docker exec -it app-python-app-1 /bin/bash 7.2. 計装 (Instrumentation) の準備 OpenTelemetry のライブラリをインストールします。 edot-bootstrap --action=install opentelemetry-bootstrap -a install 7.3. Python アプリの実行 コードに Elastic 専用の処理を書く必要はありません。 opentelemetry-instrument を冠して実行するだけで、自動的にトレースが送信されます。 実行する Python アプリ (src/test.py) のソースコード 3回ループするだけの単純な Python コードです。 import time from opentelemetry import trace def func1_sub(tracer): with tracer.start_as_current_span("func1_sub"): print ("Hello") time.sleep(1) def func1(tracer): with tracer.start_as_current_span("func1"): i = 0 while i < 3: func1_sub(tracer) i += 1 if __name__ == "__main__": tracer = trace.get_tracer(__name__) func1(tracer) Python アプリを実行します。 opentelemetry-instrument python src/test.py このコンテナからは exit して OK です。 観測データの確認 8.1. Dashboard の表示 Kibana の Analytics / Dashboard からダッシュボードを表示してみます。 [Otel] Hosts Overview ※このダッシュボードは、6.1 で追加されたものです。 EDOT Collector を動作させているホストの稼働状況が可視化されます。 [Otel] Host Details – Metrics EDOT Collector を動作させているホストの CPU や Memory, Network など各種メトリクスが可視化されます。 8.2. Logs の表示 Kibana の Discover から logs-* を表示してみます。 EDOT Collector を動作させているホストの /var/log/*.log の内容が表示されます。 ※ログが表示されない場合、表示対象期間を調整してみてください。 8.3. トレースの表示 Kibana の Observability / Application 画面を表示します。 Service inventory 画面が表示されます。 my-python-script を選択します。 “my-python-script” という名前は、python/Dockerfile に OTEL_SERVICE_NAME として記載していたものです。 my-python-script の Overview が表示されます。 Transactions をクリックします。 src/test.py のトランザクションに関する情報が表示されます。 画面の下の方の Transactions の func1 をクリックします。 func1 の trace 情報が表示されます。 func1 内で func1_sub が3回実行され、実行時間はそれぞれ、3秒、1秒となっていることがわかります。 ※ “func1” や “func1_sub” といった名前は、src/test.py 内に記載したものです。 まとめ OpenTelemetry を採用することで、以下の大きなメリットが得られます。 運用の簡素化: Fleet Server や複雑な Agent 管理から解放されます。 脱ベンダーロックイン: 業界標準のプロトコル（OTLP）を使用するため、将来的なプラットフォームの移行や併用が容易になります。 ポータビリティ: Elastic 固有のコードをアプリに埋め込む必要がなくなり、コードの純粋性を保てます。 現在 Preview 機能ですが、今後の Observability のデファクトスタンダードになることが予想されます。ぜひ今のうちに触れてみてください。 参考URL https://qiita.com/takeo-furukubo/items/2747bdf3e28037b1870b https://qiita.com/takeo-furukubo/items/5f5322977daf6d48fc8c https://www.elastic.co/docs/solutions/observability/get-started/opentelemetry/quickstart/self-managed/hosts_vms https://github.com/SIOS-Technology-Inc/elastic-blogs The post OpenTelemetry を使って Elastic Observability にログ、メトリクス、トレースを取り込んでみよう。 first appeared on Elastic Portal .

目次 はじめに 開発環境 事前準備 メインデータの用意（Sample web logs） 国マスタのインポート Lookup Index への変換 【実践】ES|QL での集計比較 Lookup Join なし（国コードのみ） Lookup Join あり（国名を結合） まとめ 参考資料 添付資料：country_list.csv はじめに これまで Elasticsearch で「メインのインデックスに、別インデックスの情報を紐付けて表示したい」場合、Enrich Processor を使用して、取り込み（Ingest）フェーズであらかじめデータを結合しておくのが一般的でした。 しかし、この方法ではデータの更新のたびに Enrich Policy の再実行が必要になるなど、運用の手間がかかる側面がありました。 最新の Elasticsearch では、ES|QL の LOOKUP JOIN 機能が登場し、クエリ実行時にリアルタイムで別インデックスの情報を参照できるようになりました。本記事では、この便利な新機能の使い方を紹介します。 開発環境 Elasticsearch / Kibana: v9.2.4 Chrome ※注意事項: LOOKUP JOIN … ON … == … の記法は、Elasticsearch 9.2 時点で Preview です。 事前準備 メインデータの用意（Sample web logs） 今回は Kibana に標準で用意されている「Sample web logs」を使用します。 まだ取り込んでいない場合は、Kibana ホームの「Add data」から Sample web logs を追加してください。 参考: https://elastic.sios.jp/blog/elasticsearch-esql-introduction-log-analysis/ 国マスタのインポート この記事の末尾に記載している country_list.csv を使用して、マスタデータを作成します。 ※筆者は、Webブラウザに Chrome を使用しました。 Kibana の Home > Upload a file を開きます。 country_list.csv をアップロードし、設定を以下のように変更します。 Index name: country_list Advanced options > Data view: off（マスタなので Data view は不要です） [Import] をクリックします。 Lookup Index への変換 ES|QL の Lookup Join を利用するには、通常のインデックスを「Lookup 用」に変換する必要があります。 Stack Management > Index Management から country_list を選択します。 2. Manage ボタンから Convert to lookup index をクリックします。 3. Lookup index name に lookup-country_list と入力し、Convert を実行します。 Note: この操作により、インメモリで高速に結合可能な特殊なインデックスが生成されます。元の country_list もそのまま残ります。 【実践】ES|QL での集計比較 Lookup Join なし（国コードのみ） まずは、通常の集計を行ってみます。 Kibana の Discover を開き、上部の [Try ES|QL] をクリックします。 以下のクエリを入力して実行します。 FROM kibana_sample_data_logs | STATS bytes_sum = sum(bytes) BY geo.dest | KEEP geo.dest, bytes_sum | SORT bytes_sum DESC | LIMIT 8 集計対象の期間は、適当に調整してください。下記の例では、Last 24 hours を指定しています。 結果: geo.dest 項目に CN や US といった 2 桁の国コードが表示されます。これだけでは、直感的にどの国か分かりにくいですよね。 Lookup Join あり（国名を結合） 次に、LOOKUP JOIN を使って国マスタから国名を引っ張ってきます。 FROM kibana_sample_data_logs | STATS bytes_sum = sum(bytes) BY geo.dest | LOOKUP JOIN lookup-country_list ON geo.dest == country_code | KEEP country_name, bytes_sum | SORT bytes_sum DESC | LIMIT 8 結果: country_name が結合され、「CHINA」「UNITED STATES」といった具体的な国名が表示されるようになります！ まとめ ES|QL の LOOKUP JOIN を使うメリットは以下の通りです。 運用の簡略化: Enrich Policy を管理・更新する手間が省ける。 直感的な記述: SQL の JOIN に近い感覚で、クエリ内で動的に結合できる。 柔軟性: 必要なときだけマスタ情報を付与できる。 現在は Preview 機能ですが、将来的に Elasticsearch でのログ分析やレポート作成において、欠かせない機能になるはずです。 参考資料 Elastic公式: LOOKUP JOIN command https://www.elastic.co/docs/reference/query-languages/esql/commands/lookup-join 添付資料：country_list.csv 国マスタのCSVです。 ※このデータは、 https://www.e-tax.nta.go.jp/toiawase/qa/crs/countrycode.htm を元に生成したものです。 country_code,country_name AF,AFGHANISTAN AX,ALAND ISLANDS AL,ALBANIA DZ,ALGERIA AS,AMERICAN SAMOA AD,ANDORRA AO,ANGOLA AI,ANGUILLA AQ,ANTARCTICA AG,ANTIGUA AND BARBUDA AR,ARGENTINA AM,ARMENIA AW,ARUBA AU,AUSTRALIA AT,AUSTRIA AZ,AZERBAIJAN BS,BAHAMAS BH,BAHRAIN BD,BANGLADESH BB,BARBADOS BY,BELARUS BE,BELGIUM BZ,BELIZE BJ,BENIN BM,BERMUDA BT,BHUTAN BO,"BOLIVIA, PLURINATIONAL STATE OF" BQ,"BONAIRE, SINT EUSTATIUS AND SABA" BA,BOSNIA AND HERZEGOVINA BW,BOTSWANA BV,BOUVET ISLAND BR,BRAZIL IO,BRITISH INDIAN OCEAN TERRITORY BN,BRUNEI DARUSSALAM BG,BULGARIA BF,BURKINA FASO BI,BURUNDI KH,CAMBODIA CM,CAMEROON CA,CANADA CV,CABO VERDE KY,CAYMAN ISLANDS CF,CENTRAL AFRICAN REPUBLIC TD,CHAD CL,CHILE CN,CHINA CX,CHRISTMAS ISLAND CC,COCOS (KEELING) ISLANDS CO,COLOMBIA KM,COMOROS CG,CONGO CD,"CONGO, THE DEMOCRATIC REPUBLIC OF THE" CK,COOK ISLANDS CR,COSTA RICA CI,COTE D'IVOIRE HR,CROATIA CU,CUBA CW,CURACAO CY,CYPRUS CZ,CZECHIA DK,DENMARK DJ,DJIBOUTI DM,DOMINICA DO,DOMINICAN REPUBLIC EC,ECUADOR EG,EGYPT SV,EL SALVADOR GQ,EQUATORIAL GUINEA ER,ERITREA EE,ESTONIA ET,ETHIOPIA FK,FALKLAND ISLANDS (MALVINAS) FO,FAROE ISLANDS FJ,FIJI FI,FINLAND FR,FRANCE GF,FRENCH GUIANA PF,FRENCH POLYNESIA TF,FRENCH SOUTHERN TERRITORIES GA,GABON GM,GAMBIA GE,GEORGIA DE,GERMANY GH,GHANA GI,GIBRALTAR GR,GREECE GL,GREENLAND GD,GRENADA GP,GUADELOUPE GU,GUAM GT,GUATEMALA GG,GUERNSEY GN,GUINEA GW,GUINEA-BISSAU GY,GUYANA HT,HAITI HM,HEARD ISLAND AND MCDONALD ISLANDS VA,HOLY SEE (VATICAN CITY STATE) HN,HONDURAS HK,HONG KONG HU,HUNGARY IS,ICELAND IN,INDIA ID,INDONESIA IR,"IRAN, ISLAMIC REPUBLIC OF" IQ,IRAQ IE,IRELAND IM,ISLE OF MAN IL,ISRAEL IT,ITALY JM,JAMAICA JP,JAPAN JE,JERSEY JO,JORDAN KZ,KAZAKHSTAN KE,KENYA KI,KIRIBATI KP,"KOREA, DEMOCRATIC PEOPLE'S REPUBLIC OF" KR,"KOREA, REPUBLIC OF" KW,KUWAIT KG,KYRGYZSTAN LA,LAO PEOPLE'S DEMOCRATIC REPUBLIC LV,LATVIA LB,LEBANON LS,LESOTHO LR,LIBERIA LY,LIBYA LI,LIECHTENSTEIN LT,LITHUANIA LU,LUXEMBOURG MO,MACAO MK,NORTH MACEDONIA MG,MADAGASCAR MW,MALAWI MY,MALAYSIA MV,MALDIVES ML,MALI MT,MALTA MH,MARSHALL ISLANDS MQ,MARTINIQUE MR,MAURITANIA MU,MAURITIUS YT,MAYOTTE MX,MEXICO FM,"MICRONESIA, FEDERATED STATES OF" MD,"MOLDOVA, REPUBLIC OF" MC,MONACO MN,MONGOLIA ME,MONTENEGRO MS,MONTSERRAT MA,MOROCCO MZ,MOZAMBIQUE MM,MYANMAR NA,NAMIBIA NR,NAURU NP,NEPAL NL,NETHERLANDS NC,NEW CALEDONIA NZ,NEW ZEALAND NI,NICARAGUA NE,NIGER NG,NIGERIA NU,NIUE NF,NORFOLK ISLAND MP,NORTHERN MARIANA ISLANDS NO,NORWAY OM,OMAN PK,PAKISTAN PW,PALAU PS,"PALESTINE, STATE OF" PA,PANAMA PG,PAPUA NEW GUINEA PY,PARAGUAY PE,PERU PH,PHILIPPINES PN,PITCAIRN PL,POLAND PT,PORTUGAL PR,PUERTO RICO QA,QATAR RE,REUNION RO,ROMANIA RU,RUSSIAN FEDERATION RW,RWANDA BL,SAINT BARTHELEMY SH,"SAINT HELENA, ASCENSION AND TRISTAN DA CUNHA" KN,SAINT KITTS AND NEVIS LC,SAINT LUCIA MF,SAINT MARTIN (FRENCH PART) PM,SAINT PIERRE AND MIQUELON VC,SAINT VINCENT AND THE GRENADINES WS,SAMOA SM,SAN MARINO ST,SAO TOME AND PRINCIPE SA,SAUDI ARABIA SN,SENEGAL RS,SERBIA SC,SEYCHELLES SL,SIERRA LEONE SG,SINGAPORE SX,SINT MAARTEN (DUTCH PART) SK,SLOVAKIA SI,SLOVENIA SB,SOLOMON ISLANDS SO,SOMALIA ZA,SOUTH AFRICA GS,SOUTH GEORGIA AND THE SOUTH SANDWICH ISLANDS SS,SOUTH SUDAN ES,SPAIN LK,SRI LANKA SD,SUDAN SR,SURINAME SJ,SVALBARD AND JAN MAYEN SZ,ESWATINI SE,SWEDEN CH,SWITZERLAND SY,SYRIAN ARAB REPUBLIC TW,"TAIWAN, PROVINCE OF CHINA" TJ,TAJIKISTAN TZ,"TANZANIA, UNITED REPUBLIC OF" TH,THAILAND TL,TIMOR-LESTE TG,TOGO TK,TOKELAU TO,TONGA TT,TRINIDAD AND TOBAGO TN,TUNISIA TR,TURKEY TM,TURKMENISTAN TC,TURKS AND CAICOS ISLANDS TV,TUVALU UG,UGANDA UA,UKRAINE AE,UNITED ARAB EMIRATES GB,UNITED KINGDOM OF GREAT BRITAIN AND NORTHERN IRELAND US,UNITED STATES UM,UNITED STATES MINOR OUTLYING ISLANDS UY,URUGUAY UZ,UZBEKISTAN VU,VANUATU VE,"VENEZUELA, BOLIVARIAN REPUBLIC OF" VN,VIET NAM VG,"VIRGIN ISLANDS, BRITISH" VI,"VIRGIN ISLANDS, U.S." WF,WALLIS AND FUTUNA EH,WESTERN SAHARA YE,YEMEN ZM,ZAMBIA ZW,ZIMBABWE XK,KOSOVO The post ES|QL の Lookup Join でインデックス結合が驚くほど簡単に first appeared on Elastic Portal .