Firebase データベースの制限事項

Firebase データベースの制限事項

Firebase のデータベースは利用しやすく便利な仕組みですが、制限事項も幾つかあります。 この記事では、Firebase のデータベースの制限事項についてよく引っかかる項目を簡単にまとめてみました。

複雑なクエリが書けない

Firebase のデータベース（Firestore）は SQL データベースのように広く利用されているリレーショナル型のデータベースではありません。 リレーショナル形のデータベースの場合、複数のテーブルから必要なデータを持ってきて一つのテーブルのようにデータを取得するようなクエリも簡単に書くことができますが、Firebase のデータベース（Firestore）の場合は、こうした場合は複数のクエリを組み合わせてデータを取得して、プログラムでまとめるような処理が必要になります。

この制限事項が問題になるかという点に関しては、実装の仕方（作り方）や方針によって変わってきます。 あまりケースとしては多くないと思いますが、リレーショナルベースを基にした設計を Firebase に置き換えたりする場合には、結構面倒になる場合が多くなります。この場合、SQL などで利用できるクエリを利用してデータベースにアクセスする場合が多いので Firebase でサポートしていないタイプのクエリがあるとその部分はプログラム（フロントエンド／バックエンド）で対応する必要があるので変更が必要になるためです。

最初から Firebase のデータベース（Firestore）利用の前提で作る場合には、余り問題にならない場合が多いです。Firebase のデータベース（Firestore）のデータは基本的に JSON でプログラムにそのまま取り込めるので、Javascript のプログラムの延長として Firebase を利用するようにすれば殆ど問題にはなりません。逆に複雑なクエリを書かないで住むように予めデータを管理する方が Firebase のデータベース（Firestore）を利用する場合には便利です。

書き込みの制限

どんなデータベースでも書き込みの制限がありますが、Firebase にも存在します。 Firebase のドキュメントを見ると、１秒間に１万回と書いてあるので大きな問題は無いように見えます。 ところが、実際の処理を行うと何故かエラーになるケースがあります！実際に１秒間に１万回の書き込みをするケースは通常の Web サービスや Web アプリでは発生するケースは余りないと考えられます。実は、別の制限があるためにエラーになっています。よくドキュメントを見ると「Soft limts」というのが設けられていて、この数字は 1 秒に１回となっています。

ただし、この制限を受けるのは、継続した連続の書き込みに対する制限で、ループなどで連続する書き込みを大量に行うと途中からエラーになる可能性があるという事です。あくまで、「ソフトリミット」で１秒間に１回以上の書き込みをしたら必ず起きるというものではありません。余り、集中した書き込みを連続すると起きるという事です。ドキュメントにはどの程度継続すると起きるかは明確に書かれていませんが、実際にプログラムのループで継続的に書き込みを行うと発生する場合があります。

従って、大量の連続した書き込みが発生する場合は、書き込みの間隔を明ける処理や、最大の連続書き込みを決めて制限するような措置が必要になります。

問題は、この手の問題は開発段階のテストでは発生しない場合が多く、実際にサービスやアプリを公開してアクセスが集中したり、データ量が増えた場合にのみ発生するタイプの問題なので対策が難しくちょっと厄介です。

しかし、こうした制限があることを予め知っていると対策もある程度可能なので有利です。

ドキュメントの制限

Firebase のデータベース（Firestore）の基本的なデータの構造は「コレクション(collection)」と「ドキュメント(document)」です。リレーショナル型のデータベースのデータ構造の言葉でいうならば、コレクションはテーブル（表）に近い概念で、ドキュメントはテーブル（表）の行要素に近い感じです。

Firebase の場合、このドキュメントのサイズに制限があります。ドキュメントのサイズは１ MB 以下になっています。Firebase のドキュメントの場合直接画像データや動画データを入れることは無いので、１ MB という数字自体は問題は余り無いかと思います。

通常の数字や文字列のデータで１ MB を超えることは実際のアプリケーションでは余り無いと思いますが、Firebase のドキュメントは基本的に JSON 形式ならば保存する事が可能です。JSON の場合は、一つの JSON でも階層構造を取る事ができて、JSON の中に別の JSON 形式のオブジェクトや、配列（array）も置くことができるので、その際にはこの階層の深さにも制限があります。階層の深さは２０まであるので通常のデータではこれも大きな問題になることはありません。

クエリなどは制限の多い Firebase ですが、ドキュメントに関しては便利な一面もあります。 コレクションの中のドキュメントは必ずしも同じデータ構造になっている必要はなく、JSON 形式のデータであれば何でも保存できます。リレーショナル型のデータベースの場合は、テーブル（表）という概念なので、各行要素は同じデータ構造（同じ列要素を持つデータ）である必要があります。しかし、Firebase の場合はこの制限がないのは大きなメリットです。

アクセスの権限

これに関しては以前の記事で何度か書いていますが、Firebase でアクセスの権限を管理するには、「セキュリティルール」が基本的に必要です。これは、フロントエンド（Web ブラウザ）から直接 Firebase にアクセスする場合の制限で、Firebase admin SDK を利用してバックエンドからアクセスする場合はこの限りではありません。

セキュリティルールは、プログラムとは別に設定する概念で、通常のリレーショナルデータベースの場合は、データベースのユーザー毎にアクセスの権限を設定するのに似ています。Firebase のログイン情報や、Firebase のデータベース（Firestore）の情報によって、アクセスの権限を別にプログラムのような形で各コレクションやドキュメント毎に決めることができます。

Web アプリや Web サービスで Firebase を利用する場合は、通常は Javascript(Typescript)ベースのプログラミング言語で開発することになります。特にフロントエンド（Web ブラウザ）で実行する Javascript のコードは基本的に Web ブラウザから全て参照可能です。つまり、Firebase のデータベースへのアクセスのやり方も全て参照できることになるので、プログラムとは別の枠組みのセキュリティルールで設定する必要があります。

このルールは、SDK をインストールしてコマンドラインから設定するか、Firebase コンソールで設定するので、基本的にフロントエンド（Web ブラウザ）からは参照する事はできません。従って、フロントエンドからデータベースにアクセスする場合は必ずこのセキュリティルールを設定して、必要最低のアクセス権限のみを許可するようにする必要があります。

一方で、Firebase admin SDK を利用してバックエンドからアクセスする場合は、全てのデータベースのデータにアクセス可能になるので別の方法で、認証（authentication）を行って、アクセスの権限を確認する必要があります。

まとめ

Firebase のデータベース（Firestore）は手軽に利用が可能なので非常に便利です。プログラミングや Web 開発の初心者でも、本格的な Web アプリや Web サービスを簡単に実現できるので便利な仕組みと言えます。しかし、他のデータベース同様に、制限事項も存在します。

主な制限事項は：

＊　クエリの制限

＊　書き込みの制限

＊　ドキュメントサイズの制限

＊　アクセスの制限です

きちんと理解して Firebase を利用する場合、どれも大きな問題にはならない場合が殆どですが、制限事項をきちんと理解した上で利用することはとても重要です。