База данных Firebase в реальном времени и хранилище

1

Я использую базу данных в реальном времени для хранения своих профилей пользователей.

Каждый из профилей может содержать несколько комнат, где каждая из них содержит свое собственное изображение, создавая довольно сложную структуру.

Вот пример: Изображение 174551

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

Мне было просто интересно, если это произойдет с какой-либо стоимости в будущем. Или, если эта реализация безопасна, где мы помещаем больше данных в базы данных.

Теги:
firebase
firebase-storage
firebase-realtime-database

3 ответа

4

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

Используя базу данных реального времени и эту структуру, каждый раз, когда вы запрашиваете "user/SOME_ID", вы загружаете все данные, расположенные ниже, включая ваши сериализованные изображения. Обратитесь к руководству по структуре базы данных для получения информации о том, как сгладить ваши данные, чтобы этого не произошло.

Кроме того, я бы порекомендовал использовать Cloud Storage for Firebase для хранения ваших изображений в их собственном двоичном формате, а не сериализовать в Base64, занимая ~ 30% больше места. Как и RTDB, хранилище может быть защищено правилами, если вы храните файлы в структурированных местах, таких как "user/SOME_ID/roomImages/ROOM_ID/..." или "roomImages/ROOM_ID/..."

0

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

Итак, если ваша база данных поддерживает байтовые массивы (двоичные, BLOB-объекты и т.д.), Я бы пошел с этим, а не со строками.

Второе - может быть более серьезная проблема с этим дизайном с точки зрения производительности - вам действительно нужны все картинки каждый раз, когда вы заходите в профиль пользователя?

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

0

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

  • 1
    Что ж, это для университетского проекта, мы должны разработать приложение для Android (где мы не должны принимать во внимание какую-либо безопасность ...). Я больше беспокоился о производительности, чем о безопасности, когда спрашивал об этом. Также обеспечивает ли хранилище Firebase шифрование файлов по сравнению с базами данных Firebase в реальном времени?
  • 1
    #AskFirebase опубликовал видео на темы GDPR и конфиденциальности, включая множество полезных ссылок на их политику. RTDB против Firestore предполагает, что Firestore будет проще в использовании, когда дело доходит до гео-защиты ваших хранимых данных. Также ведутся обширные разговоры о соблюдении безсерверного GDPR . Наконец, у Riya Sinha есть статья об использовании шифрования на стороне клиента с Firebase .

Ещё вопросы

Сообщество Overcoder
Наверх
Меню