プランナー兼ディレクターのyumeです。
複数のツール・システムを運用するケースって非常に多いと思うのですが、
だいたいの場合、しばらく経つと
「ツールAでシステムBの情報を検索した結果を取ってきてゴニョゴニョしたい！」
ってなりますよね。
そういうときに、すぐAやBの改修ができるエンジニアに依頼できる状態ならよいのですが、
他の案件にかかりきりで、地味な改修を誰にも依頼できない…ってこともよくありませんか？
そんなときに、Amazon CloudSearchという手段も検討してみてはいかがでしょうか。
こんな要件にオススメ
- 検索対象のデータを出力したファイルを生成できる
- APIで条件検索した結果を取得できるようにしたい
- ただしAPIの自前開発をする余力がない
- (既にAWSを使っていて、新たにアカウント発行とかクレカ登録とかする必要がない)
- (検索対象が膨大なサイズでない)
CloudSearchって？
Amazonが提供している、検索ソリューションを簡単に構築できるサービスです。
日本語のあいまい検索やサジェストの提示ができるので、弊社では以前からサイト内検索に利用しています。
Amazon CloudSearch （クラウド内の検索サービス）| AWS
え！？CloudSearchって文書検索じゃないの！？
CloudSearchと言えば、「日本語解析して単語ベースで検索」「自動入力候補の表示」などの目玉機能があり、なんとなく
「フリーテキストで検索するシーンで使うんだろうな〜」
「複雑な検索するのに向いてるサービスなんだろうな〜」
と思いがち※ですが、属性を利用した単純な検索でも充分利用する価値があります。
※筆者の主観です
例えば、以下のような元データがあったとしましょう。
| ID | テキスト | 日付 | 投稿者 | お店の緯度経度 |
|---|---|---|---|---|
| 1 | ここのカオマンガイ屋は骨入スープが最高。 | 2018-10-10 | A | 35.655898,139.705498 |
| 2 | とにかく餃子がうまい！ | 2018-07-10 | B | 35.666781,139.750832 |
| 3 | 2度食べてハマる麻婆豆腐。 | 2018-04-10 | C | 35.667239,139.752888 |
| 4 | 個人的にこの近辺で一番魚がうまい。 | 2018-01-10 | C | 35.669347,139.738818 |
(どの店も私のオススメなので、都内の方は緯度経度から検索してぜひ行ってみてください♡)
この場合、CloudSearchでは以下のことがすべて開発なしでできるので便利です。
- 食べ物の名前で検索する(あいまい検索もOK)
- テキストの一致度や日付で並び替えをする
- 投稿者が完全一致した場合のみに絞り込み
- 緯度経度の範囲を指定して絞り込み
上2つのイメージが強いですが、単純な絞り込み検索や、空間検索もできるので汎用性は高いです。
「自宅から半径◯キロ以内で！」に近いこともできそうですね。
Amazon CloudSearch での地理的位置による検索および結果のランク付け - Amazon CloudSearch
ざっくり手順
詳しくはAmazonのヘルプを参照してください〜ここでは流れのイメージだけ(๑•̀ㅂ•́)
1. Amazon CloudSearchで検索ドメインを作成する
- AWSのコンソール上でポチポチ設定する
- 必要に応じてアクセス制限を設定
Amazon CloudSearch ドメインの作成 - Amazon CloudSearch
2. 必要なフィールドと型を洗い出す
下記のようなフィールドが必要になるかと思います。
- 検索条件になるフィールド
- 検索結果に必要なフィールド
それぞれのデータが何型か(日付型なのかテキスト型なのか)を検討します。
3. 作成したドメイン上で、フィールドを設定する
- コンソール上でポチポチ設定する
- 型によってデータの表記法が決まっている(特に日付型)ので、データ作るより先にこちらを決めるのがオススメ
Amazon CloudSearch ドメインのインデックスフィールドの設定 - Amazon CloudSearch
4. 上記に合わせた検索用データを用意する
Amazon CloudSearch 用にデータを準備 - Amazon CloudSearch
5. 検索用データをアップロードする
ここまで対応すると、API経由で対象データを検索できるようになります！
絞り込み検索のイメージ
コンソール上の「Run a Test Search」で、検索結果をプレビューすることができます。
全件検索するには、"Search:"に「*:*」を入れ、"Options"の"Query Parser"を「Lucene」に変更します。
Searchには通常、検索したいテキストを入力しますが、全件の場合(テキスト検索をしない場合)は「*:*」と指定するようです。
Search欄についてですが、ここで指定したテキストは、単純に検索可能なフィールド全体が検索対象となります。
時に、完全に一致していないレコードもヒットして返ってきますし、検索対象となるフィールドを指定することもできません。
一方で、「このフィールドがこの値に完全一致したとき」という条件で検索したい場面もあると思います。
というか、「えっ…単純にRDBMS的に検索条件セットするので充分なんだけど…」ということのほうが多いと思います。
この場合は絞り込み検索です。
絞り込み検索を行うには、"Filter Query"に条件を指定していくことになります。
投稿者がCのレコードのみを検索するには、以下のようにします。
「この検索結果をAPI経由で取得するにはどうすればいいんだ？」となった場合は、
同じページ内の「JSON」リンクをクリックすると以下の画面が表示できます。
赤矢印の箇所が該当の検索リクエストになっているので、コピペして連携させたいシステム側からcurl等で叩いてあげればOKです。
料金
料金はインスタンスのサイズと起動時間でほぼ決まります。
詳細は以下のページが非常にわかりやすいです。(ちょっと古いですが)
Amazon CloudSearchの見積方法について | ナレコムAWSレシピ
安く済ませるには、使わないときはインスタンスを停止させればいいじゃん！と思いましたが、
どうやら削除か起動かしかないようです。
予めデータ量などが分かっている場合は、以下のツールで試算するといいと思います。
Amazon Web Services Simple Monthly Calculator
まとめ
以上のように、プログラミングをすることなく検索用DBを持てる点と、即座にAPIが利用できる点が、CloudSearchの便利なところです。
また、リクエストやアップデートに応じたスケーリングも勝手にやってくれるので、その点は楽です。
ですが、データの二重管理になってしまう、コスト試算がしづらい等、長年運用するケースに不向きな面もありますので、
状況に合わせて選択肢の1つになるかもなというくらいでのご紹介でした。
こういう状況でむしろこうしたほうがいい、このツールもオススメ、というものがあればぜひ教えてくださいm( )m
＼\ 『明日のはたらくを創る』仲間を募集中!! /／ 919.jp
