怎么解决NOSQL数据库数据持久性问题

无风之谷

      目前的NOSQL主要分为两种，一种是基于内存型的如redis、memcached，一种是基于磁盘型的如Tokyo Tyrant、Tokyo Cabinet、Berkeley DB。
      redis、memcached这类内存型NOSQL。虽然读写效率很高，但是有一个大问题，就是数据库持久性。memcached是一重启进程数据就没了。redis支持两种持久化方式，一种是 Snapshotting（快照）也是默认方式，另一种是Append-only file（缩写aof）的方式。但是这两种效率都不高。 怎样才能做到高效读写，又能保持数据持久性了?
     
     以下这个解决方案是由CU热心网友“七夜”带来的：
     quickdb 是一款基于内存文件系统的 HashTable数据结构的Key-Value数据引擎. . 什么是内存文件系统了？就是操作系统把系统内存划出一部分当作硬盘使用。你可以像操作磁盘那样的操作内存。但效率远远比硬盘来的快多了。通俗叫做内存文件系统，只要服务器不重起数据将一直都在。
     通俗的来讲 redis、memcached是自己申请内存管理数据。当进程重启或者挂了就会丢失数据。quickdb是把实体数据储存在内存文件系统里的。当quickdb进程挂了，  实体数据依然还在。 一个进程可能因为各种原因比如修改了配置文件或者要调试数据。要经常重启。但是一个服务器不可能三天两天的重启或者死机。 一般服务器都是半年，或者 好几年都不重起的。 如果你的服务器经常断电或者死机重启那就不叫服务器了，叫家用电脑了。quickdb可以定期的从内存文件系统的数据同步到磁盘中去。这样当服务器重启，也不会丢失数据。 简单的来讲，进程可能会经常因为各种原因要重启或者挂了，但是服务器不可能经常重启或者死机。这样很大程度上保证了数据持久性，也保证了读写效率。做到鱼和熊掌兼得。
     quickDB Benchmark 性能测试
     写入3145739条数据 花费4.38秒  读取 3145739条数据花费3.88秒


quickdb下载地址：
http://code.google.com/p/loongsso/downloads/detail?name=quickdb-beta1.tar.bz2&can=2&q=#makechanges

Q: 既然是基于内存文件系统的，那leveldb、tokyocabinet等磁盘类的NOSQL可以直接使用了，为啥还用quickdb了?
A: leveldb、tokyocabinet是专门为硬盘特性而优化的NOSQL。比如增加了合并多个写为一次性写,并有内部的内存缓存系统。 如果使用内存文件系统的话，就会造成多次内存浪费。 quickdb不用缓存，不用合并写。做到简单就是快。

Q:  如果服务器内存不够大,是不是用不了quickdb
A:   内存不够大,也可以用quickdb。 内存文件系统可以用tmpfs。tmpfs是当内存不足的时候，把数据交换到swap区。

下面讲解了linux下的三种不同的内存文件系统类型：
(1)ramdisk,使用前需要先创建文件系统,并且调整文件系统大小比较麻烦,需要修改内核引导参数并重新启动操作系统,在繁杂多变的应用与需要 7X24不间断运行的系统来说,并不是一个可以接受的选择.好处是自2.0版本起内核便支持(这也算好处?嗯,确实算,如果你手头真有这样的系统的话)

(2)ramfs,使用前不需要去创建文件系统了,直接通过mount的方式即可挂载上来用,需要的时候可以使用"mount -o remount,maxsize=..."这种方式来调整大小.

(3)tmpfs,同ramfs在表面上基本上一样啦,不同于ramfs针对"物理内存",tmpfs是在虚拟内存下分配空间的,也就是说tmpfs实例中存储的文件既可能存在于物理内存中,也可能存在于交换分区中,具体存在哪里,是由"虚拟内存子系统"来调度的.

纯性能角度讲,ramfs会在进程占用内存使用较多的情况下会优于tmpfs,在没有交换分区或进程占用内存较小而不发生swap行为的情况下,两者性能不会有差异。

本期讨论话题：1，针对“怎么高效解决NOSQL数据库，数据持久性问题”这个话题分享您在实际生产中的解决方案，经验。
                    2，针对“七夜”带来的解决方案，进行讨论。
讨论时间：2012.1.10——2012.2.10
讨论有奖：     我们将对积极参与讨论的网友进行奖励，我们会对提出更优质方案的网友进行评选，优胜者（可以是多名）将获得CU十周年定制背包一个。
                   对积极参与活动网友（有效回复超过3贴），将获得由IBM笔记本内胆包一个（共5个）

十周年背包


IBM内胆包

epstar

谢谢楼主啊，受益匪浅啊！

大邪神

不用啊

jiyuwoaa

支持~！！！！！！！！！！

hitsubunnu

hobbs136 发表于 2012-03-09 16:38
第一 我觉得不要试图去搞一些nosql不擅长的功能，例如保证acid的事务特性。
第二 我认为你的持久化方案简直 ...

就这位兄弟说的话 靠谱

hobbs136

第一 我觉得不要试图去搞一些nosql不擅长的功能，例如保证acid的事务特性。
第二 我认为你的持久化方案简直是糟糕透顶了。我逐条分析
1.
"什么是内存文件系统了？就是操作系统把系统内存划出一部分当作硬盘使用。你可以像操作磁盘那样的操作内存。但效率远远比硬盘来的快多了"
首先相比直接操作内存来说，这增加了代码的复杂度。用文件形式存储key和value，那你不得不自己去管理偏移量了，可能你选择管理空闲块链表，
但是无论如何，这都会增加代码量，增加cpu的处理周期。
"当quickdb进程挂了，实体数据依然还在。一个进程可能因为各种原因比如修改了配置文件或者要调试数据。要经常重启。但是一个服务器不可能三天两天的重启或者死机。 一般服务器都是半年，或者好几年都不重起的。如果你的服务器经常断电或者死机重启那就不叫服务器了，叫家用电脑了。quickdb可以定期的从内存文件系统的数据同步到磁盘中去。这样当服务器重启，也不会丢失数据"
上面这句话毛病最多。"进程挂了，实体数据依然还在，这根本不算一个优点"。设计良好的服务程序怎么可能自己挂掉了？那么多nosql数据库都没有提过这点。那么多sql数据库也没有提过这点。修改配置文件或者调试数据，要经常重启。靠，进程正常结束时操作系统会将所有需要持久化的数据冲刷进硬盘的。
  "但是一个服务器不可能三天两天的重启或者死机。一般服务器都是半年，或者好几年都不重起的。如果你的服务器经常断电或者死机重启那就不叫服务器了，叫家用电脑了"。 这好像是服务器推销员的口吻。各种数据库要考虑的就是非正常宕机的情况，虽然宕机的几率很低，但是各种数据库都为此牺牲了很多。但是这个quickdb却不是，且看下面这句话。
  "quickdb可以定期的从内存文件系统的数据同步到磁盘中去，这样当服务器重启，也不会丢失数据"。就这句话，你都没说这个时间窗口到底是多大，用户到底会损失多少数据啊。
  
  "这样很大程度上保证了数据持久性，也保证了读写效率。做到鱼和熊掌兼得"。这句话完全不靠谱。因为下面又说，每天备份一次，苍天，我还是用我的redis好了。
  
第三 那个测试毫无意义，因为没有考虑并发这种情况。
第四 还需要特殊的运维操作，就是创建内存文件系统，增加系统整体复杂度。
第五 看着那个id为“我要思考”的家伙的留言我就想笑，他大概是刚开始思考。
第六 我的建议
认清各种事物的用途，没有一个nosql数据库用内存文件系统来存储文件，所以不要标新立异。潜下心来，好好读一下开源程序的代码。从设计上，利用现有的软件解决实际中的问题。现在存储的问题就是cap的问题，请沿着这个方向走。

lihualoveyou

T-Bagwell 发表于 2012-03-07 13:07
掉电重启以后内存中的数据还会存在？

通用的服务器估计不行，BIOS启动之后好像会有初始化内存的操作。不过，现在的磁盘阵列都是用这种方式来保证缓存数据不丢失的。

T-Bagwell

lihualoveyou 发表于 2012-03-07 11:18
回复 22# T-Bagwell
个人觉得，要解这个问题可以从系统层做文章。
可以通过掉电保护单元（BBU）解决宕机 ...

掉电重启以后内存中的数据还会存在？

lihualoveyou

回复 22# T-Bagwell
个人觉得，要解这个问题可以从系统层做文章。
可以通过掉电保护单元（BBU）解决宕机后数据丢失问题。比如，掉电重启后，先把内存的数据刷到硬盘上。
内存坏掉的话，可以做内存镜像，不过有点难度，需要对内存管理机制进行调整，确保镜像确实是在两条不同的内存条上。或者干脆所有的内存都mirror.

感觉超出了这个软件需要解决的范围了，呵呵


   

witer666

好的冗灾，好的共享内存，好的数据热备

Darleter

喜欢这帖子。
七夜的blog我也很喜欢。