eventual-consistency - 如何在 NoSQL 中保持非规范化的一致性？

Question

假设我有两个集合，每个集合的值彼此独立，但每个都相互关联。他们是 photos和 users .用户和照片之间是一对多的关系。

非规范化数据的示例:

users:
{
  "id": "AABC",
  "name": "Donna Smith"
}

photos:
{
  "id": "FAD4",
  "description": "cute dog",
  "user_id": "AABC",  // This is the relationship
  "user_name": "Donna Smith"  // This is the denormalized value from the "users" collection
}

如何确保与 photos 中的文档保持一致用户“AABC”将姓名从“Donna Smith”更改为“Donna Chang”时的集合？

作为非事务性，我理解一致性将是最终的。

一个简单(天真)的实现可能会在更改用户“AABC”后触发后台作业，以更新 user_id =“AABC”的所有照片。在单个更新的情况下，这会很好用。但这是一个多用户环境，并且会同时向各个方向发送更新。例如，如果在照片后台更新中途将“Donna Smith”更改为“Donna Chang”，用户“AABC”的名称又更改回“Donna Smith”怎么办？

在网上搜索，我看到很多关于如何对非规范化数据建模的讨论。但是关于如何维护它的任何讨论似乎都被忽视了，因为“您还需要更新所有相关记录”。在这种情况下，是否有任何 NoSQL 系统可以为您完成繁重的工作？任何框架或实用程序？

我已阅读 Thomas Wanschik's excellent blog articles关于“物化 View ”的主题和正是这种情况的背景更新。但我担心的是:

后台作业必须延迟预定量
大于更新允许的最长时间(我如何
确定延迟？如果操作需要更长的时间怎么办？)，以及；

这是我尚未找到的有关实际解决方案的唯一讨论。 NoSQL 是一个大问题，为什么我没有看到更多关于这个的讨论？我错过了什么？

Answer 1

我对 NoSQL 的早期理解是在将大量数据返回给用户/应用程序时对成本进行了真正的分析。

在您的应用程序中传回照片时，什么更有可能发生得更频繁？将照片返回给用户，也许是他们正在查看它们的 friend ……或者更改用户的姓名？

由于更改用户名在应用程序中是一个不太常见的实例，NoSQL 的非规范化声名鹊起是您可以向用户提供高速的照片数据块，而无需在传统的规范化/RDBMS 环境中花费 JOIN。

使用这些天有的一些工具(因为你很久以前写过这个)可以帮助解决这样的情况，但你基本上是正确的，因为你可以安排代码更改来处理这个......它将是慢...它会很贵....但它会起作用...而且您仍然可以享受将照片传送到应用程序的速度的好处，这本质上是您的应用程序的主要目的。

这个问题发展成为一部史诗般的小说，一方面是 SQL Defenders，另一方面是“狂热的”NoSQL 追随者。传统的 DBA 一想到为了速度而牺牲结构，就会不寒而栗，但将 NoSQL 视为很久以前的旧“ super 表”概念，我们过去常常根据返回的内容与需要存储的内容进行思考。本质上……这就是 NoSQL 概念的产生原因，事实证明，它在大规模应用程序和大数据报告中非常有用。

我知道这是一个老问题，但我仍然希望我的回答能帮助其他人，比如我自己，在涉及此类问题时揭开 NoSQL 的神秘面纱。