window.pipedriveLeadboosterConfig={です。 ベース:'leadbooster-chat.pipedrive.com'、 companyId:11580370, playbookUuid: '22236db1-6d50-40c4-b48f-8b11262155be', version: 2、 } ;(function () { var w = window もし (w.LeadBooster) {なら console.warn('LeadBooster already exists') } else { w.LeadBooster = { {. q: [], on: function (n, h) { this.q.push({ t: 'o', n: n, h: h }) }, trigger: 関数 (n) { { this.q.push({ t: 'o', n: n, h: h }) this.q.push({ t: 't', n: n }) }, } } })() elasticsearch gotchas - パート1 - The Codest
The Codest
  • 会社概要
  • サービス
    • ソフトウェア開発
      • フロントエンド開発
      • バックエンド開発
    • Staff Augmentation
      • フロントエンド開発者
      • バックエンド開発者
      • データエンジニア
      • クラウドエンジニア
      • QAエンジニア
      • その他
    • アドバイザリー
      • 監査&コンサルティング
  • 産業
    • フィンテック&バンキング
    • E-commerce
    • アドテック
    • ヘルステック
    • 製造業
    • 物流
    • 自動車
    • アイオーティー
  • 価値
    • CEO
    • CTO
    • デリバリー・マネージャー
  • チーム
  • Case Studies
  • ノウハウ
    • ブログ
    • ミートアップ
    • ウェビナー
    • リソース
採用情報 連絡先
  • 会社概要
  • サービス
    • ソフトウェア開発
      • フロントエンド開発
      • バックエンド開発
    • Staff Augmentation
      • フロントエンド開発者
      • バックエンド開発者
      • データエンジニア
      • クラウドエンジニア
      • QAエンジニア
      • その他
    • アドバイザリー
      • 監査&コンサルティング
  • 価値
    • CEO
    • CTO
    • デリバリー・マネージャー
  • チーム
  • Case Studies
  • ノウハウ
    • ブログ
    • ミートアップ
    • ウェビナー
    • リソース
採用情報 連絡先
戻る矢印 戻る
2016-02-21
ソフトウェア開発

elasticsearch gotchas - パート1

ミハエル・ロゴフスキー

こんにちは!私たちのフォーラムには様々な経験レベルの人たちが投稿しています!しかし今、私は真のRubyの巨人を探しています!

Elasticsearchは信頼できる成熟したライブラリApache Luceneをベースにした検索エンジンです。git での大きな活動 プロジェクト リポジトリや、GitHub、SoundCloud、Stack Overflow、LinkedInなどのプロジェクトへの実装が、その人気の高さを証明している。Elastic "という部分が、そのシステムの本質をすべて物語っています。その機能は、小規模のシンプルなファイル検索から、ナレッジディスカバリー、リアルタイムでのビッグデータ分析まで、膨大なものです。Elasticはあなたの代わりにクラスタを構成し、インデックスを定義し、最初に取得するドキュメントのフィールドタイプを定義します。また、別のサーバーを追加すると、サーバー間でインデックスデータを分割する処理を自動的に行います。残念ながら、上記のような自動化によって、デフォルト設定が何を意味するのかが不明確になり、誤解を招くことがしばしばあります。この記事では、Elasticベースのアプリを作成する過程で遭遇する可能性のある、最も一般的なゴッチャを扱うシリーズを始める。

シャードの数は変更できない

最初の文書に インデックスAPI:

 $ curl -XPUT 'http://localhost:9200/myindex/employee/1' -d '{".
     「first_name" : "Jane"、
     "last_name" : "Smith"、
     "steet_number":  12
   }'

この瞬間、Elasticはmyindexというタイトルのインデックスを作成してくれます。ここで見えないのは、インデックスに割り当てられているシャードの数だ。シャードは、インデックス全体のドキュメントの一部のインデックス作成、保存、検索を担当する個々のプロセスとして理解することができます。文書のインデックス作成プロセスにおいて、elasticは文書をどのシャードで見つけるべきかを決定する。これは以下の式に基づいている:

shard = hash(document_id) % number_of_primary_shards。

これで、ドキュメントを含むインデックスではプライマリシャードの数を変更できないことが明らかになった。したがって、最初のドキュメントにインデックスを作成する前に、常に手動でインデックスを作成し、インデックス対象のデータ量に対して十分と思われるシャードの数を指定する:

 $ curl -XPUT 'http://localhost:9200/myindex/' -d '{
     "設定" : {
       "number_of_shards" : 10
     }
   }'

のデフォルト値 シャードの数 これは、インデックス作成中にデータを収集する サーバーを最大5台まで拡張できることを意味する。本番環境では、シャードの値は、予想されるインデックス作成の頻度とドキュメントのサイズに応じて設定すべきである。開発環境やテスト環境では、値を1に設定することをお勧めします。それはこの記事の次の段落で説明する。

比較的少ない文書数でのテキスト検索結果の並べ替え

フレーズで文書を検索する:

 $ curl -XGET 'http://localhost:9200/myindex/my_type/_search' -d
   '{
     "query":{
       "match":{
         "title":"素早い茶色の狐"
       }
     }
   }'

Elasticはテキスト検索を数ステップで処理します:

  1. リクエストのフレーズは、文書がインデックスされたのと同じ同じ形式に変換される: [クイック」、「ブラウン」、「フォックス」]。 ("the "は重要ではないので削除した)、
  2. 索引は、検索された単語の少なくとも1つを含む文書を検索するために閲覧されている、
  3. 一致するすべての文書は、検索フレーズとの関連性の観点から評価される、
  4. 結果は計算された関連性によってソートされ、結果の最初のページがユーザーに返されます。

第3ステップでは、(とりわけ)以下の値が考慮される:

  1. 検索フレーズに含まれる単語が文書中にいくつあるか
  2. ある単語が文書に出現する頻度 (TF - term frequency)
  3. 一致した単語が他の文書に出現しているかどうか、またその頻度(IDF:逆文書頻度) - 他の文書でよく使われる単語であればあるほど、重要度は低くなる。
  4. 文書の長さ

IDFの機能は私たちにとって重要です。Elasticはパフォーマンス上の理由から、インデックス内の全てのドキュメントについてこの値を計算しません。その代わりに、全てのシャード(インデックスワーカー)がそのローカルIDFを計算し、ソートに使用します。そのため、ドキュメント数が少ないインデックス検索では、インデックス内のシャードの数やドキュメントの分布によって大幅に異なる結果が得られる可能性があります。

インデックスに2つのシャードがあり、最初のシャードには「fox」という単語でインデックスされた文書が8つあり、2番目のシャードには同じ単語でインデックスされた文書が2つしかないとします。その結果、"fox "という単語は両方のシャードで大きく異なることになり、誤った結果を生む可能性がある。したがって、開発目的では、1つのプライマリシャードのみからなるインデックスを作成する必要があります:

 $ curl -XPUT 'http://localhost:9200/myindex/' -d
   '{"settings" : { "number_of_shards" : 1 }.}'

"遠い "検索ページの結果を表示するとクラスタが死ぬ

前の段落で書いたように、インデックス内の文書は、まったく個別のインデックス・プロセス(シャード)間で共有される。各プロセスは完全に独立しており、自分に割り当てられた文書だけを扱う。

何百万もの文書を含むインデックスを検索し、トップ10の結果を得るために待機する場合、各シャードはクラスタの ノード検索を開始したその後、各シャードからの応答が結合され、(インデックス全体の中で)検索結果の上位10件が選ばれる。このようなアプローチにより、多くのサーバー間で検索プロセスを効率的に分散することができる。

ユーザーが閲覧できるページ数の制限なしに、1ページあたり50件の検索結果を閲覧できるアプリを想像してみよう。私たちのインデックスは10個のプライマリシャード(各サーバーにつき1個)で構成されていることを思い出してください。

1ページ目と100ページ目の検索結果の獲得がどのようになるかを見てみよう:

検索結果の1ページ目

  1. クエリーを受け取ったノード(コントローラー)は、それを10個のシャードに渡す。
  2. 各シャードは、関連性でソートされた50のベストマッチ文書を返す。
  3. すべてのシャードから応答を受信した後、コントローラは結果(500ドキュメント)をマージする。
  4. この結果は、前のステップの上位50文書である。

検索結果の100ページ目

  1. クエリーを受け取ったノード(コントローラー)は、それを10個のシャードに渡す。
  2. 各シャードは、関連性でソートされた5000のベストマッチ文書を返す。
  3. すべてのシャードから応答を受信した後、コントローラは結果(50000ドキュメント)をマージする。
  4. 私たちの結果は、4901から5000までの前のステップの文書である。

1つのドキュメントのサイズが1KBであると仮定すると、2番目のケースでは、1人のユーザーが100の結果を表示するために、クラスタ内で〜50MBのデータが送信され、処理されなければならないことを意味する。

結果ページが増えるごとに、ネットワーク・トラフィックとインデックスの負荷が大幅に増加することに気づくのは難しいことではない。そのため、「遠い」検索ページをユーザーが利用できるようにすることは推奨されません。インデックスがうまく構成されていれば、ユーザーは最初の検索ページで興味のある結果を見つけるはずであり、クラスタの不必要な負荷から身を守ることができる。このルールを証明するために、最も人気のあるウェブ検索エンジンが閲覧を許可している検索結果ページの数を調べてみよう。

さらに興味深いのは、連続する検索結果ページのブラウザ応答時間の観察である。例えば、Google検索(検索語は "search engine")の個々の検索結果ページのレスポンスタイムを以下に示す:

| 検索結果ページ(1ページあたり10文書)|レスポンスタイム|検索結果ページ(1ページあたり10文書)|レスポンスタイム|検索結果ページ(1ページあたり10文書
|——————————————–|—————|
| 250ミリ秒
| 10 | 290ms |
| 20|350ミリ秒
| 30 | 380ms |
| 38(最後の1本

次のパートでは、ドキュメントの索引付けに関する問題を詳しく見ていきたい。

関連記事

ソフトウェア開発

将来を見据えたウェブ・アプリケーションの構築:The Codestのエキスパート・チームによる洞察

The Codestが、最先端技術を駆使してスケーラブルでインタラクティブなウェブアプリケーションを作成し、あらゆるプラットフォームでシームレスなユーザー体験を提供することにどのように秀でているかをご覧ください。The Codestの専門知識がどのようにデジタルトランスフォーメーションとビジネス...

ザ・コデスト
ソフトウェア開発

ラトビアを拠点とするソフトウェア開発企業トップ10社

ラトビアのトップソフトウェア開発企業とその革新的なソリューションについて、最新記事でご紹介します。ラトビアの技術リーダーたちがあなたのビジネスをどのように向上させるかをご覧ください。

thecodest
エンタープライズ&スケールアップ・ソリューション

Javaソフトウェア開発の要点:アウトソーシングを成功させるためのガイド

outsourcingのJavaソフトウェア開発を成功させるために不可欠なこのガイドを読んで、The Codestで効率性を高め、専門知識にアクセスし、プロジェクトを成功に導きましょう。

thecodest
ソフトウェア開発

ポーランドにおけるアウトソーシングの究極ガイド

ポーランドのoutsourcingの急増は、経済、教育、技術の進歩がITの成長とビジネス・フレンドリーな環境を促進していることによる。

ザ・コデスト
エンタープライズ&スケールアップ・ソリューション

IT監査ツール&テクニック完全ガイド

IT監査は、安全かつ効率的で、コンプライアンスに準拠したシステムを保証します。その重要性については、記事全文をお読みください。

The Codest
ヤクブ・ヤクボヴィッチ CTO & 共同創設者

ナレッジベースを購読して、IT部門の専門知識を常に最新の状態に保ちましょう。

    会社概要

    The Codest - ポーランドに技術拠点を持つ国際的なソフトウェア開発会社。

    イギリス - 本社

    • オフィス 303B, 182-184 High Street North E6 2JA
      イギリス、ロンドン

    ポーランド - ローカル・テック・ハブ

    • ファブリチュナ・オフィスパーク、アレハ
      ポコジュ18、31-564クラクフ
    • ブレイン・エンバシー, コンストルクトースカ
      11, 02-673 Warsaw, Poland

      The Codest

    • ホーム
    • 会社概要
    • サービス
    • Case Studies
    • ノウハウ
    • 採用情報
    • 辞書

      サービス

    • アドバイザリー
    • ソフトウェア開発
    • バックエンド開発
    • フロントエンド開発
    • Staff Augmentation
    • バックエンド開発者
    • クラウドエンジニア
    • データエンジニア
    • その他
    • QAエンジニア

      リソース

    • 外部ソフトウェア開発パートナーとの協力に関する事実と神話
    • 米国から欧州へ:アメリカの新興企業がヨーロッパへの移転を決断する理由
    • テックオフショア開発ハブの比較:テックオフショア ヨーロッパ(ポーランド)、ASEAN(フィリピン)、ユーラシア(トルコ)
    • CTOとCIOの課題は?
    • The Codest
    • The Codest
    • The Codest
    • Privacy policy
    • ウェブサイト利用規約

    著作権 © 2025 by The Codest。無断複写・転載を禁じます。

    jaJapanese
    en_USEnglish de_DEGerman sv_SESwedish da_DKDanish nb_NONorwegian fiFinnish fr_FRFrench pl_PLPolish arArabic it_ITItalian ko_KRKorean es_ESSpanish nl_NLDutch etEstonian elGreek jaJapanese