Asset Publisher

null 【前編】開発者の視点から見たLiferay 7.2の検索機能

技術者向け7.2検索

【前編】開発者の視点から見たLiferay 7.2の検索機能

Liferay 7.2で強化された検索機能について、開発者の視点から取り上げてみます。

はじめに:テクニカル記事ごとに必要な知識レベルについて


本記事は以下の知識レベルの方たち、ユースケースが対象です。


■ 本記事対象の知識レベルとユースケース

  • 中級レベル
  • 一般的なLiferay DXP開発に必須

検索機能のトピックは広範囲に渡るため、日本語版では、前編と後編に記事を分けてお届けしたいと思います。なのでまずは前編です。

後編は、数日後にアップ予定です。

Liferayの検索とインデックス作成のドキュメントをネットで検索してみると、多くの情報が見つかるかと思います。その中でもインデックス作成とカスタムエンティティの検索をサポートする方法に関しては、情報が少ないと感じました。

このブログエントリでは、Liferayのドキュメントサンプルを元に、インデックス作成とカスタムエンティティの検索に関して詳しく書いてみようと思います。このエントリを読み終わるころには、インデックスと検索をLiferayで利用するための必要な知識が得られるかと思います。

まずはLiferayがそもそも外部検索インデックスエンジンを使用している理由を理解しましょう。

検索が解決するもの


※本記事はLiferay Community Blogに投稿されている”Understanding Search from a Developers Perspective”を翻訳したものです。配信元または著者の許可を得て配信しています。
※オリジナルの英記事著者:David H Nebinger サウスカロライナ州のサマーヴィルに住むLiferay, Inc.のSoftware Architect/リードコンサルタント。Liferay Communityサイトにて、多くの技術情報を投稿するなど精力的に活動しています。

Liferayがデータストアとは別の検索インデックスを保持している理由は、OracleやMySQLなどの標準的なリレーショナルデータベースでは、実際には非常に困難で(時には少なくとも実用的な意味では)不可能なことがあるからです。

検索インデックスは、データの「列」に関係なく、キーワードまたはフレーズのドキュメントを照合するために使用されます。

例えば、大きなテキストブロックを含む5列のデータベースのテーブルを考えてみましょう。テーブルの列の例として、製品名、説明、インストール手順、リサイクルオプション、販売パンフレットの内容などが考えられます。

「キーレスエントリ」などのフレーズを検索したいが、5つの列のいずれかで一致させたい場合、次のような結果になります。


SELECT * FROM mytable WHERE
  (prod_name LIKE ‘%keyless entry%’) OR
  (description LIKE ‘%keyless entry%’) OR
  (install_instr LIKE ‘%keyless entry%’) OR
  (recycling LIKE ‘%keyless entry%’) OR
  (brochure LIKE ‘%keyless entry%’)

これはすでにかなり煩雑ですが、キーワード「キーレス」または「エントリ」を検索する場合はどうなりますか?比較的単純な追加条件を追加しはじめると、クエリの保守性も低下し始めます。

また、データベースに複数のテーブルがあり、複数のテーブル間で一致した結果を結合したい場合はどうでしょうか?特定のタイプのクエリでは、通常のSQL-92データベースでは実行できないか、非効率になり、場合によっては不可能になります。

検索インデックスの出番


検索はテーブル列ではなくドキュメントに対して行われるため、検索インデックスはこの問題を解決します。

検索に含まれる、または検索から除外されるフィールドを制御できることは知っていますが、ここでは理論にまずは注目してみましょう。

検索インデックスの用語では、テーブルの各レコードは、検索インデックスのドキュメントと呼びます。ドキュメントには、テーブルの列に1対1で対応するフィールドか、生成した値(数値コードを文字列ラベルに変換など)か、もしくは必要な子データをドキュメントに含める親/子テーブルリレーションの値が含まれる場合があります。

フレーズまたはキーワードの検索が実行されると、検索インデックスは、一致するフィールドに関係なく、一致するドキュメントを検索します。このように、新しいキーワードまたはフィールドまたはドキュメントが追加されても、クエリの複雑さは変わりません。

複数テーブルのシナリオでは、異なるテーブルのレコードが同じ検索インデックスに含まれます。 NAMEやDESCRIPTIONなどの共通フィールドは、異なるドキュメントタイプで再利用されるため、NAMEフィールドで「キーレスエントリ」を検索すると、一致するすべてのテーブルから結果が得られます。

テーブルに固有のフィールドについては、インデックス作成のために追加できますが、クエリを検索する場合、追加のフィールドを含めるようにクエリを変更する必要がある場合があります。

開発者の視点


開発者の観点に戻ると、このすべての目標は、ユーザーがLiferayで検索を実行したときに、Liferayエンティティと同じ方法でエンティティを見つけて照合できるように、エンティティを検索インデックスに入れることです。

以下にLiferayの公式ドキュメントに書いてある意味がどういうことか、例を説明してみましょう。

モデルエンティティフィールドをインデックスに提供する

検索キーワードに一致させるために、インデックスに保存したエンティティの、どのフィールドをに取得するかを示しています。

公式ドキュメント

再インデックスとバッチインデックスの動作を構成する

Liferay管理者がすべてのインデックスを再作成する際に、カスタムエンティティを再インデックスするのに何が必要かを示しています。

公式ドキュメント

モデルエンティティの用語をクエリに追加する

カスタムエンティティに定義したカスタムフィールドを検索クエリに追加して、確認する方法を示しています。

公式ドキュメント

Liferayが検索結果を事前にフィルタリングする

検索結果に含みたくないレコードをフィルタする方法を示しています。

公式ドキュメント

結果の概要を作成する

検索結果に表示される、エンティティから生成された概要を制御する方法を示しています。

公式ドキュメント

検索サービスの登録

カスタム実装した検索サービスをLiferay上のインデックスインフラストラクチャで利用可能にし、検索結果に反映する方法を示しています。

公式ドキュメント


前編はここまで

いかがでしたかでしょうか?
検索の紹介、前編はひとまずここまでです。インデックスの詳しい実装方法の紹介は、後編へつづきます!

 

記事に関するご意見、ご感想などございましたら、お気軽に[email protected]までご連絡ください。


■ Liferay Japan User Groupスラックを開設しました。製品に関する質問、設計に関する疑問などでもこちらにポストしてください!
https://liferay-community.slack.com/messages/C7P2GV5RA

■ これまで発信してきた日本語による技術コンテンツを、Qiitaでお読みいただけます。よろしければそちらの記事も合わせてご役立てください。
https://qiita.com/yasuflatland-lf

■ Twitterでも公式プレスリリースやなどの情報を発信しています。
https://twitter.com/LiferayJapan

Doorkeeperのライフレイコミュニティメンバー大歓迎!
コーポレートブログの技術コンテンツ更新情報など定期的におとどけしています。
https://liferay.doorkeeper.jp/

Upgrade - jp banner - gartner

業界最高の評価

Gartner Magic Quadrant Digital Experience Platforms 2019

Gartnerレポート:『リーダー』に位置づけ

ライフレイは9年連続で、Gartner社によるデジタルエクスペリエンスプラットフォーム(DXP )分野のマジック・クアドラントにおいて、リーダーに選出されました。

ガートナーは、ガートナー・リサーチの発行物に掲載された特定のベンダー、製品またはサービスを推奨するものではありません。また、最高のレーティング又はその他の評価を得たベンダーのみを選択するようにテクノロジーユーザーに助言するものではありません。ガートナー・リサーチの発行物は、ガートナー・リサーチの見解を表したものであり、事実を表現したものではありません。ガートナーは、明示または黙示を問わず、本リサーチの商品性や特定目的への適合性を含め、一切の責任を負うものではありません。

レポートの詳細

Upgrade - jp common footer contact or demo