如何在 Firebase 中写入非规范化数据

IT技术 javascript firebase web firebase-realtime-database nosql
2021-01-29 06:29:42

我已阅读有关结构化数据的 Firebase 文档数据存储便宜,但用户的时间不便宜。我们应该针对get操作进行优化,并在多处写入。

那么我可能会存储一个列表节点和一个列表索引节点,在两者之间有一些重复的数据,至少是列表名称。

我在我的 javascript 应用程序中使用 ES6 和 promises 来处理异步流,主要是在第一次数据推送后从 firebase 获取 ref 键。

let addIndexPromise = new Promise( (resolve, reject) => {
    let newRef = ref.child('list-index').push(newItem);
    resolve( newRef.key()); // ignore reject() for brevity
});
addIndexPromise.then( key => {
   ref.child('list').child(key).set(newItem);
 });

知道我的应用程序仅在客户端上运行,如何确保数据在所有地方保持同步

为了完整性检查,我在我的Promise中设置了一个 setTimeout 并在它解决之前关闭了我的浏览器,实际上我的数据库不再一致,保存了一个没有相应列表额外索引

有什么建议吗?

2个回答

很好的问题。我知道三种方法,我将在下面列出。

我将为此举一个稍微不同的例子,主要是因为它允许我在解释中使用更具体的术语。

假设我们有一个聊天应用程序,我们在其中存储两个实体:消息和用户。在我们显示消息的屏幕中,我们还显示了用户的姓名。因此,为了尽量减少阅读次数,我们也在每条聊天消息中存储了用户的姓名。

users
  so:209103
    name: "Frank van Puffelen"
    location: "San Francisco, CA"
    questionCount: 12
  so:3648524
    name: "legolandbridge"
    location: "London, Prague, Barcelona"
    questionCount: 4
messages
  -Jabhsay3487
    message: "How to write denormalized data in Firebase"
    user: so:3648524
    username: "legolandbridge"
  -Jabhsay3591
    message: "Great question."
    user: so:209103
    username: "Frank van Puffelen"
  -Jabhsay3595
    message: "I know of three approaches, which I'll list below."
    user: so:209103
    username: "Frank van Puffelen"

因此,我们将用户配置文件的主要副本存储在users节点中。在消息中,我们存储uid(so:209103 and so:3648524) 以便我们可以查找用户。但是我们也在消息中存储了用户名,这样当我们想要显示消息列表时,我们就不必为每个用户查找它。

所以现在当我转到聊天服务的个人资料页面并将我的名字从“Frank van Puffelen”更改为“puf”时会发生什么。

交易更新

大多数开发人员最初可能会想到执行事务性更新。我们总是希望usernamein 消息与name相应配置文件中的 相匹配

使用多路径写入(在 20150925 上添加)

从 Firebase 2.3(适用于 JavaScript)和 2.4(适用于 Android 和 iOS)开始,您可以通过使用单个多路径更新轻松实现原子更新:

function renameUser(ref, uid, name) {
  var updates = {}; // all paths to be updated and their new values
  updates['users/'+uid+'/name'] = name;
  var query = ref.child('messages').orderByChild('user').equalTo(uid);
  query.once('value', function(snapshot) {
    snapshot.forEach(function(messageSnapshot) {
      updates['messages/'+messageSnapshot.key()+'/username'] = name;
    })
    ref.update(updates);
  });
}

这将向 Firebase 发送一个更新命令,该命令会在其个人资料和每条消息中更新用户的姓名。

以前的原子方法

因此,当用户更改name其个人资料时:

var ref = new Firebase('https://mychat.firebaseio.com/');
var uid = "so:209103";
var nameInProfileRef = ref.child('users').child(uid).child('name');
nameInProfileRef.transaction(function(currentName) {
  return "puf";
}, function(error, committed, snapshot) {
  if (error) { 
    console.log('Transaction failed abnormally!', error);
  } else if (!committed) {
    console.log('Transaction aborted by our code.');
  } else {
    console.log('Name updated in profile, now update it in the messages');
    var query = ref.child('messages').orderByChild('user').equalTo(uid);
    query.on('child_added', function(messageSnapshot) {
      messageSnapshot.ref().update({ username: "puf" });
    });
  }
  console.log("Wilma's data: ", snapshot.val());
}, false /* don't apply the change locally */);

相当投入,精明的读者会注意到我在处理消息时作弊。第一个欺骗是我从不调用off侦听器,但我也不使用事务。

如果我们想从客户端安全地执行此类操作,我们需要:

  1. 确保两个地方的名称匹配的安全规则。但是规则需要允许足够的灵活性,以便在我们更改名称时暂时不同。所以这变成了一个非常痛苦的两阶段提交方案。
    1. username消息的所有字段更改so:209103null(某些魔术值)
    2. name用户更改so:209103为“puf”
    3. 更改username每则消息中的so:209103nullpuf
    4. 该查询需要and两个条件之一,Firebase 查询不支持。所以我们最终会得到一个我们可以查询的额外属性uid_plus_name(带有 value so:209103_puf)。
  2. 以事务方式处理所有这些转换的客户端代码。

这种方法让我头疼。通常这意味着我做错了什么。但即使这是正确的方法,如果我的头很痛,我也更有可能犯编码错误。所以我更喜欢寻找更简单的解决方案。

最终一致性

更新 (20150925):Firebase 发布了一项允许原子写入多个路径的功能。这与下面的方法类似,但使用单个命令。请参阅上面的更新部分以了解其工作原理。

第二种方法取决于将用户操作(“我想将我的名字更改为 'puf'”)与该操作的含义(“我们需要更新配置文件中的名称 so:209103 和每条具有 的消息中的名称user = so:209103)。

我会在我们在服务器上运行的脚本中处理重命名。主要方法是这样的:

function renameUser(ref, uid, name) {
  ref.child('users').child(uid).update({ name: name });
  var query = ref.child('messages').orderByChild('user').equalTo(uid);
  query.once('value', function(snapshot) {
    snapshot.forEach(function(messageSnapshot) {
      messageSnapshot.update({ username: name });
    })
  });
}

我再一次在这里采取了一些捷径,例如使用once('value'(这对于 Firebase 的最佳性能来说通常是一个坏主意)。但总的来说,该方法更简单,代价是不能同时完全更新所有数据。但最终消息将全部更新以匹配新值。

不在乎

第三种方法是最简单的:在许多情况下,您根本不需要更新重复的数据。在我们在这里使用的示例中,您可以说每条消息都记录了我当时使用的名称。我直到现在才更改我的名字,所以旧的消息显示我当时使用的名字是有道理的。这适用于辅助数据本质上是事务性的许多情况。当然,它并不适用于所有地方,但适用于“不在乎”的地方是最简单的方法。

概括

虽然以上只是对如何解决这个问题的广泛描述,它们绝对不完整,但我发现每次我需要扇出重复数据时,它都会回到这些基本方法之一。

这么棒的答案。您概述的建议非常有用,适用于许多场景,而不仅仅是 firebase。
2021-03-15 06:29:42
感谢弗兰克的精彩回答!事实上,我采用了“不在乎”的方法。我确实切换了我的写操作,所以该项目出现在索引之前,所以我不会冒险让列表中的项目链接到没有数据的地方(但现在我可能最终得到一个孤立的列表项目,这不是大不了)。
2021-03-17 06:29:42
小心确保在最终一致性中延迟服务器任务并检查名称是否再次更改。
2021-04-09 06:29:42

为了给 Franks 很好的回复,我使用一组Firebase Cloud Functions实现了最终一致性方法每当主值(例如用户名)发生更改时,函数就会被触发,然后将更改传播到非规范化字段。

它不像事务那么快,但在许多情况下它不需要。

很好的补充 Uffe。只要您没有严格的实时或离线要求,Cloud Functions 就非常适合这一点。
2021-03-20 06:29:42