NoSQL(MongoDB)中的提交和磁盘持久性 [英] Commit and disk persistence in a NoSQL(MongoDB)

问题描述

在 NoSQL 数据库中，我们没有事务(提交)，所以我想知道数据库如何提交持久性?

In a NoSQL db we don't have transaction (commit) so I am wondering how db commit the persistence?

当我们告诉 db 只保存对象时，并不意味着它在磁盘上，刷新缓存应该是磁盘持久性的句柄.我 RDBMS 事务的提交保证数据在磁盘上，那么 MongoDB 或其他 NoSQL 呢?

when we are telling to db just save the object, it doesn't mean it is on the disk, flushing the cache should be handle for disk persistence. I RDBMS the transaction's commit guarantees the data is on the disk, what about the MongoDB or other NoSQLs?

n,

推荐答案

我想知道这个模因来自哪里.首先，由于所有的缓存层，没有真正保证任何东西都会写入实际的 HDD，即使是传统的 RDBMS 也不会一直尝试写入文件，否则它们不会如此很快，但细节差异很大(参见例如 InnoDB 中的自适应刷新).

I wonder where this meme comes from. First, nothing really guarantees that anything is written to the actual HDD because of all the caching layers, and even traditional RDBMS don't attempt to write to files all the time, otherwise they wouldn't be so fast, but the details vary greatly (see for example adaptive flushing in InnoDB).

您应该只关心第一层，这本质上是数据库尝试写入磁盘时的问题.现在有了第一个缓存层:许多数据库(包括 MongoDB)使用日志记录，而不是写入实际的表/集合:写入将定期合并回实际数据文件的仅附加文件.任何事情都发生了，它在日记中，你很好.

You should only concern yourself with the first layer which is essentially the question when the database tries to write to disk. Now there is the first caching layer: Instead of writing into the actual tables/collections, many DBs (including MongoDB) use journaling: Write to an append-only file that will be regularly merged back into the actual data files. In anything goes down and it's in the journal, you're fine.

现在的问题是你是否想给期刊写信以及如何写.在 MongoDB 中，您可以使用 写关注 来控制它，即您可以让您的应用程序代码等待 MongoDB 写入日志以进行特定写入(或所有写入).在 MongoDB 中，如果日志和数据文件在不同的块设备上，则等待日志提交最多需要 10 毫秒，如果它们在同一块设备上，则默认配置为 33 毫秒.如果需要，也可以修改 journalCommitInternval.

Now the question is whether you want to write to the journal and how to do it. In MongoDB, you can control this using the write concern, i.e. you can have your application code wait until MongoDB has written to the journal for a specific write (or for all writes). In MongoDB, waiting for the journal commit takes at most 10ms with default configuration if the journal and data files are on different block devices, 33ms if they are on the same block device. The journalCommitInternval can also be modified if required.

我在另一个答案中收集了一些关于 MongoDB 日志的详细信息在另一个答案中.

I gathered some details on MongoDB's journalling in another answer.

顺便说一句，持久性与事务并没有太大关系.事务提供隔离和一致性，例如您可以一次性更改多项内容，并且读者可以保证获得新的或旧的，但不会获得介于两者之间的状态.换句话说，一个事务安全的数据库可以是一个完全不写入磁盘的内存数据库.

As a side note, durability doesn't really have a lot to do with transactions. Transactions provide isolation and consistency, e.g. you can change multiple things in one go and readers are guaranteed to get either the new or the old, but not some in-between state. In other words, a transaction-safe database could be an in-memory database which doesn't write to the disk at all.

这篇关于NoSQL(MongoDB)中的提交和磁盘持久性的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！