Управление денормализованными / дублированными данными в облачном хранилище

Question

Если вы решили денормализовать / продублировать ваши данные в Firestore, чтобы оптимизировать их для чтения, какие шаблоны (если таковые имеются) обычно используются для отслеживания дублированных данных, чтобы их можно было корректно обновлять, чтобы избежать противоречивых данных?

Например, если у меня есть функция, такая как доска объявлений Pinterest, где любой user на платформе может привязать мои post к своим board, как бы вы отслеживали дублирующиеся данные во многих местоположение?

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

Например, создание коллекции users_posts_boards, которая в первую очередь представляет собой коллекцию userIDs с подколлекцией postIDs, которая, наконец, имеет другую подколлекцию boardIDs с boardOwnerID. Затем вы используете их для восстановления путей дублированных данных для post (например, /users/[boardOwnerID]/boards/[boardID]/posts/[postID])?

Кроме того, если posts может быть дополнительно предоставлен для groups и lists, продолжите ли вы делать users_posts_groups и users_posts_lists коллекций и подколлекций для отслеживания дублированных данных таким же образом?

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

{
  postID: 'someID',
  locations: ( <---- collection
    "path/to/post/location1",
    "path/to/post/location2",
    ...
  )
}

Это будет означать, что вам в основном нужно, чтобы все записи в Firestore выполнялись через облачные функции, которые могут отслеживать эти данные по соображениям безопасности ... если правила безопасности Firestore не являются достаточно мощными, чтобы разрешить операции добавления в /posts_denormalization_tracker/[postID]/locations вложенная коллекция без возможности чтения или обновления вложенной коллекции или родительской коллекции postIDs.

Я в основном ищу разумный способ отслеживать сильно денормализованные данные.

Редактировать: о да, еще один замечательный пример - информация post автора profile, включаемая в каждый post. Представьте себе адский пейзаж, пытающийся поддерживать все это в актуальном состоянии, поскольку он распределяется по платформе, а затем user обновляет свои profile.

Answer 1

Я задаю этот вопрос из-за вашего запроса от здесь .

Когда вы дублируете данные, нужно помнить одну вещь. Точно так же, как вы добавляете данные, вы должны поддерживать их. Другими словами, если вы хотите обновить / обнаружить объект, вы должны делать это в каждом месте, где он существует.

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

Чтобы отслеживать все операции, которые нам необходимо выполнить для получения согласованных данных, мы добавляем все операции в пакет. Вы можете добавить одну или несколько операций update для разных ссылок, а также операции delete или add . Для этого смотрите:

• Как выполнить массовое обновление в Firestore

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

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

Затем вы используете их для восстановления путей дублированных данных для поста (например, /users/[boardOwnerID]/boards/[boardID]/posts/[postID])?

Да, вам нужно передать каждому методу document() соответствующий идентификатор документа, чтобы операция обновления работала. К сожалению, в пути к документам Cloud Firestore нет подстановочных знаков . Вы должны идентифицировать документы по их идентификаторам.

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

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

если только правила безопасности Firestore не являются достаточно мощными, чтобы разрешить операции добавления в подколлекцию / posts_denormalization_tracker / [postID] / location, не разрешая чтение или обновление для подколлекции или родительской коллекции postIDs.

Правила безопасности Firestore настолько мощны, чтобы сделать это. Вы также можете разрешить чтение или запись или даже применять правила безопасности в отношении каждой необходимой вам операции CRUD.

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

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

Map<Object, DocumentRefence> map = new HashMap<>();
map.put(customObject1, reference1);
map.put(customObject2, reference2);
map.put(customObject3, reference3);
//And so on

Выполните итерации по карте и добавьте все эти ключи и значения в пакет, зафиксируйте пакет и все.