4

RDBMSの現状

主に検索目的で使用されるエンタープライズ環境に、30〜40列のレガシーRDBMSテーブルがあるとします。実生活ではいくつかのテーブルがあるかもしれませんが、それを単純に保ちましょう。私には数十、場合によっては数百もの異なるプログラムがあり、それぞれがこのテーブルに対して独自のクエリを実行し、それぞれがわずかに異なるフィールドのセットを調べています。

現状が痛い理由

  1. 私たちのDBAは、それぞれに対応するようにインデックスを調整することで、これらのさまざまなクエリがすべて適切に機能するように努めています。
  2. DBAは、インデックスを確認できるように実行される新しいクエリを知りたいので、開発者とDBAの間には不信感があり、開発者はできるだけ早く新機能をプッシュしたいと考えています。
  3. ポイント2は、DBAが最初にパフォーマンスを評価する機会を確実に得ることができるように、開発者に静的にバインドされたすべてのクエリを使用するように強制する取り組みに要約されることがあります。

うーん...

これはESインデックスとどのように比較されますか？

したがって、elasticsearchインデックスの30〜40列すべてにインデックスを付けるとすると、RDBMSインデックスのセットとほぼ同じパフォーマンスの方法で、1つの用語または複数の用語のいずれかを検索できるというのは本当ですか？

4

1 に答える 1

5

したがって、elasticsearchインデックスの30〜40列すべてにインデックスを付けるとすると、RDBMSインデックスのセットとほぼ同じパフォーマンスの方法で、1つの用語または複数の用語のいずれかを検索できるというのは本当ですか？

要するに、はい。

Elasticsearchでは、これらのフィールド/列に「列挙型」タイプのデータ（、、など）が含まれていて、全文検索を使用してクエリを実行したくない場合は、フィルターを使用することをお勧めします。 。（全文検索の追加は簡単ですが、適切なアナライザー、ユーザー検索パターンなどのトピックについて事前に検討する必要があります。）statusgenderdepartment

termここでフィルターを使用するとします。

curl localhost:9200 -d '{
  "query" : {
    "filtered" : {
      "filter" : {
        "term" : {
          "department" : "marketing"
        }
      }
    }
  }
}'

現在、用語フィルターは、特定のドキュメントがこのフィルターに一致するかどうか（1/0）に情報を格納するビットセットを生成します。このビットセットには、3つの重要な機能があります。a）非常にコンパクト、b）非常にキャッシュ可能、c）ビットセット操作でフィルターを組み合わせることができます。

Elasticsearchは、このフィルターへのアクセスを高速化するためにフィルターキャッシュを使用します。

フィルタとビットセットの良いところは、少し異なるクエリを実行する場合です。

curl localhost:9200 -d '{
  "query" : {
    "filtered" : {
      "filter" : {
        "bool" : {
          "must": [
            "term" : {
              "department" : "marketing"
            },
            "term" : {
              "status" : "active"
            }
          ]
        }
      }
    }
  }
}'

部門フィールドのフィルターは再利用されてキャッシュからロードされ、新しいキャッシュされたビットセットがステータスフィールドに作成され、次回は両方がキャッシュからロードされ、ビットセット操作で評価されます。

ElasticsearchはWarmerAPIを提供するため、既知のクエリを使用してキャッシュを非常に効果的に「プリロード」できます。

フィルタキャッシュの統計は、NodesStatsAPIの一部です。

于 2013-03-05T08:54:42.583 に答える