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

я было время, пытаясь обернуть голову вокруг того, что я считал простой концепцией.

У меня есть приложение, в котором я регистрирую пользователя, позволяя этому пользователю установить «photoURL» для его «пользовательской» информации в системе Firebase Auth. Это работает. Когда пользователь создает сообщение в моем приложении, я хочу отобразить заголовок, изображение и «photoURL» создателя.

В настоящее время я сохраняю пост:

-Post {
 -id
 -title
 -image
 -photoURL <- from current logged in user }

Я также разрешаю пользователям посещать страницу постеров через маршрутизацию / poster / 'displayName'

Поэтому позже, когда пользователь обновляет информацию своего профиля, такую ​​как displayName или photoURL, нужно ли мне искать все сообщения, комментарии, сообщения, ответы и любое другое место, где у этого пользователя есть запись, и обновлять photoURL?

Я думал, что смогу сказать: (псевдокод)

get all posts =>
 foreach(post)
   post = {
          title: post.title.val()
          image: post.image.val()
          avatar: firebase.database().ref().child('users' + post.key)
          }

Все, что я читаю, говорит о том, что мне нужно хранить этот photoURL в своей таблице «Пользователи». Если я это сделаю, то ни одна из публикаций не будет обновлена, если я не напишу серверный вызов, чтобы сделать это каждый раз, когда происходят изменения. Проблема в том, что, если у меня есть 100 000 пользователей, и 10% из них меняют свой photoURL, я должен изменить его в сообщениях, комментариях, ответах и ​​сообщениях для каждого пользователя. Если средний пользователь имеет 100 сообщений, 4000 комментариев, 6000 ответов, мы ищем около 10 000 пользователей * 10 000 пользователей, которых необходимо обновить, и если средний серверный вызов составляет 137 мс, то мои затраты составляют около $ 175 (расходы)

Другой вариант - извлекать информацию из двух таблиц и каждый раз создавать новый объект. Это приведет к удвоению количества обращений к серверу и времени, что удвоит мои затраты.

Это лучший подход для этого? Я думал, что будет намного проще просто получить фотографию пользователя и отображаемое имя.

Извините за длинный эпический пост, но я пытаюсь учиться. Спасибо всем!

 DKinnison16 нояб. 2017 г., 17:35
да, я только обновляю строку, но я делаю это кучу раз и мест. Разве это не будет стоить мне тонны функций и миллисекунд серверного времени?

Ответы на вопрос(1)

Решение Вопроса

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

Нет «лучшего» способа определить, что делать. Это полностью зависит от вашего конкретного случая. Похоже, если у вас слишком много дублирования данных, которое может быть дорогостоящим для обновления, было бы лучше просто каждый раз запрашивать запись пользователя, а не делать обновления. Но опять же, это в конечном итоге зависит от вас.

 DKinnison16 нояб. 2017 г., 17:33
Я понимаю, что если у меня 100 тыс. Пользователей и они посещают 10 раз в месяц, я смотрю 1 млн. Просмотров. Если я выполняю объединение каждый раз, когда они поднимают сообщение, и средний пользователь видит 210 объектов с разными аватарами, то я смотрю примерно 210 миллионов вызовов и около 7 286 мс, что приводит меня к 370 долларам, но если я обновлю все экземпляры, Я мог бы сделать это примерно за половину количества звонков и сэкономить время примерно на половине денег. Эти варианты просто кажутся экстремальными в любом случае. Я ошибаюсь по этому поводу?
 Doug Stevenson16 нояб. 2017 г., 17:53
Еще одна вещь, которую следует учитывать, - это использовать некую форму кэширования на стороне клиента, чтобы в некоторых случаях запросы не повторялись. База данных реального времени обеспечивает постоянство для всего, что она читает, или вы можете также внедрить простой кеш для встречающихся пользователей.

Ваш ответ на вопрос