Mongo DB如何处理应用死机等中途故障 [英] How to handle application death and other mid-operation faults with Mongo DB

问题描述

由于 Mongo 没有可用于确保除非数据一致(未损坏)的数据不向数据库提交任何内容的事务，如果我的应用程序在写入一个文档和进行相关写入之间死亡另一个文档，我可以使用哪些技术来删除损坏的数据和/或以某种方式恢复?

Since Mongo doesn't have transactions that can be used to ensure that nothing is committed to the database unless its consistent (non corrupt) data, if my application dies between making a write to one document, and making a related write to another document, what techniques can I use to remove the corrupt data and/or recover in some way?

推荐答案

NoSQL 背后的更大想法是针对特定问题使用精心建模的数据结构，而不是用锤子敲击每个问题.对于应称为短期事务"的事务也是如此，因为典型的 RDBMS 事务几乎对真实"、长期事务没有帮助.

The greater idea behind NoSQL was to use a carefully modeled data structure for a specific problem, instead of hitting every problem with a hammer. That is also true for transactions, which should be referred to as 'short-lived transactions', because the typical RDBMS transaction hardly helps with 'real', long-lived transactions.

通常只需要 RDBMS 支持的事务类型，因为有限的数据模型迫使您跨多个表存储数据，而不是使用嵌入式数组(想想典型的发票/发票项目示例).

The kind of transaction supported by RDBMSs is often required only because the limited data model forces you to store the data across several tables, instead of using embedded arrays (think of the typical invoice / invoice items examples).

在 MongoDB 中，尝试使用写入繁重、非规范化的数据结构并将数据保存在单个文档中，从而提高读取速度、数据局部性并确保一致性.这样的数据模型也更容易扩展，因为单个读取只会访问单个服务器，而不必从多个来源收集数据.

In MongoDB, try to use write-heavy, de-normalized data structures and keep data in a single document which improves read speed, data locality and ensures consistency. Such a data model is also easier to scale, because a single read only hits a single server, instead of having to collect data from multiple sources.

但是，在某些情况下，必须在各种上下文中读取数据并且去规范化变得不可行.在这种情况下，您可能需要查看 Two-Phase Commits 或选择一个完全不同的并发方式，比如MVCC(一句话，就是svn、git之类的等做).然而，后者几乎不是 RDBM 的直接替代品，而是向更高级别的应用程序(如果不是用户)公开了一种完全不同的并发性.

However, there are cases where the data must be read in a variety of contexts and de-normalization becomes unfeasible. In that case, you might want to take a look at Two-Phase Commits or choose a completely different concurrency approach, such as MVCC (in a sentence, that's what the likes of svn, git, etc. do). The latter, however, is hardly a drop-in replacement for RDBMs, but exposes a completely different kind of concurrency to a higher level of the application, if not the user.

这篇关于Mongo DB如何处理应用死机等中途故障的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！