支持分布式? 支持读写分离?
回复 21# 七夜
这个办法不错。。。。
回复 24# 七夜
其实，我比较关注的，如果在系统负载率比较高的情况下，你还能不能保证你的读写效率，这方面有没有做过相关的测试了？
差点看成MYSQL
本帖最后由 renxiao2003 于 2012-01-12 12:55 编辑
1，针对“怎么高效解决NOSQL数据库，数据持久性问题”这个话题分享您在实际生产中的解决方案，经验。
随着内存价格的降低，针对关系型数据库的ORM软件层出不穷，其原理就是先在内存区域开辟足够的空间来存储数据库的数据，然后在内存中操作这些数据，在需要时再批量将数据存储回关系数据库系统中。其实从这个方面来看，quickdb可能就是借签了关系数据库的这些ORM框架的经验来实现的。但关系数据库最终存储的也是系统文件，只是在中间架构了一些DBMS系统来管理这些系统文件，而不是由ORM框架来直接操作系统文件。quickdb只是相当于在ORM框架和系统文件中省略了DBMS而已。是否可以将quickdb看成是NOSQL的相当于ORM的框架实现呢？
现在的NOSQL有基于内存的，也有基于磁盘的。那么如果有一个框架来实现从内存和磁盘的MAP，那么就可以提高磁盘NOSQL的性能了。只是目前的NOSQL属于百家争鸣阶段，还没有形成统一的标准，所以想开发一个兼容多种NOSQL的MAP框架就比较有难度了啊。这也是NOSQL目前发展的瓶颈了吧。
2，针对“七夜”带来的解决方案，进行讨论。
“七夜”提供的这个quickdb确实是一个不错的能提高NOSQL的性能的“家伙”，可惜如第一条叙述的一样，正是因为目前NOSQ的百家争鸣，没有统一的标准，所以quickdb也只能适用自己的系统，如果业界能定义出NOSQL的统一的标准，我想某一天，quickdb就可以兼容所有的NOSQL系统，这样我们也不用刻意的去区分到底是内存型的NOSQL还是磁盘型的NOSQL了。就像当今的HIBERNAT一样，我一下子就兼容了所有的关系数据库软件，只要你使用“我”，就不用去特意考虑底层RDBMS的不同。“我”已经帮你考虑完了。期待NOSQL也有能这么一天。
应用程序还是要通过read/write访问数据，就像访问普通文件一样？这样应用程序一般来说还得在内存中维护一份数据，有没有办法减少内存的占用和复制呢？
看了下代码，跟我想象的不是一回事
在我的RHEL 5.3 x86_64编译错误，是pstdint.h中的一些定义类型冲突，懒得去弄了。
似乎是hash的key等信息用mmap，value 写到另外的数据文件中。这样进程挂了并不能保证mmap中的数据是正确的，有可能其中的某些长度数据错误，导致数据文件解析错误，整个HashTable都无法恢复。
redis好像也是定期刷到磁盘里吧
七夜 发表于 2012-01-11 16:55 static/image/common/back.gif
任何一个nosql，都会有索引文件和实体数据文件的。 像key-value数据库，都是通过key的索引去查找数据的 ...
在你的实现中我没找到这方面的考虑呀