免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
最近访问板块 发新帖
楼主: 无风之谷

怎么解决NOSQL数据库数据持久性问题 [复制链接]

论坛徽章:
0
发表于 2012-01-10 17:24 |显示全部楼层
支持分布式? 支持读写分离?

论坛徽章:
0
发表于 2012-01-10 18:11 |显示全部楼层
回复 21# 七夜


    这个办法不错。。。。

论坛徽章:
0
发表于 2012-01-10 18:13 |显示全部楼层
回复 24# 七夜


    其实,我比较关注的,如果在系统负载率比较高的情况下,你还能不能保证你的读写效率,这方面有没有做过相关的测试了?

论坛徽章:
33
ChinaUnix元老
日期:2018-07-04 15:10:362015年亚洲杯之阿联酋
日期:2015-02-06 17:15:532015亚冠之武里南联
日期:2015-06-06 15:40:252015亚冠之北京国安
日期:2015-06-17 15:42:412022北京冬奥会纪念版徽章
日期:2015-08-10 16:30:322015亚冠之阿尔纳斯尔
日期:2015-09-20 09:42:1215-16赛季CBA联赛之北京
日期:2016-01-15 10:03:5915-16赛季CBA联赛之青岛
日期:2016-04-26 16:44:4915-16赛季CBA联赛之广夏
日期:2018-07-04 15:33:21C
日期:2016-10-25 16:12:142017金鸡报晓
日期:2017-01-10 15:19:5615-16赛季CBA联赛之同曦
日期:2017-02-22 22:41:10
发表于 2012-01-10 19:01 |显示全部楼层
差点看成MYSQL

论坛徽章:
59
2015七夕节徽章
日期:2015-08-24 11:17:25ChinaUnix专家徽章
日期:2015-07-20 09:19:30每周论坛发贴之星
日期:2015-07-20 09:19:42ChinaUnix元老
日期:2015-07-20 11:04:38荣誉版主
日期:2015-07-20 11:05:19巳蛇
日期:2015-07-20 11:05:26CU十二周年纪念徽章
日期:2015-07-20 11:05:27IT运维版块每日发帖之星
日期:2015-07-20 11:05:34操作系统版块每日发帖之星
日期:2015-07-20 11:05:36程序设计版块每日发帖之星
日期:2015-07-20 11:05:40数据库技术版块每日发帖之星
日期:2015-07-20 11:05:432015年辞旧岁徽章
日期:2015-07-20 11:05:44
发表于 2012-01-10 22:40 |显示全部楼层
本帖最后由 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也有能这么一天。

论坛徽章:
323
射手座
日期:2013-08-23 12:04:38射手座
日期:2013-08-23 16:18:12未羊
日期:2013-08-30 14:33:15水瓶座
日期:2013-09-02 16:44:31摩羯座
日期:2013-09-25 09:33:52双子座
日期:2013-09-26 12:21:10金牛座
日期:2013-10-14 09:08:49申猴
日期:2013-10-16 13:09:43子鼠
日期:2013-10-17 23:23:19射手座
日期:2013-10-18 13:00:27金牛座
日期:2013-10-18 15:47:57午马
日期:2013-10-18 21:43:38
发表于 2012-01-11 11:45 |显示全部楼层
应用程序还是要通过read/write访问数据,就像访问普通文件一样?这样应用程序一般来说还得在内存中维护一份数据,有没有办法减少内存的占用和复制呢?

论坛徽章:
323
射手座
日期:2013-08-23 12:04:38射手座
日期:2013-08-23 16:18:12未羊
日期:2013-08-30 14:33:15水瓶座
日期:2013-09-02 16:44:31摩羯座
日期:2013-09-25 09:33:52双子座
日期:2013-09-26 12:21:10金牛座
日期:2013-10-14 09:08:49申猴
日期:2013-10-16 13:09:43子鼠
日期:2013-10-17 23:23:19射手座
日期:2013-10-18 13:00:27金牛座
日期:2013-10-18 15:47:57午马
日期:2013-10-18 21:43:38
发表于 2012-01-11 13:39 |显示全部楼层
看了下代码,跟我想象的不是一回事

论坛徽章:
323
射手座
日期:2013-08-23 12:04:38射手座
日期:2013-08-23 16:18:12未羊
日期:2013-08-30 14:33:15水瓶座
日期:2013-09-02 16:44:31摩羯座
日期:2013-09-25 09:33:52双子座
日期:2013-09-26 12:21:10金牛座
日期:2013-10-14 09:08:49申猴
日期:2013-10-16 13:09:43子鼠
日期:2013-10-17 23:23:19射手座
日期:2013-10-18 13:00:27金牛座
日期:2013-10-18 15:47:57午马
日期:2013-10-18 21:43:38
发表于 2012-01-11 15:23 |显示全部楼层
在我的RHEL 5.3 x86_64编译错误,是pstdint.h中的一些定义类型冲突,懒得去弄了。
似乎是hash的key等信息用mmap,value 写到另外的数据文件中。这样进程挂了并不能保证mmap中的数据是正确的,有可能其中的某些长度数据错误,导致数据文件解析错误,整个HashTable都无法恢复。

论坛徽章:
0
发表于 2012-01-11 17:53 |显示全部楼层
redis好像也是定期刷到磁盘里吧

论坛徽章:
323
射手座
日期:2013-08-23 12:04:38射手座
日期:2013-08-23 16:18:12未羊
日期:2013-08-30 14:33:15水瓶座
日期:2013-09-02 16:44:31摩羯座
日期:2013-09-25 09:33:52双子座
日期:2013-09-26 12:21:10金牛座
日期:2013-10-14 09:08:49申猴
日期:2013-10-16 13:09:43子鼠
日期:2013-10-17 23:23:19射手座
日期:2013-10-18 13:00:27金牛座
日期:2013-10-18 15:47:57午马
日期:2013-10-18 21:43:38
发表于 2012-01-11 20:58 |显示全部楼层
七夜 发表于 2012-01-11 16:55
任何一个nosql,都会有索引文件和实体数据文件的。 像key-value数据库,都是通过key的索引去查找数据的 ...


在你的实现中我没找到这方面的考虑呀
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们:huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP