2016-01-08 3 views
1

Я использую Firebase для хранения профилей пользователей. Я попытался поместить минимальный объем данных в каждый профиль пользователя (следуя рекомендациям в документации по структурированию данных), но поскольку у меня есть профили пользователей более 220K, он по-прежнему представляет собой 150 МБ при загрузке в качестве JSON всех профилей пользователей. И, конечно, он будет становиться все больше и больше, поскольку я намерен иметь гораздо больше пользователей :)Firebase: запросы в больших наборах данных

Я больше не могу делать запросы по этим профилям пользователей, потому что каждый раз, когда я это делаю, я достигаю 100% базы данных I/O и, следовательно, некоторые другие запросы, выполняемые пользователями, использующими приложение, заканчиваются ошибками.

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

Итак, существует ли реальный предел до достижения 100% емкости ввода-вывода базы данных? И в чем же заключается полезность запросов Firebase в этом случае? Если у меня просто небольшое количество данных, мне действительно не нужны запросы, я бы мог легко загрузить все данные. Но теперь, когда у меня много данных, я больше не могу использовать запросы, когда мне это нужно больше всего ...

+0

Не могли бы вы привести пример того, как вы структурировали свои данные вместе с запросом, который вы делаете? Помните, что когда вы запрашиваете узел, ему также нужно вытащить _все данные из этого дочернего узла. –

+1

Вы не упомянули, что это происходит только во время начальной индексации или любых других тем, которые мы рассмотрели в поддержке. Это важные факторы, которые влияют на результат здесь. Кроме того, прецедент и ограничения чрезвычайно полезны для ориентации на конкретный ответ. См. [Проблема XY] (http://meta.stackexchange.com/questions/66377/what-is-the-xy-problem/66378#66378) для аргумента в пользу всегда начинающегося с варианта использования. – Kato

ответ

4

Основная проблема здесь - не запрос или размер данных, это просто время, необходимое для согревания данных в памяти (т. е. загрузка его с диска), когда он не часто запрашивается. Вероятно, это будет только проблема разработки, так как в производстве этот запрос скорее всего будет более часто используемым активом.

Но если целью является повышение производительности при начальной нагрузке, единственным разумным ответом здесь является запрос на меньшее количество данных. 150 МБ является значительным. Попробуйте скопировать 150 МБ-файл между компьютерами по беспроводной сети, и у вас будет некоторое представление о том, что это такое, чтобы отправить его через Интернет или загрузить его в память с файлового сервера.

Многое здесь зависит от используемого варианта, который вы не включили.

Предполагая, что у вас есть достаточно стандартные критерии поиска (например, поиск по адресам электронной почты), вы можете use indices хранить адреса электронной почты отдельно, чтобы уменьшить набор данных для вашего запроса.

/search_by_email/$user_id/<email address> 

Теперь, вместо 50k на одну запись, у вас есть только байт для хранения адреса электронной почты в записи - гораздо меньшую полезную нагрузку, чтобы нагреть в память.

Предполагая, что вы ищете надежные возможности поиска, лучшим ответом является использование реальной поисковой системы. Например, включите private backups и экспортируйте в BigQuery или зайдите в ElasticSearch (см. Пример Flashlight).

Смежные вопросы