Database 是否可以在基于复制的分布式数据库中删除？

到目前为止，我的印象是，您无法真正删除基于复制的分布式数据库中的一行。在基于副本的系统中，这一切都很好。但在复制中，您将它们标记为“考虑此删除”，并在每次查询中过滤掉它们。但实际上，您从未从数据库中删除过某些内容。我认为是时候验证这个假设是否正确了

我的理解是，若发生密钥冲突，您将在复制时遇到竞争条件。事情是这样的：

数据库A： 在键11（11A）下添加一个条目

数据库B： 在键11（11B）下添加一个条目

数据库A： 删除键11下的条目

现在，这取决于这3个操作在野外“相遇”的顺序： 预期的顺序是：

• 11A创建
• 11删除（即11A）
• 11B创建

但如果发生这种情况呢

• 11A创建
• 11B创建（失败，已经是密钥11）
• 11删除

或者更糟的是，这个

• 11B创建
• 11A创建（失败，已经是密钥11）
• 11删除（将命中11B）

---

我假设我们讨论的是一个无领导的分布式数据库，即所有节点都扮演相同的角色（没有主节点），因此读写都可以由所有节点提供服务。否则，如果只有一个主服务器，它可以对所有写/删除操作施加特定的顺序，从而解决您所描述的并发问题

但在复制中，您将它们标记为“考虑此删除”并进行筛选 在最后的每一个查询中都会显示它们

是的，这样做有两个主要原因：

• 正确性：如果删除了项而不是删除了项，则可能存在一个不明确的实例，其中查阅了两个节点，其中节点A拥有项，但节点B没有。整个系统无法区分该项是已删除（但a中的删除失败）还是最近创建的（但B中的创建失败）。通过墓碑，可以清楚地看出这一区别
• 性能：大多数系统不执行就地更新（如RDBMS数据库通常所做的），而是执行仅附加的操作。这样做是为了提高性能，因为磁盘中的随机访问操作比顺序操作慢得多。因此，通过墓碑执行删除操作与此方法非常吻合

但实际上，您从未从数据库中删除过某些内容

这不一定是真的。通常，墓碑最终会从数据库中删除（以垃圾收集方式）。这里的最终意思是，当系统可以确保上述示例不再发生在这些项目上时，它们将被删除（因为删除已传播到所有节点）

我的理解是，若发生密钥冲突，您将在复制时遇到竞争条件

这对于大多数这种分布式系统来说都是正确的。结果将取决于操作到达数据库的顺序。但是，其中一些数据库提供了替代机制，如条件写入/删除。这样，您只能删除项目的特定版本，或者仅当项目的版本为特定版本时才更新项目（因此，如果其他人同时更新了项目，则会中止更新）。卡桑德拉的这类操作的一个例子是

---

下面是一些描述Riak和Cassandra如何执行删除的参考资料，其中也包含大量关于墓碑的信息：

---

我不能为那些反对票说话，但我看不出为什么数据库不能删除一行仅仅因为它进行了复制。有符合你假设的数据库系统吗？@Rei：我已经举了一些例子。如果数学上不可能解决这个问题，那么任何数据库管理系统是否能够做到这一点的问题将永远是“否”。因此，问题的答案是“否”（您不能删除）。我知道在基于副本的分布式数据库中执行删除操作与在非分布式数据库中执行删除操作一样简单。这就是为什么我们只有一位大师。我知道这是可能的，如果我们——无论多么有限——侵蚀复制DD复制（通过添加一个或多个决定冲突的主数据库），我看不到任何。我的意思是数据库系统的名称，这样我可以仔细阅读它的文档并确认它不支持删除。@Rei：你没有看到我的示例吗？？？它们占我帖子的一半以上。再说一次：从数学上来说，能解决这个问题吗？如果不是，我们可以寻找一个数据库管理系统来支持它，直到太空母牛回家。我要的是一个符合你假设的数据库系统的名称，而不是示例。这可能是Elasticsearch、Cassandra、CouchDB、MongoDB或其他东西。我在你的帖子中没有看到任何数据库名称。