Searchを紹介します。Search上に検索用データベースを構築してデータを検索できるようになるまでの手順について説明します。Service)です。全文検索とはその名の通り全ての文を対象として検索を行うことで、RDBのwhere句のようにカラムを指定することなくデータを検索することが可能です。身近な全文検索の例としては、GoogleやBing等の検索エンジンサービスがあります。検索エンジンサービスでは検索キーワードをユーザが入力すると、そのキーワードがタイトルや本文中に含まれるWebサイトが検索結果として表示されます。全文検索では、このように各Webサイトの構造が全く異なるものであっても検索を可能とするために、検索対象データの保存方法と検索方法に工夫を施しています。全文検索には、主に以下の表に挙げた機能が備わっています。SDKを通じて使用することができます。Searchの機能のデモサイトでは、これらの機能が実際のWebサイト上でどのように使われているのかをガイダンス付きで紹介しているので、是非確認してみてください。Searchは前述した全文検索の機能以外にも、いくつかの独自の機能や特徴をサポートしています。日本語のように人が用いる自然言語の文章を適切な単語に分割して全文検索で利用できるようにする処理です。SearchではBingやOfficeといった他のMicrosoft製品でも使用され、実績のある自然言語解析ライブラリを使用することができます。Searchは、PaaSであることからインフラ部分の管理がAzureによって担保されているため、素早くサービスを開始することができます。DBやBLOBストレージなどのAzureのデータベースサービスを選択することが可能です。Searchからデータソースを自動でクロールしてインデックスにアップロードできます。クロールは、スケジュール指定での起動や、データソースの変更検知による起動から選択することができます。Searchのスケールには、検索に対するレスポンス性能のスケールと、データ容量に対するスケールの2種類のスケールがあります。Searchのインスタンスを増減させることで、多重の検索リクエストによる負荷の分散を行います。Searchのストレージの増減によって、インデックスに保存できるデータのサイズをスケールさせることができます。レプリカとパーティションのスケールは、Azureポータルの画面上から簡単に行うことができます。Searchではこれらの機能や特徴によって、全文検索の専門的な知識なしでも比較的容易にな検索アプリの構築が可能となっています。PaaSであるため、インフラ部分は完全マネージドのため運用管理コストも削減することができ、アプリ・サービス開発に集中できるようになっています。全文検索の処理フロー(インデックス作成フロー)次は、全文検索の処理フローを説明しながら、全文検索に用いられる用語の解説も行っていきます。全文検索には、大きく2つのステップがあります。1つ目は全文検索の対象となるデータソースである「インデックス」の作成フロー、2つ目はユーザが検索キーワードを入力し実際に全文検索を行う検索フローです。以下の図は、インデックス作成のフローです。Searchのインデックス作成フロー(1)データソースインデックスに保存するデータの元となるデータです。データソースはファイルやデータベースなど、様々なものを使用することができます。SearchのインデックスにはJSON形式でデータを追加していくため、JSON形式に変換可能なデータであればデータソースとして使用することができます。(2)インデクサーデータソースのデータは「インデクサー」にインポートします。インデクサーでは、データソースに含まれるテキストを「アナライザー」を使って加工し、インデックスに登録する単語に形式を整形する役割を持ちます。DBなどの他のAzureサービスをデータソースとして選択した場合は、インデクサーは自動でこれらのデータソースからデータを取得するように設定することができます。このパターンを「プル型」と呼びます。SDKを使ってプログラムから明示的にデータを追加する方法を「プッシュ型」と呼びます。プッシュ型の場合はデータソースの種類に制限はありません。「アナライザー」は前述の通りデータソースに含まれる文字列を単語の単位に分割したり、文字のゆらぎを正規化するなどしてインデックスに登録する形式にしていきます。アナライザーで処理された単語は一般的に「トークン」と呼ばれます。文字列を単語に分割する方法ですが、英語のようにスペースで単語を区切る文法の言語は簡単ですが、日本語のように単語同士が続いて文章となる文法の言語の場合は工夫が必要となります。Searchでは、言語ごとの特徴に対応するために各言語に特化したアナライザーが用意されています。日本語の場合は「Luceneアナライザー」と「Microsoftアナライザー」の2種類からアナライザーを選択することができます。Luceneというオープンソースの全文検索ライブラリで使用されている日本語アナライザーです。Microsoftアナライザーはその名の通りMicrosoftが作成したアナライザーで、これはOffice製品やBingといった他のMicrosoft製品の中でも利用されています。Search用のデータベースという位置づけです。全文検索のインデックスは「転置インデックス」と呼ばれるデータ構造でトークンを保存します。転置インデックスは、キーにトークンが入り、値にそのトークンが含まれる文章やデータの宛先がリストで入っているデータ構造となっています。本の索引をイメージすると分かりやすいかと思います。転置インデックスは、あるキーワードが含まれるデータを探し出すことに特化しているため、全文検索のインデックスとして最適なデータ構造となっています。Searchのインデックスでは、検索した結果取得できるデータの最小単位を「ドキュメント」と呼びます。ドキュメントは複数のフィールドから構成されており、フィールドは名前や年齢などの項目で定義していきます。インデックスとドキュメント、フィールドは、RDBのテーブルと行、列とほぼ同じものと捉えることができます。全文検索の処理フロー(検索フロー)つづいて、ユーザーが検索を行う場合の処理フローを説明します。Searchに渡します。検索クエリはまず「クエリパーサー」で処理されます。Search内部のクエリ形式である「クエリツリー」に変換して「検索エンジン」に渡します。検索エンジンはクエリツリーを使ってインデックスからデータを取得します。検索エンジンは、データの取得後にデータを関連度順に並び替えするランキング処理を行い、ユーザに結果を返します。APIから検索ができるところまでの手順を説明します。Searchが用意しているサンプルデータをインデックスに取り込んでいきます。Searchを選択します。Searchサービスの画面に遷移後、追加ボタンから新たにSearchサービスを作成します。Searchを選択する新規作成画面では、任意のURLとリソースグループを入力し、お手持ちのサブスクリプションを選択します。西日本のみ選択可能となっています。価格レベルは今回は無料の「Free」を選択します。価格レベルを変更することで、Searchサービスが利用できるインデックスの数、レプリカやパーティションの数も増減させることができます。全ての項目を入力・選択後に「作成」ボタンでSearchサービスの新規作成を開始します。開始後しばらくすると作成が完了します。次はインデックスの作成です。インデックスはまず保存するドキュメントとそのフィールドの定義をし、その後で実際にデータをアップロードしていきます。Searchのダッシュボード画面に移動します。ダッシュボードの上部にある「データのインポート」を選択します。「データのインポート」からインデックスを作成する場合は、プル型でのインデックス作成方式となります。プッシュ型でインデックスを作成する場合は、「データのインポート」の左隣にある「インデックスの追加」からフィールド定義を行いインデックスを作成していきます。「データのインポート」画面ではまずデータソースを選択します。「データソース」を選択すると接続可能なAzureのデータベースサービスが表示されます。今回はサンプルデータでインデックスを作成しますので、「サンプル」を選択し、「realestate-us-sample」というアメリカの物件情報のサンプルデータが入ったデータベースを選択します。「選択」をクリックすると、「インデックス」の編集画面に移動します。ここの画面では、先ほど選択したデータソースからスキーマ情報を収集して、自動的にフィールド定義として表示してくれます。DBのようにスキーマ定義を持たないデータソースを選択した場合は、表示されているフィールドに過不足が生じている可能性があるので、その場合は手動でフィールドの追加や削除を行って下さい。フィールドでは、以下の項目を編集することができます。データに含める場合にチェックを入れるフィルター可能このフィールドで絞り込み検索をする場合にチェックを入れるソート可能このフィールドで並べ替えをする場合にチェックを入れるファセット可能ファセットナビゲーション(サイト側であらかじめ設定する、カテゴリー別、価格別、レビュー別等でフィルタリングした検索条件のナビゲーション)に含める場合にチェックを入れる検索可能ユーザからの検索時にヒットさせたいフィールドの場合にチェックを入れるまた、フィールド定義の上部にある「アナライザー」にチェックを入れると、フィールドごとにアナライザーを変更することができるようになります。「提案者」にチェックを入れてフィールドにもチェックを入れることで、そのフィールドをインクリメンタルサーチに対応させることができます。今回はすべてデフォルトの状態で「OK」ボタンを選択します。「インデクサー」の作成画面に移動し、最後にインデクサーを作成します。必須項目のインデクサー名のみ入力して「OK」を選択します。今回は設定しませんが、任意項目の「スケジュール」では、このインデクサーの実行をスケジュール化し、定期的にインデックスを更新できるようにすることができます。「詳細オプション」ではインデクサー実行時のエラーの許容回数などを指定することができます。インデクサーの作成インデクサーの作成後、「データのインポート」画面下部の「OK」ボタンを選択するとウィザードが終了し、Searchサービスのダッシュボード画面に戻ります。この間に、バックグラウンドではインデクサーが実行されてインデックスにデータが登録されています。インデクサーの実行履歴は、ダッシュボード画面の下部にある「インデクサー」から確認することができます。インデクサーの実行履歴ダッシュボード上のインデクサーを選択すると、インデクサーの実行結果画面に遷移します。以下の図では実行結果がエラーとなっていますが、これはFreeプランでSearchサービスを作成した際の制約によるものです。Freeプランではインデクサー1回あたりの実行時間が1分に制限されてしまうため、データソースから全てのデータをインデックスにアップロードできずにエラーとして扱われてしまいました。サンプルのインデックスであること、またサンプルデータソースにはデータが5000件含まれており、そのうちの数十件のみが取り込みに失敗しただけのため、今回はこのまま説明を続けます。Freeプランより上位のプランを使用すると、インデクサーは最大24時間稼働することができるので、本運用をされる場合はFree以外のプランを選択し、またエラーについては詳細を確認して対応されることをお薦めします。上記の通りプランの制約のため一部取り込めなかったデータもありますが、検索をするには十分の量のデータがインデックスにアップロードされました。APIを使って検索を行ってみましょう。APIの実行と結果の確認を行うことができます。Searchサービスのダッシュボードの上部にある「検索エクスプローラー」を選択すると簡易的な検索画面が表示されます。「クエリ文字列」の部分に検索キーワードやクエリパラメータを入力して「検索」ボタンを選択すると検索が実行され、結果が画面下部の「結果」フィールドにJSON形式で出力されます。試しにクエリ文字列に「seattle」と入力して検索を実行してみましょう。実行するとJSONのデータが「結果」フィールドに表示されたかと思います。JSONデータを見ていくと、「city」のフィールドに「Seattle」という文字列があることが分かります。検索時にフィールドの指定はしていませんでしたが、都市がシアトルの物件情報を取得することができました。これが全文検索の特徴です。今回のサンプルデータでは「seattle」という文字列は全てcityフィールドに含まれていますが、仮にcity以外の検索可能なフィールドに「seattle」という文字列が入ったデータが存在する場合は、そのデータも取得することができたでしょう。クエリ文字列に入力した文字は全て小文字の「seattle」であるのに対し、結果として取得されたデータ内の文字列は先頭が大文字の「Seattle」であることに注目して下さい。コンピュータからみるとこの2つの文字列は全く異なるものとなるため、そのまま検索をしてもヒットしません。この問題を解消しているのがアナライザーです。Searchの内部では全て小文字の「seattle」に統一されて検索が行われます。「sEAtTlE」のような大文字と小文字が混在した文字列で検索をした場合も同様の結果となることを確認してみましょう。取得されたデータの件数を確認できるクエリパラメータを付与し、「sEAtTlE&$count=true」という文字列で検索します。「@odata.count」というフィールドに取得件数が表示されますが、この件数が先ほどの全て小文字の場合の取得件数と同じになっているかと思います(全て小文字の場合の件数は「seattle&$count=true」で確認します)。クエリ文字列にクエリパラメータを追加して、より細かい検索条件で検索を行ってみましょう。「filter」を使用すると、指定した条件にマッチするデータのみ取得することができます。filterを使用する場合は対象のフィールドを指定する必要がある反面、比較演算子を使用することができるため絞り込みの条件を細かく調整する事が可能です。