サイトの全文検索のためにCloudSearchを使う、と決めたのはよいものの、取っ掛かりに苦労したので、とにかく「インスタンスをたてる」→「ドキュメントを登録する」→「検索して結果を取得する」までのなんとなくの流れを超ざっくりとメモ書き。そのうちちゃんとまとめたい。
参考にしたリンクとか書籍とか
- 公式
- Amazon CloudSearch ドキュメント
- Amazon CloudSearch でのデータの検索 - Amazon CloudSearch
- うまいこと検索できないとね…
- Amazon CloudSearch でのデータの検索 - Amazon CloudSearch
- CloudSearch — Boto 3 Docs 1.9.166 documentation
- CloudSearchDomain — Boto 3 Docs 1.9.166 documentation
- endpointの指定の記述がないような……後述の記事を参照
- Amazon CloudSearch ドキュメント
- 書籍
- 「Elasticsearch実践ガイド」の第4章まで
- 記事
とりあえずやってみる流れ
知識
基礎知識をどれくらい抑えるかは悩みどころだと思うんだが、しかしチュートリアルをやってもなにをやっているのかさっぱりわからないのでは甲斐がないので、やはりある程度は抑えておく必要があるだろう。
これについては、書籍「Elasticsearch実践ガイド」の4章くらいまでを卒読しておけば、何をしているのかなんとなく想像がつくようになる……のではないかな、多分。
チュートリアル
この手のやつは習うより慣れろの側面があるので、とにかく手を動かして感覚を掴む。「Amazon CloudSearch の使用開始 - Amazon CloudSearch」のチュートリアルで、ドメインを作る、削除する、ドキュメントを登録する、検索する、削除する、の一通りの操作を体験してみる。
慣れたら、コンソールからインデックスをいじってみて、変更が反映されるのにどれくらい時間がかかるか見てみたり、ドメインをmanualで作ってみたり、色々試す。
AWS CLIとboto3で慣れる
一通り慣れたら、ドキュメントの登録・検索・削除をAWS CLI経由でやってみる。問題なければ、今度はboto3でやってみる(Python使いなら)。boto3のほうが色々楽かなと思う。
考えどころいくつか
ポリシー
CloudSearchはその性質上、アカウントオーナー以外からもアクセスがあることを想定しているのか、リソースベースのポリシーについて設定できる(「IAM ロールとリソースベースのポリシーとの相違点 - AWS Identity and Access Management」)。コンソール画面にあるAccess Policiesがそれ。最初、これなんのために書くんだ?と悩んだのだが、たしかにまぁ他アカウントや完全なる匿名ユーザーからの利用も考えられるサービスなので、こういうのがあるのかな、と理解。僕の使い方だと管理者ないしLambda経由でのアクセスで、いわゆるクロスアカウントについて考える必要もなかったので、設定しなかった(これだとcurlがとおらなくなるので、事業所のIPアドレスの許可くらいはしてもいいかもしれない)。
ID
各ドキュメントにユニークなIDをつける必要がある。複数の属性を繋ぎ合わせる、DynamoDBっぽいIDの付け方がよいかと思った。
リテラル、date型、int、doubleか
型は検索の利便性に関わるので、どうするかけっこう考えどころ。全部text or literalにしてしまってもいいような気がするが、やはり数値はint or doubleであろうし。日付については、RFC3339などのフォーマットで文字列でやるのがよいのか、それともdate型に対応させる形にするのがよいのか、どちらがよいのか悩ましい。DynamoDBは時刻型が存在せず、文字列でそのまま格納してしまっているので、当面はtextにしてしまっているが、さて……。
コメント