NoSQL持久化技术笔记
2013-04-24 19:08:51   来源：互联网   评论：0 点击：

NoSQL持久化技术笔记

（内容来自程序员杂志2012年5月） create by kevinlin

持久化定义

将数据写到断电后不会丢失的设备中，比如磁盘

主流NoSQL的持久化策略

* Redis的RDB快照和AOF日志

* MongoDB使用mmap定时fsync以及journaling日志

* CouchDB日志即数据的存储模型

持久化原理

分三步：  

1. 调用write[2]系统调用，逻辑上将数据写到磁盘上。实际此时数据还在系统的内存缓冲区中。

2. 操作系统定时或者强制将内存缓冲区中的数据转移给磁盘控制器中，此时数据在磁盘缓冲区中。

3. 磁盘控制器将磁盘缓冲区中的数据写到磁盘的物理介质中。数据真正落地。

注意：实际环境中，磁盘缓冲区都是关闭或为读缓存状态，对写操作不缓冲，故2，3步合并。关注的重点为两个：

• 何时调用write[2]写到缓冲区中。

• 何时被回写数据（或调用fsync等)到磁盘。

几种典型的持久化方法

数据快照

将当前整个数据集按某个时间点进行一次全量保存，将所有数据写到文件中，通过fsync[2]持久化到磁盘。

Redis的做法： fork子进程来完成数据遍历及回写到文件。 （COW)

Redis的每次快照都会遍历并保存全量数据，当数据集达到几十GB时，一次快照可能要花费几十分钟时间。

内存映射

利用mmap实现数据的快照功能，这是一种偷懒做法，把持久化工作交给了操作系统。

与快照相比的优势：

• 采用mmap方式，数据文件可以远远超过内存大小。理想状态下只需要内存能装下热数据就行。因为操作系统的虚拟内存机制会将内存自动调度给热数据使用。

• 进行持久化时，需要进行的磁盘I/O减少了。脏数据才会回写。

缺陷：

• 在fsync到磁盘的过程中断电或操作系统宕机等，可能会导致数据文件中一部分数据是老的，另一部分是新的。

操作日志

理念：在进行数据添加，修改，更新之前，先写操作日志。这样虽然不用关心数据何时被修改，但其关键点变成日志何时被持久化了。简言之： 操作日志本身的持久化就是数据的持久化。

• 操作日志的持久化问题：

  Redis中，AOF就是操作日志的记录。

  提供三个级别的日志持久化选项。

  • 每次写日志都调用fsync

  • 每秒调用一次

  • 不主动调用fsync

• 操作日志越来越大问题：

  • 提供日志切分或合并重写等功能，以保证日志文件不会无限膨胀。

    • Redis的rewriteaof功能

重做日志

理念：　通过日志文件的持久化与数据文件的持久化相结合的方式来实现数据的持久化。仅需要保存数据文件在上一次fsync之后进行的数据变更。

案例：

• MongoDB的journal日志就是一种重做日志，当MongoDB在某个时间点异常停机后，就可以通过重新执行journal日志中的更新，将MongoDB恢复到异常停机前的状态。

持久化选择

• Redis

  • 使用RDB快照

  • AOF操作日志记录

  提供灵活的持久化机制，使得可在高性能和高安全性之间进行配置。

  在开启AOF并且设置总是fsync的情况下，数据安全性并不比任何传统数据库低。

• MongoDB

  • 使用mmap通过内存映射方式实现

  • journaling日志进行重做。

• BigTable模式

  • 写内存加写日志模式。

  • 有数据变化等先写日志再写内存，等内存大小达到一定程度再将整个数据写到磁盘。保证对磁盘的操作是顺序执行的，提高系统写性能和数据吞吐量。感觉类似MongoDB的模型，但在写上优化了一下。

• CouchDB

  • 独特的数据存储模式，它的数据写操作是追加型的，不仅包括添加数据的操作，也包括数据的修改和删除操作。（MVCC模式）

  • 所有写操作都变成了对磁盘的顺序操作

总结：

    相对与传统数据库，NoSQL产品产不是一味地以牺牲安全性来换取高性能或者扩展性的，只是采用了不同的方法，
    比如尽量将对磁盘的操作顺序化，来减轻在持久化方面的开销。而在你需求时，使用NoSQL也可以达到传统数据
    库的安全程度。