私は、かなり多数のキー、潜在的に数百万のキーを持つ可能性のあるプロジェクトのfirebaseをテストしています。
ノードを使用して数 10k のレコードのロードをテストしましたが、ロード パフォーマンスは良好なようです。ただし、「FORGE」Web UI は使用できないほど遅くなり、ルート ノードを展開するとすべてのレコードがレンダリングされます。
Firebase はこの量のデータ用に設計されていませんか、それとも何か間違っていますか?
私は、かなり多数のキー、潜在的に数百万のキーを持つ可能性のあるプロジェクトのfirebaseをテストしています。
ノードを使用して数 10k のレコードのロードをテストしましたが、ロード パフォーマンスは良好なようです。ただし、「FORGE」Web UI は使用できないほど遅くなり、ルート ノードを展開するとすべてのレコードがレンダリングされます。
Firebase はこの量のデータ用に設計されていませんか、それとも何か間違っていますか?
これは単に Forge UI の制限です。まだまだ初歩的な内容です。
Firebase のリアルタイム関数は、大規模なデータ セットに適しているだけでなく、そのように設計されています。レコードがリアルタイムでストリーミングされるという事実は、これに最適です。
他の大規模データ アプリと同様に、パフォーマンスは実装次第です。ここでは、大規模なデータ セットで留意すべきいくつかの落とし穴を示します。
デノーマライズ、デノーマライズ、デノーマライズ
データセットが反復され、そのレコードが数千に数えられる場合は、それを独自のパスに保存します。
これは、大きなデータセットを反復するのには適していません:
/users/uid
/users/uid/profile
/users/uid/chat_messages
/users/uid/groups
/users/uid/audit_record
これは、大きなデータセットを反復するのに適しています:
/user_profiles/uid
/user_chat_messages/uid
/user_groups/uid
/user_audit_records/uid
大規模なデータセットで「値」を避ける
を使用してchild_added
、value
レコード セット全体をクライアントにロードする必要があります。
子に対する隠されたvalue
操作に注意してください
を呼び出すとchild_added
、基本的value
にすべての子レコードが呼び出されます。そのため、それらの子に大きなリストが含まれている場合は、返されるすべてのデータをロードする必要があります。したがって、上記の DENORMALIZE セクション。