Производительность Firebase с большими наборами данных

Я тестирую firebase для проекта, у которого может быть достаточно большое количество ключей, возможно, миллионов.

Я протестировал загрузку нескольких 10 тыс. записей с помощью node, и производительность загрузки оказалась хорошей. Однако веб-интерфейс "FORGE" становится необычно медленным и отображает каждую отдельную запись, если я расширяю свой корень node.

Является ли Firebase не предназначенным для этого объема данных, или я делаю что-то неправильно?

Ответы

Ответ 1

Это просто ограничения пользовательского интерфейса Forge. Он все еще довольно рудиментарный.

Функции реального времени в Firebase предназначены не только для больших наборов данных, но и для них. Тот факт, что поток записей в реальном времени идеально подходит для этого.

Производительность, как и в любом приложении с большими данными, не хуже вашей реализации. Итак, вот несколько ошибок, которые следует учитывать при использовании больших наборов данных.

DENORMALIZE, DENORMALIZE, DENORMALIZE

Если набор данных будет итерирован, а его записи могут быть подсчитаны тысячами, сохраните их по своему пути.

Это плохо для итерации больших наборов данных:

/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 выше.