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

89
10

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

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

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

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

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

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

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

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

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

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

спросил(а) 2021-01-25T17:52:29+03:00 4 месяца, 3 недели назад
1
Решение
77

Я задаю этот вопрос по вашей просьбе отсюда.

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

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

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

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

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

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

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

В качестве альтернативы, вы бы вместо этого имели post_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

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

ответил(а) 2021-01-25T17:52:29+03:00 4 месяца, 3 недели назад
Ваш ответ
Введите минимум 50 символов
Чтобы , пожалуйста,
Выберите тему жалобы:

Другая проблема