问题标签 [eventual-consistency]

我正试图围绕 GAE 数据存储中的可能性一致性和每秒写入 1 原则。我有一个场景和两个问题：

问题：

1. 我会在这里得到一个例外，因为我在一秒钟内对同一个 EntityGroup 进行了两次写入（user.put 和 comment.put）？有没有简单的方法解决它？
2. 如果我删除 parent=user(user_id)，这两个实体将不再属于同一个 EntityGroup。这是否意味着从函数返回的评论列表可能不包含最后添加的评论？
3. 我做错了什么吗？

我知道我弄错了实体引用部分。这个问题无关紧要（或者是吗？）

我有以下情况：

• 大约 7000 万台设备每 3~5 分钟向服务器发送一个信号，发送其 id、状态（在线或离线）、IP、位置（经纬度）、父节点和其他一些信息。

• 其他信息可能不是标准格式（所以我没有架构），但我仍然需要查询它。

• 设备可能会消失一段时间（或永远）在此过程中不发送信号。因此，如果设备在过去 X 天内没有发送信号，我需要一种方法来“忘记”设备。新设备也可能随时上线。

• 我需要查询所有这些数据。就像了解特定区域或 IP 范围内有多少设备离线一样。不会有很多查询同时运行。

• 一些查询需要快速运行（每个查询少于 3 分钟）并且在数据库更新的同时。所以我需要主要属性（id、状态、IP、位置和父节点）的索引。查询结果不需要 100% 准确，最终一致性很好，只要它们不需要太长时间（平均超过 20 分钟）才能出现在查询结果中。

• 我根本不需要坚持，如果停电了，失去一切也没关系。

考虑到这一切，我想使用 noSQL 方法，可能是 MongoDB 或 CouchDB，因为我有使用 MapReduce 和 Javascript 的经验，但我不知道哪个更适合我的问题（我倾向于 CouchDB）或者它们是否完全适合来处理如此庞大的工作量。我什至不知道我是否真的需要一个“传统”数据库，因为我不需要持久性到磁盘（也许主内存方法会更好？），但我确实需要一种方法来轻松构建自定义查询。

我发现的主要问题如下：

• 需要非常快速地插入/更新大量元组，我事先不知道我收到的信号是否已经在数据库中。几乎所有信号都将处于与上次相同的状态，因此可以通过 id 查询并检查元组是否更改，如果不执行任何操作，是否更新？

• 忘记离线设备。在夜间运行的批处理作业删除过期的元组可以解决这个问题。

• 不会有很多查询同时运行，但它们需要快速运行。所以我想我需要一个在集群的多个节点上执行单个查询的集群（CouchDB MapReduce 是否将工作负载拆分到集群的多个节点？）。我不确定我是否需要一个集群，一台更昂贵的机器可以处理所有负载吗？

• 我以前从未使用过 noSQL 系统，但我对这个主题有理论知识。

我有一个应用程序：

• 使用嵌入式 RavenDB 数据库
• 使用单调读取选项
• 使用静态索引

我注意到，当应用程序启动时，索引都是暂时过时的，即使在应用程序关闭（干净地）前一次运行时它们不是过时的。

例如，我运行应用程序，插入 10 条记录，然后等待索引更新。我查询它并查看我期望的结果。然后我关闭应用程序，重新启动它，然后查询，我没有得到任何结果。一秒钟后，索引已更新，我现在可以返回结果。如果我重复这个，有时我会得到 10 个结果，有时会得到 0 个结果，有时会得到 2 个结果。

我的假设是，在时间 T 查询索引时，我总是会在 T + 1 看到“至少一致”的结果。但是，如果服务器在此期间重新启动，我似乎在 T + 1 看到不太一致的结果。这是不是最终的一致性，而是最终的不一致！:)

我的问题是：

1. 我的假设是错误的/愚蠢的吗？
2. 有没有办法防止这种情况发生？
3. 这种行为只是一个开始的事情，还是可能随时发生？例如，我是否可以渲染 10 个结果，然后刷新 0 个结果，然后再次刷新 10 个结果，因为 Raven 决定要重新索引所有内容？

CloudSearch 的结果只是最终一致的。

在我 95% 的应用程序中，对于它提供的性能和冗余来说，这是一个可以接受的折衷方案。

不过，在最后 5% 中，我发现自己正在发布一个新的 SDF 文档，然后立即运行一个查询，我需要反映我刚刚所做的 POST。

目前，我有一个拼凑的解决方案，其中涉及轮询 CloudSearch，直到结果符合我的预期，直接在 POST 之后。不幸的是，这有很多问题，从与额外读取相关的成本增加 ($) 到当我有多个用户时的竞争条件。

有没有处理这种情况的最佳实践？

来自 AWS 论坛的 xpost：https ://forums.aws.amazon.com/thread.jspa?messageID=470636⹬

编辑：关于我的特定用例的附加信息。

我正在获取带有许多布尔查询的搜索结果，并且我希望能够更新一个或多个文档，以便它们可能不再出现在查询中，然后刷新视图以显示结果.

具体来说，我有一堆带有布尔值的文档，将它们标记为“已归档”

当我在未归档视图中查看它们，然后将它们标记为已归档时，我希望能够在不显示这些项目的情况下刷新视图。

我还在使用 CloudSearch 进行排序/过滤/分页，这使得插入或修改本地副本变得困难

如果我有一堆条目存储在最终一致的数据库中，是否有任何标准策略可以帮助我可靠地查找修改后的条目？当然，它们只会“最终”被发现，这没关系，但我想避免可能永远找不到它们的情况。

这似乎是一个非常普遍的问题，因此我希望有一些标准的方法来处理它。但不幸的是，我很难找到任何有用的东西。

我一直在考虑的方法是用某种单调递增的版本号（例如时间戳）标记所有条目，然后在数据库中查询版本号大于我迄今为止看到的最高版本号的所有条目。这样做的问题是条目可能被无序提交（并因此在查询中返回）。因此，如果以后的更新“成功”到给定的查询中，而较早的更新没有，我不能只使用后来的版本号作为我在下一个查询中看到的最高版本，否则我会永远找不到较早的更新。

如果可以保证版本号总是不断增加而没有跳过版本（这在我的情况下很难实现，但可能是可行的），我可以简单地保留一个更改日志，每个更改都有一个条目，然后查询“给我除 x、y、z、...以外的所有版本。” 但是这个更改日志和相关的查询可能会很大（取决于相对于我可以假设一致性的时间尺度的变化速度），所以我认为这不是一个好的选择。

有什么想法吗？

我知道在 Cassandra 中，除非您明确要求，否则没有强一致性（即使这样，也没有事务）。

但是，我对一致性的“顺序”感兴趣。举个例子：

在一个数据库节点中，有 3 个节点（A、B 和 C）。两个插入查询是通过相同的 CQL 连接发送的（或者就此而言，我认为这与这个问题无关）。两者都在不同的表上运行（这可能是相关的）。

在问题被发送到的节点上成功执行后，它立即关闭。该节点可能成功也可能未成功将这两个查询传播到 B 和 C。

现在，我认为有一个一致性的顺序。要么两者都在 B 和 C 上成功传播和执行，要么只有第一个查询是，或者两者都是。我认为，在任何情况下都不会传播和执行第二个查询，而不是第一个（因为 tcp 数据包的顺序，以及显然所有节点共享相同的一致性策略的事实）。

我对吗？

我正在写我的学士论文。因此，我关心的是理论上的最终一致性以及 Cassandra 如何应用该理论。要理解我的问题，请考虑以下一致性定义（据我所知）：

• 因果一致性：

  如果系统的每个节点以相同的顺序看到可能存在因果关系的内存操作，则系统提供了因果一致性。（维基百科）

  因此，如果进程 A 将数据 X 写入数据库，然后进程 B 读取该数据 X 并用 Y 覆盖，那么我们说如果 B 在所有副本（分别为节点）上的 A 之后获得 X，则确保了因果一致性）。

• 读写一致性：

  这是因果一致性的一个特例。因此读取和写入在同一个进程A上处理。这种一致性确保A在修改后永远不会有更旧的数据对象。

• 会话一致性：

  在这种情况下，进程 A 在会话中访问数据库。只要这个 Session 存在，系统就保证给你一个 Read-your-write Consistency

• 单调读取一致性：

  如果一个进程在读取后​​获得了特定的数据对象，则系统保证在每个后续的读取访问中的进程都不会获得较旧的数据对象。

• 单调写入一致性：

  在这种情况下，对 DB 的写入选项将被序列化，因此写入选项的顺序会导致哪个进程首先写入。

  现在这是一些理论上的一致性选项，其中一些或其中一个是在 NoSQL 系统中实现的。但是，如果我理解错误，请纠正我。

我的问题是 CASSANDRA 提供哪种类型的一致性？ 以及这些一致性如何与规则“R+W>N”和“R+W<=N”相关

我有一个 CQRS 应用程序，在事件存储和读取模型之间具有最终一致性。在其中我有一个项目列表，在列表下有一个“新建”按钮。当用户成功创建新项目时，他将被引导回列表，但由于读取模型尚未更新（最终一致性），因此列表中缺少该项目。

我想伪造列表中的条目，直到更新读取模型。当新项目出现在实际列表中时，我如何最好地做到这一点以及如何将其删除？我预计读取模型会延迟大约 60 秒。

我确实意识到有更简单的方法可以在没有 CQRS 的情况下实现此行为，但应用程序的其余部分确实从 CQRS 中受益。

如果重要，应用程序是 ac# mvc4 应用程序。我一直在考虑涉及 HTML5 Web Storage 的解决方案，但想知道解决此类问题的最佳实践是什么。

大部分nosql方案只使用最终一致性，鉴于DynamoDB将数据复制到三个数据中心，读写一致性是如何维护的？

解决此类问题的通用方法是什么？我认为这很有趣，因为即使在 MySQL 复制中，数据也是异步复制的。

如果我做对了，在最终一致的系统中，您将接受并确认来自用户的事件，但实际上只是将事件保留在队列中，直到它被完全处理，包括对用户可见的效果。

但由于在这两者之间，系统并不是 100% 一致的，因此事件的处理可能会遇到问题。例如，考虑由对已被删除的对象的更改组成的事件。

向用户呈现这种故障的模式是什么？

我现在唯一能想到的是一个仍然需要处理的事件列表，带有关于失败的标记，但这似乎是一种相当技术性的方法，可能会让大多数用户感到困惑。