AWS CloudSearch
https://gyazo.com/69245538a78a06ceba574292bd4efa48
所感: 特定のユースケースに特化した検索サービスを開発したい場合は CloudSearch を利用するのが良さそうに思える。DB に対する汎用的な検索システムを利用したい場合は、テーブル数に従ってドメインも増える。インデックスフィールドに重複したデータをもたせてテーブル数を少なくすればいけそうだけど、そこまでする価値があるのだろうか。
Amazon CloudSearch
検索機能をアプリケーションに簡単に追加するためのサービス、というように読める。
Amazon CloudSearch は AWS クラウドにおけるマネージド型サービスであり、ウェブサイトまたはアプリケーション向けの検索ソリューションを容易かつコスト効率良く設定、管理、スケールできます。
用語
検索ドメイン
検索のエンドポイント
以下を保持する
スケーリングオプション : インスタンスタイプ等
インデックス作成オプション : インデックスフィールドの集合
分析スキーム : WIP
アクセスポリシー : その名の通り、アクセス制限のためのポリシー記述
コレクション (コーパス)
検索対象のデータの集合
以下のいずれかである必要がある
構造化されていないフルテキストドキュメント
XML 等のマークアップ言語で記述された半構造化ドキュメント
厳密なデータモデルに準拠する構造化データ
ドキュメント
検索対象データ
例えば、投稿されたコメント群や、Web ページのテキスト群
インデックス
検索用のインデックス
複数のインデックスフィールドの集合
table:インデックスフィールドの項目
項目名 概要
Type データ種別。int, date, text, array 等
Search そのフィールドが検索可能かどうか
Facet WIP
Return 検索結果に含めるか
Sort そのフィールドでそーとするかどうか
Highlight テキスト内でマッチした文字列をハイライト表示するか
Anarysys Scheme フィールドがテキストの場合に利用する ストップワードやシノニム等の設定
Default value 初期値
Source field WIP
検索の仕方
検索対象のデータの準備として、検索ドメインに対して ドキュメントをアップロード する。ドキュメントは JSON, XML, CSV, TXT のいずれかで表現する
アップロード対象のデータは、ローカル/S3/DynamoDB/定義済み のいずれかから選択できる
検索ドメインのインデックス作成オプションに従って、ドキュメントから検索用のインデックスが作成される
ここの仕組みは詳しくわからないが、おそらく単純にフィールド名が一致していると対応づけられるのだと思う
インデックスに対してクエリを送信し、結果を取得する
クエリパーサーは simple、structured、lucene、dismax のいずれかから選ぶことができる
料金
課金対象は以下
インスタンスの起動時間あたりの課金
時間毎に $0.3 くらい。
ドキュメントのアップロードリクエスト毎の課金
1000 件毎に $0.1 なので、これが割と高そう
インデックス再構成毎に、格納されたデータ量あたりの課金
GB あたり 1 USD くらい
CloudSearch へのイン/アウト通信量あたりの課金
GB あたり $0.1 にみたないくらい
制限
インスタンスは削除のみで、休止はできない
バッチの最大サイズは 5 MB
ドキュメントの最大サイズは 1 MB
ドキュメントの最大フィールド数は 200
検索ドメインにおけるインデックスフィールドの数は最大 200
AWS アカウント毎に検索ドメインは最大 100 個
等々
CloudSearch のメリット
RDBMS VS CloudSearch
RDBMS は、全文検索しようとして Like 句を使うと重いし、重み付けや近さ等の要素を検索で利用できない
CloudSearch は、テーブルジョイン等は行えない
２つの組み合わせ
リレーショナルなクエリは RDBMS
テキストクエリは CloudSearch
デメリット: 複雑さ
動作するコンポーネントが増える
同期の問題
ユースケース
従量課金制で、コストパフォーマンスが良い
トラフィック、データにあわせた自動的なスケーリング
可用性の高い検索機能の提供
検索時間の短縮
多彩な機能
自動入力、ヒットの強調表示、地理空間検索