検索サイトElasticsearchのmatch系のクエリとterm系のクエリを、一覧にして比較してみました。これどっちだったけというところで振り返りやすくなると思いました。検索フィールド指定と検索語で、それぞれ単複どう指定できるか整理しました。Elasticsearchでは、検索語の中のワードはデフォルトORらしいのですが、operatorに"and"を指定してクエリを投げるとANDになります。このORとANDを切り替えられるものを◯をつけました。(正確にいうと、公式リファレンスで、operatorプロパティが指定できると記載があったものに◯をつけたつもりですので、ひょっとするとコレ以外にもあるかもしれません。みる限りORとANDの概念が存在しえるようなもの*1に◯がついているように見えるのでおそらくあっていると思います。)実はクエリのシンタックス例は入れ込んでいないのですが、並べて比較することで、シンタックスのプロパティ階層を思い出しやすくなったと思います。一覧見比べ並べてみることで、これまであまり意識していなかったものに気づきました。複数フィールドにざっくり当たって欲しいが、bool-should記法は少しめんどくさい場合に便利termsのlookupメカニズム:termsは複数の検索語を配列で指定できるが、その配列をある別のインデックスのドキュメントID=1のfollowersフィールドの値とする...というようなクエリ。アプリの変数を介する必要がない。Query」が漏れていた。検索語の指定はtermsに似ている。検索語の配列で指定した配列のうち、minimum_should_match_fieldで指定した個数以上分の配列内の要素ヒットするようなドキュメント。何か便利そうな気もするが、ここでは具体的なユースケースは思いつかなかった。並べてみると分かるのですが...並べてみると分かるのですが...というと少し強引ですが、これだけクエリ種類があるといろいろ考えて欲張ってしまうのですが、検索サイトでは、次ぐらいの方針で良いのではと改めて感じました。フリー検索BOXでは検索語はANDが多数派のような気がします。つまるところ自然語風に検索できますというところを特にウリにしない限り、フレーズ検索は使わない戦略を取っても良さそうです。ORで検索したいようなシーンは、ディレクトリ検索(フリーの検索語ではなく、リンクやラベルを選択して選択状態にする)でカバーする使い分け方がすっきりしそうです。系は、コード値や特定の属性にぴったりヒットさせる場合に使いますが、スコアリングを高めにして、term、termsで検索する。wildcardやregexpやfuzzyは検索結果が0件や少ない場合に、「もしかしての」バリエーションとして追加で検索するという用途に寄せた方がシンプルになるかもしれません。要は、普通の検索はtermとtermsの使用にとどめる設計方針にしておき、個別の重要なユースケース対応が必要な場合は、「詳細検索」等としてワイルドカードが使える検索窓として別メニューにした方が良い(できればそのようなものは設けない方が良い)という気がしました。図でまとめているクエリの一覧。検索語の中の単語の順序に意味があるmatch_phraseなどはANDもORもない。Elasticsearchの検索クエリのチートシートなど。(1)はてなブログをはじめよう!azotarさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。