Firebase推奨の全文検索 ElasticSearch/Algolia/Typesense比較

FireStoreで全文検索をする方法3種類を比較してみた#

ご存知の通りFireStoreは全文検索機能をサポートしておりません。それ以外の機能がとても優秀なだけに、非常に残念です。 全文検索をするには外部の全文検索データベースを併用することを案内しております。 Firebase公式サイトでは、全文検索データベースとして、

• Elastic Search
• Algolia
• Typesense

の3種類を紹介しています。もちろんこれらに限らず、全文検索をサポートする任意のデータベースを利用することができます。 今回ご縁があり、Elastic Searchを試す機会があり、Firebaseが公式で紹介してる3つのDBをすべて使うことになりましたので、ここで改めて3種類の全文検索データベースの比較を書いてみようと思います。

これらのデータベースの目的は、FireStoreで補えない全文検索をサポートするという目的に着眼しています。 すべてのDBで共通ですが、データの書き込みは Firebase Cloud Functionsを使うことになります。

Algolia#

最も簡単で即効性のある全文検索データベースでした。導入までのハードルは低いです。 難しいことを考えずとも良しなにインデックスしてくれます。

Firebaseのアカウントに応じてアクセスできるデータを制御する必要がある場合は、ファセットを登録する必要があります。 データの検索時は、制限付きAPIキーを使うことで安全・簡単にデータにアクセスできます。Vueなどのフロントから直接Algoliaのデータベースにアクセスできるので、開発もテストも簡単に行なえます。 制限付きAPIキーだけはフロント側で発行させるわけにはいきませんので、Cloud Functionsを使う必要があります。 Cloud FunctionsからFirebaseのログインユーザIDなどを取得して、そのユーザIDのデータを予めファセットした状態で検索される制限付きAPIキーを発行してフロントに渡す必要があります。

検索の速度や制度も申し分はありませんが、データの登録だけは体感上ラグがあるように感じました。データ登録後すぐに検索するということはあまりないと思いますが、登録後すぐに検索してもHitしないことがあります。反映には10秒前後かかります。

最大のデメリットはコストで、Algoliaの費用は決して安くは有りません。 1000レコードで1ドルかかります。数十万件のデータを保存するような規模になるとこのコストは無視できません。

Typesense#

Algoliaの廉価版という立ち位置かな？と思いますが、Algoliaより優れた点も多くあります。 Algolia同様に制限付きAPIキーを発行できるのはとても便利です。Cloud Functionsから制限つきAPIキーをフロントに渡せば、フロント側で直接Typesenseにアクセスできます。 基本的には読み取り専用です。データの書き込みはFirebase Cloud Functionsを使うようにしましょう。 Algoliaはデータを投げれば勝手にインデックスしてくれますが、Typesenseではデータを入れる前に、テーブルの作成をしなくてはなりません。 この時点でAlgoliaより手間がかかる感じがしてきますね。実際、作業の手間で言えばAlgoliaより多くなります。

Typesense Cloudというサービスを展開しており、自前でサーバを抱えることなく全文検索データベースを持つことができます。 性能もGCPを使っているようで、ある程度需要に応じて選択できます。そのため、一定額の運用費用は発生しますが、データ量がある程度増えてくるとAlgoliaより安価に運用できます。 極端な話、データが0件ならAlgoliaのほうが安価ですが、数万件を超えたあたりでTypesenseのほうが安くなります。しかもこの差はデータ量が増えるごとに相対的に広がっていくことになります。

Algoliaとの大きな違いとして、オープンソースのため自前でサーバを用意して使うこともできるという点です。 Algoliaではソート機能がランキング形式で、任意のフィールドでソートするにはそれ専用のインデックスを作る必要があります。 Typesenseでは数値フィールドであれば自由にソートできる点が優秀です。ただし、文字によるソートはサポートされない点がマイナスポイント。 製品名順に並べたいといったことが残念ながらできません。 一時期は大変良いプロジェクトと考えていましたが、Elastic Searchに乗り換えてからはあまり積極的に推奨できなくなりました。 最大の問題は「日本語に対応していない」という点です。データとして格納できるし、検索もできますが日本語を全部検索するには、一筋縄では行きません。 単純にN-gramでぶつ切りにすることで検索できるようにはなりますが、かなりノイズが紛れ込むため、利用者からは結構不満が漏れます。 形態素解析を使って意味のある文章に分け、インデックスしても新語や誤入力などでうまくインデックスされないケースも有り、結果検索漏れが発生します。

Elastic Search#

3つのデータベースの中では最もとっつきにくいですが、最も優秀でした。 日本語の全文検索制度を語る上で外すことのできないN-gramや形態素解析といった機能がプラグインとして予め用意されています。 日本語の検索を実装するガイドが非常に参考になります。 クエリもかなり優秀ですし、文字列によるソート、数値によるソートも完全に対応しています。 非常に面白いと思ったのが、1つのフィールドに2つ以上のデータをもたせることができるという仕組みでした。 例えば nameというフィールドに、 name.keywordとname.ngramの2つのフィールドを作ると言ったことができます。 逆を言えばこういうフィールドの設計が必要で、これが少し面倒です。

適当にデータ突っ込むだけでもいいんだけど日本語の検索をしたいなら設計しないとだめっぽい

Elastic Cloudというサービスがあり、自前でサーバを用意せずに利用できます。 Firebaseのアカウントに応じてアクセスできるデータを制御する必要がありますが、その振り分けがRoleでは実装するのが難しいと思います。 今回は公式に例示されているように、Cloud Functionsを使ってアクセス制御しました。 AlgoliaやTypesenseのように制限付きAPIキーというものが無いため、データを安全に保護するためにはCloud Functions経由でアクセスするというやり方がベストでしょう。 欲を言えば制限付きAPIキーのような仕組みも欲しいと思います。 AlgoliaやTypesenseの管理画面は比較的GUIチックでデータを直感的に見ることができますが、Elastic Searchはそのあたりが非常にわかりにくいです。 データを可視化するのはすべてKIBANAという、Elastic Search内部の別のサービスが受け持ちますが、初学者にはこれがわかりにくく感じました。 最初の2，3日は結構ストレスを感じますが、それをすぎると違和感なく使えるようになります。

総括#

Firebaseの公式サイトで紹介されている3つの全文検索を、実際に使った側の立場でざっくりとまとめてみました。 個人的に最も推奨するのはElastic Searchです。 多少の不便さや、最初のとっつきにくさはありますが、3つのデータベースの中では最も優秀だと感じました。 もちろん、用途や目的によっても変わってくるでしょう。わかりやすさ、手軽さを重視するならAlgoliaには勝てません。 Typesenseは現時点で採用するのは厳しいかなーと思います。確かに安価なのですがやはり日本語に対応する手間を考えると、他の道を探りたくなります。