dotti

こんにちは、mikotoです。

AWSには CloudSearchElasticsearch Service の2つの全文検索サービスがあります。
今回は、この2つを比較してみます。

ベースはほとんど同じ

SolrElasticsearch のどちらもLuceneという検索エンジンをベースにしており、検索に関してはほとんど同じことができるのとと同様に、CloudSearchElasticsearch Service でもほぼ同じことができます。
CloudSearch はベースのエンジンを明言してはいませんが、 Lucene のクエリパーサーが使えたり、利用できる型がほぼ同じであったりすることから、大部分が Lucene を参考にしていると思われます。
若干の癖がありますが、 SolrElasticsearch の経験があれば、 CloudSearch の利用はすんなり行くかと思われます。

CloudSearchの強み

なんと言ってもフルマネージドサービスであることが、CloudSearchを使う最大の理由です。
つまり、 導入運用 が非常に楽になります。
以下に、CloudSearchが供えるフルマネージドな点を解説します。

スケーリング

CloudSearchは、状況に応じてインスタンスの数とインスタンスタイプを自動で調整します。
どのような時にインスタンスの数とタイプが調整されるかは、 Amazon CloudSearch での自動スケーリングを参考にしてください。

フィールド設定

検索エンジンを導入するにあたり、多くの場合は日本語や英語などのテキストを検索する必要があります。
CloudSearchは、例えば日本語であれば Japanese というAnalysis Schemeを選択するだけで可能です。
その他のサービスのようにXMLやJSONで初心者にとっては見慣れない設定項目を記述する必要はありません。
(もちろん、JSONで設定項目を記述することもできます)

他にも、ダイナミックフィールドなどの高度な機能も特定の命名規則に従ってフィールドを設計するだけで良く、array型のような複数要素からなるフィールドをサポートしていたりと意外と機能もリッチです。

辞書の管理

日本語や英語などのテキストを検索する際に、下記に示すような 辞書 を導入する必要があるケースがあります。
これは、サービスのドメインによって異なるため、検索精度を上げて行くために個々にチューニングを繰り返さなければならない項目になります。

  • Stopwords: 意味の無い語として検索対象から除外する単語。
    • 例) です,ます
  • Stemming: 基本形化。動詞の活用系などによる表記違いを吸収する。
    • 例) 食べた → 食べる
    • (ドメインによっては厳密にはStemmingではないが統一化したいものを登録するケースもある)
  • Synonyms: 同音異義語。異なる単語での表記であっても同じものとして検索対象にしたい単語グループ。
    • 例) ネットカフェ,ネカフェ,インターネットカフェ
  • Tokenization Dictionary: 単語辞書。単語の分割単位を決めるため、1単語で扱いたい単位。
    • 例) 東京タワー(登録しておかないと東京とタワーに分解されるため、「東京にある他の名前のタワー」にもヒットしてしまう)

bed76e20-770c-39f1-42a4-5cb38a3ac0d2

上記の図にある通り、幾つかのスケーリングオプションを適切に設定する必要があります。

Elasticsearch Serviceの強み

拡張性

Elasticsearch Serviceは、単純にElasticsearchをホスティングしてくれるだけのサービスのため、Elasticsearchをセットアップして最低限の環境を構築する手間を省いてくれるものと理解しておくと良いでしょう。
従って、標準以外のプラグインのインストールなど一部を除き、Elasticsearchでできることの大部分が可能であるため、CloudSearchに対して 拡張性 があると言えます。
どのような制限があるかについては、Amazon Elasticsearch Service Limitsを参考にしてください。

サービス連携

では、通常のElasticsearchと全く一緒かというと、 AWSのその他のサービスとの連携 がシームレスであることに強みがあります。
Elasticsearchを利用するケースとして、 ログのリアルタイム可視化 が多くあります。
Elasticsearch Serviceでは、 容易にCloudWatch Logsを投入、可視化 することができます。

下記の図のように、CloudWatch Logsのロググループ一覧から、ログのストリーミングを簡単に開始することができます。
ログが投入された後、Kibanaをすぐに利用できるようになっているので、可視化も簡単です。

d7317189-c486-8017-925a-f6bde413245a

まとめ

以上から、目的別にどちらのサービスを利用した方がいいかまとめると…

  • 一般的な全文検索エンジンの構築 → CloudSearch
  • 高度な全文検索エンジンの構築 → ElasticSearch Service
  • ログのリアルタイム可視化がしたい → ElasticSearch Service

となると思います。
サービス選定の参考になりましたら幸いです。