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

Question

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

Ниже приведены данные сообщений в блогах. Сообщения могут быть помечены несколькими терминами, такими как «tag1», «tag2». Для того, чтобы найти, сколько сообщений помечаются с определенным тегом можно разветвление данные сообщения в теги пути путь, а также:

/posts/postid1:{“Title”:”Title 1”, “body”: “About Firebase”, “tags”: {“tag1:true, “tag2”: true}} 
/tags/tag1/postid1: {“Title”:”Title 1”, “body”: “About Firebase”} 
/tags/tag2/postid1: {“Title”:”Title 1”, “body”: “About Firebase”} 

Теперь рассмотрим одновременно,

1a), что User1 хочет изменить название postid1 и он строит следующее обновление многолучевой:

/posts/postid1/Title : “Title 1 modified” 
/tags/tag1/postid1/Title : “Title 1 modified” 
/tags/tag2/postid1/Title : “Title 1 modified” 

1b) в то же время Пользователь2 хочет добавить tag3 к postid1 и построить следующие мульти- путь обновление:

/posts/postid1/tags : {“tag1:true, “tag2”: true, “tag3”: true} 
/tags/tag3/postid1: {“Title”:”Title 1”, “body”: “About Firebase”} 

Так, по-видимому оба обновления могут сменяют друг за другом, и мы можем иметь данные тег/tag3/postid1 из синхронизации, как это имеет старое название.

Я могу думать о правилах безопасности, чтобы справиться с этим, но затем не уверен, что это правильно или будет работать.

Как мы можем иметь updatedAt и lastUpdatedAt поля и мы проверяем, если мы обновляем нашу собственную версию поста, что мы читаем:

posts":{ 
    "$postid":{ 
    ".write":true, 
    ".read":true, 
    ".validate": " 
     newData.hasChildren(['userId', 'updatedAt', 'lastUpdated', 'Title']) && (
     !data.exists() || 
     data.child('updatedAt').val() === newData.child('lastUpdated').val())" 
    } 
} 

Также для тегов мы не хотим, чтобы проверить, что снова и мы можем проверьте, является ли/tags/$ tag/$ postid/updatedAt таким же, как/posts/$ postid/updatedAt.

"tags":{ 
    "$tag":{ 
    "$postid":{ 
     ".write":true, 
     ".read":true, 
     ".validate": " 
     newData.hasChildren(['userId', 'updatedAt', 'lastUpdated', 'Title']) && (
     newData.child('updatedAt').val() === root.child('posts').child('$postid').val().child('updatedAt').val())”    
    } 
    }  
} 

К этому «/ сообщениям/$ сообщений дан» имеет управление параллелизмом в нем, и пользователи могут писать свои собственные читает Кроме того/сообщений/$ сообщений дан»становится источником истины и отдыха и другие пути веера из проверки, если updatedAt поля соответствуют ему основным источником пути истины.

Будет ли это приводить в соответствие или все еще есть проблемы? Или может привести к снижению производительности, когда это делается в масштабе?

Являются ли множественные обновления путей и правила атомарными вместе под этим я подразумеваю правило или оба правила оцениваются отдельно в изоляции для обновлений нескольких путей, таких как 1a и 1b выше?

Answer 1

К сожалению, Firebase не предоставляет никаких гарантий или механизмов для обеспечения уровня детерминизма, который вы ищете. У меня была лучшая удача, завершающая такие обновления с помощью стека API (GCF и Lambda - это очень простые, без сервера методы для этого). Обновления могут быть сделаны в этом слое и даже сериализованы, если это абсолютно необходимо. Но в Firebase нет безопасного способа сделать это.

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