Как создать следующую структуру данных в среде NoSQL

Question

Intro
У меня есть база данных FireStore, похожая на базу данных социальных сетей, с 3 коллекциями Users, Events и EventUpdates.Моя цель - создать ленту с событиями, созданными мной и моими друзьями.Поэтому я должен расширить свою базу данных дружескими связями.Но я борюсь с 3 проблемами, и, надеюсь, кто-то здесь может подтолкнуть меня в правильном направлении, чтобы решить их.

Проблема / Вопрос 1:
Я добавил имя пользователя и изображение пользователя вМодель EventUpdate, так что запрос проще.Я слышал, что денормализация - это путь к базе данных NoSQL.Но если пользователь обновляет свой образ пользователя, я должен обновить все события EventUpdates, созданные этим пользователем.Похоже, что-то, что вы не хотите делать.Но есть ли лучший способ сделать это?

Проблема / Вопрос 2:
Как создать структуру данных, оптимизированную для выполнения следующего запроса: получить событие от меняи мои друзья упорядочены по дате.

Задача / Вопрос 3:
Как хранить лайки?Я могу сохранить счетчик в eventUpdate.Но это становится проблемой, когда я денормализирую eventUpdates (см. Текущее решение под EDIT) ..

Пример структуры данных .

{
  "users": {
    "1": { "name": "Jack", "imageUrl": "http://lorempixel.nl" }
  },
  "events": {
    "A": { 
      "name": "BeerFestival", 
      "date": "2018/09/05",
      "creatorId": "1"
    }
  },
  "eventUpdates": {
    "1": {
      "timestamp": "13243543",
      "creatorId: "1",
      "creatorName": "Jack",
      "creatorImageUrl": "http://lorempixel.nl",
      "eventId": "A",
      "message": "Lorem ipsum"
    }
  }
}

EDIT

ОК, после некоторых проб и ошибок я получил следующую структуру.Эта структура, кажется, работает, но моя проблема с этим решением состоит в том, что мне нужно сделать много вызовов записи для обновления одного события EventUpdate из-за всех копий в каждом фиде (1000 подписчиков означают 1000 копий).И, похоже, мне нужно много это делать.

Я хотел бы, например, добавить кнопку «Мне нравится» в каждое обновление события.Это инициирует обновление всех копий EventUpdate.Для меня это выглядит так, как будто Firebase не подходит для моего проекта, и я думаю заменить его на SQL DB, или кто-нибудь здесь может передумать с лучшим решением?

{
  "users": {
    "user1": { "name": "Jack", 
      "imageUrl": "http://lorempixel.nl",
      "followers": ["user1"]
    }
  },
  "feeds": {
    "user1": {
      "eventUpdates": {
        "1": {
          "timestamp": "13243543",
          "creatorId: "1",
          "eventId": "A",
          "message": "Lorem ipsum"
        }
      },
      "following": {
        "user1": { 
          "name": "Jack", 
          "imageUrl": "http://lorempixel.nl",
          "followers": ["user1"]
        }
      }
  },
  "events": {
    "A": { 
      "name": "BeerFestival", 
      "date": "2018/09/05",
      "creatorId": "1"
    }
  }
}

Answer 1

У Firestore другой подход к миру NoSQL.Как только вы узнаете, какие данные вы будете использовать (как вы уже знаете), есть несколько очень важных моментов относительно того, какую архитектуру будут иметь данные.И многое зависит от того, как растут данные, какие запросы вам понадобятся и как часто вы будете их использовать.В некоторых случаях Вы можете создать корневую коллекцию, которая объединяет данные и запросы, может быть проще.

Существует отличное видео с Firebase Channel, которое может помочь.Проверьте это!Как структурировать ваши данные |Познакомьтесь с Cloud Firestore # 5 https://www.youtube.com/watch?v=haMOUb3KVSo

[ОБНОВЛЕНО] 26 декабря

Другие видео, которые могут помочь в моделировании и запросе ваших данных, это следующие видео:

КакПодключите пользователей Firebase к своим данным - 3 метода https://www.youtube.com/watch?v=jm66TSlVtcc

Как НЕ получить 30-тысячный счет Firebase https://www.youtube.com/watch?v=Lb-Pnytoi-8

Модель реляционных данных в Firestore NoSQL https://www.youtube.com/watch?v=jm66TSlVtcc

Answer 2

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

Правильно, denormalization и является обычной практикой, когда дело доходит до Firebase.Если вы новичок в базах данных NoQSL, я рекомендую вам посмотреть это видео, Денормализация нормальна с базой данных Firebase для лучшего понимания.Это для базы данных реального времени Firebase, но к Cloud Firestore применяются те же правила.

Но если пользователь обновляет свой пользовательский образ, я должен обновить все eventUpdates, созданные этим пользователем.Похоже, что-то, что вы не хотите делать.Но есть ли лучший способ сделать это?

Да, это тоже правильно.Вам необходимо обновить все места, где существует это изображение.Поскольку вы выбрали google-cloud-firestore в качестве тега, я рекомендую вам посмотреть мой ответ из этой записи , потому что в случае многих операций записи Firestore может быть немного дорогостоящим.См. Также Ценовые планы Firestore .

Относительно Firestore, вместо того, чтобы держать весь объект, вы можете удерживать только ссылку на изображение.В этом случае нет ничего, что вам нужно обновить.Это всегда торговля между этими двумя методами, и, к сожалению, между ними нет никакого пути.Вы или держите объекты или только ссылки на объекты.Для этого, пожалуйста, смотрите мой ответ из этой записи .

Как мне создать структуру данных, оптимизированную для выполнения следующего запроса: get eventUpdatesот меня и моих друзей, упорядоченных по дате.

Как я вижу, ваша схема больше похожа на схему базы данных Firebase в реальном времени, чем на облачное хранилище пожаров.И чтобы ответить на ваш вопрос, да, вы можете создать.Итак, говоря о Firestore, вы можете создать коллекцию с именем eventUpdates, которая может содержать eventUpdate объектов и запрашивать ее в соответствии с отметкой времени, такой запрос необходим:

FirebaseFirestore rootRef = FirebaseFirestore.getInstance();
CollectionReference eventUpdatesRef = rootRef.collection("eventUpdates");
Query query = eventUpdatesRef.orderBy("timestamp", Query.Direction.ASCENDING);

Но обратите внимание, чтополе timestamp должно иметь тип Date, а не long.Также посмотрите на мой ответ из этого поста , чтобы узнать, как добавить свойство даты в базу данных Cloud Firestore.

Какмагазин любит?Я могу сохранить счетчик в eventUpdate.Но это становится проблемой, когда я денормализирую eventUpdates (см. Текущее решение под EDIT)

Вы можете просто добавлять лайки, но я рекомендую посмотреть последнюю часть моего ответа из этого поста.Поэтому вы можете рассмотреть возможность добавления этого количества в базу данных Firebase в реальном времени, а не в Cloud Firestore.Обе базы данных работают очень хорошо вместе.

Эта структура, кажется, работает, но моя проблема с этим решением состоит в том, что мне нужно сделать много вызовов записи, чтобы обновить один eventUpdate из-за всех копий в каждомподача (1000 подписчиков означает 1000 копий).И, похоже, мне нужно это много делать.

Вы также можете взглянуть на мой ответ из этого сообщения .

Мне кажется, что firebase не подходит для моего проекта, и я подумываю заменить его на базу данных SQL, или кто-нибудь здесь может передумать с лучшим решением?

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

Answer 3

Если вы хотите, чтобы элементы вашего фида синхронизировались с данными реальных пользователей (например, с новым изображением профиля, когда пользователь изменяет его), вы можете просто сохранить идентификатор пользователя в документе eventUpdate.Таким образом, вам не нужно поддерживать их синхронизацию вручную, и каждый раз, когда вам нужно отобразить элемент в ленте, вы можете просто получать пользовательские данные и легко запрашивать множество eventUpdate s в полях userId и created_at(при условии, что они у вас есть).

Для реализации лайков в вашем фиде решение зависит от множества факторов, таких как объем трафика.Самый простой способ - обновить поле likes с помощью транзакции, но Firestore имеет максимальную частоту обновления для одного документа в 1 секунду.Кроме того, транзакция может легко завершиться неудачей, если более 5 транзакций пытаются обновить один и тот же документ.

Чтобы внедрить более надежную систему likes, взгляните на эту страницу от официальногоДокументы Firebase.