<![CDATA[张宴的博客]]>

<![CDATA[张宴的博客]]> http://zyan.cc/index.php zh-cn http://zyan.cc/post/329/ <![CDATA[dbcached──“分布式 key-value 数据库内存缓存系统”发布[原创]]]> 张宴 <net@s135.com> Mon, 18 Feb 2008 12:22:52 +0000 http://zyan.cc/post/329/
　　dbcached

　　协议：New BSD License
　　作者：张宴
　　网址：http://code.google.com/p/dbcached/

　　dbcached 是什么?

　　● dbcached 是一款基于 Memcached 和 NMDB 的分布式 key-value 数据库内存缓存系统。

　　● dbcached = Memcached + 持久化存储管理器 + NMDB 客户端接口

　　● Memcached 是一款高性能的，分布式的内存对象缓存系统，用于在动态应用中减少数据库负载，提升访问速度。

　　● NMDB 是一款多协议网络数据库(dbm类)管理器，它由内存缓存和磁盘存储两部分构成，使用 QDBM 或 Berkeley DB 作为后端数据库。

　　● QDBM 是一个管理数据库的例程库，它参照 GDBM 为了下述三点而被开发：更高的处理速度，更小的数据库文件大小，和更简单的API。QDBM 读写速度比 Berkeley DB 要快，详细速度比较见《Report of Benchmark Test》。

　　

　　Memcached 和 dbcached 在功能上一样吗?

　　● 兼容：Memcached 能做的，dbcached 都能做。除此之外，dbcached 还将“Memcached、持久化存储管理器、NMDB 客户端接口”在一个程序中结合起来，对任何原有 Memcached 客户端来讲，dbcached 仍旧是个 Memcached 内存对象缓存系统，但是，它的数据可以持久存储到本机或其它服务器上的 QDBM 或 Berkeley DB 数据库中。

............

Tags - linux , memcached , memcache , dbcached , nmdb , qdbm , memcachedb , php ]]> http://zyan.cc/post/329/#blogcomment683 <![CDATA[[评论] dbcached──“分布式 key-value 数据库内存缓存系统”发布[原创]]]> 乐百氏 <user@domain.com> Tue, 19 Feb 2008 02:03:27 +0000 http://zyan.cc/post/329/#blogcomment683 http://zyan.cc/post/329/#blogcomment684 <![CDATA[[评论] dbcached──“分布式 key-value 数据库内存缓存系统”发布[原创]]]> outrace <user@domain.com> Tue, 19 Feb 2008 02:25:23 +0000 http://zyan.cc/post/329/#blogcomment684 跟Memcachedb 项目有啥差异？ ]]> http://zyan.cc/post/329/#blogcomment686 <![CDATA[[评论] dbcached──“分布式 key-value 数据库内存缓存系统”发布[原创]]]> powerv <user@domain.com> Tue, 19 Feb 2008 18:25:20 +0000 http://zyan.cc/post/329/#blogcomment686 http://zyan.cc/post/329/#blogcomment688 <![CDATA[[评论] dbcached──“分布式 key-value 数据库内存缓存系统”发布[原创]]]> dd <user@domain.com> Wed, 20 Feb 2008 07:08:33 +0000 http://zyan.cc/post/329/#blogcomment688 QDBM 或 Berkeley DB 这样的数据库中
当客户端在Memcached 中没有知道到请求的的数据然后到 QDBM 或 Berkeley DB 中查找

这样和直接从数据库中读取区别很大吗 ]]> http://zyan.cc/post/329/#blogcomment689 <![CDATA[[评论] dbcached──“分布式 key-value 数据库内存缓存系统”发布[原创]]]> 代码罐头 <user@domain.com> Wed, 20 Feb 2008 11:41:33 +0000 http://zyan.cc/post/329/#blogcomment689 master-slave模式就可以了
考虑到主从模式.写操作的时候从服务器的负载以及网络负载问题
可以在应用上做数据库的垂直分割.
memcache本来就是作为临时cache存在的.
如果修改成了持久性的数据cache层.
那么我个人还是觉得数据库用主从模式就可以解决了.
这样对应用层的要求也会比较小.
因为MEMCACHE对应用层的改动太大.要求的工作也很多.
至于千万级的数据查询.如果你把这么多数量的内容都作为key来做memcache
这个性能一样不会高到哪里去的.
memcache只有对于最最常用的东西做cache才有效的.

至于插入问题.memcache只是缓冲层
他的插入也只是临时性的
虽然memcache可以将操作速度大大提高
但是最终数据仍旧是要跑到主数据库保存的
由于木桶理论.你的这个操作再快,也无法解决整体结构中写操作的速度
如果用了事务那就更加慢了.
除非你把写操作也cache下来.然后后台再把memcache里面的内容写到mysql里面,而不是由应用层来做这个工作.否则memcache写性能在强也于事无补的.

一些拙见.大家探讨. ]]> http://zyan.cc/post/329/#blogcomment690 <![CDATA[[评论] dbcached──“分布式 key-value 数据库内存缓存系统”发布[原创]]]> 代码罐头 <code_tin@msn.com> Wed, 20 Feb 2008 12:16:33 +0000 http://zyan.cc/post/329/#blogcomment690 变成解决数据库的高可用性和负载均衡问题.
简言之就是数据库的虚拟化.
memcache本身只是作为cache存在
cache的目的纯粹是为了慢速设备和快速设备之间做缓冲
而持久性和可靠性并不计在内(所有的cache在掉电后都允许数据损失,而且即便cache数据不可靠.也没有关系.因为cache不是最终数据保存的地方,cache允许数据存在时差或者误差)
memcache之所以存在许多不足.
不是由于它没有持久数据或者它的可靠性不足
而是由于它并非是从数据库存取数据
需要靠应用层主动对缓冲数据进行操作.
memcache这种手动优化的方法
在程序小的时候不会有问题,一旦程序框架变大
就变成整个项目需要手动优化数据存取

解决数据库虚拟的方法在于
在应用层下面建立透明的代理层
mysqlproxy项目的概念是非常好的.
虚拟化了后端的数据库服务器之后
不论是HA,还是LB,都可以通过代理层进行透明的操作.
代理可以对执行的操作进行简单的分类,比如读,还是写,对哪个库,哪个表操作.
代理层通过分析后,可以将实际的操作交由不同的后端数据库来做.
这样不论是读写分离,还是数据库垂直,水平分割,或者高可用性.
都是通过一个透明层来进行虚拟化.

memcache只是在虚拟化途中的一个临时变通手段
如果张兄继续优化.最终可能会变成一个类似MySQL Proxy的东西
不论现在做的什么手段
最终大家需要的.应该是一个类似LVS的MYSQL虚拟机 ]]> http://zyan.cc/post/329/#blogcomment691 <![CDATA[[评论] dbcached──“分布式 key-value 数据库内存缓存系统”发布[原创]]]> 代码罐头 <user@domain.com> Thu, 21 Feb 2008 01:04:40 +0000 http://zyan.cc/post/329/#blogcomment691

引用

对于千万级的数据，Memcached是很快的，因为它是根据key，确定value在内存中的位置，从而取出数据，性能跟数据条数无关。不然 Facebook 也不会弄400台 16GB 的机器来跑 memcached。

和我猜想的用法很像.
memcache在这里其实类似于mysql的query cache
不过这样.可以完全抛弃memcache的固有做法
因为你的问题域减小了.不再是所有网页内容的cache.而是mysql select查询的cache.
而从应用层来自己做set.get.
我一直认为不是件很好的事情
分层就会逐渐模糊.

我建议dbcached做一个mysql-like的接口
将获取到的select query做hash,和hash table里面的比对
如果cache未命中,则发送到后端的mysql
cache命中,则直接返回内存中的内容
这样这个cache对于上层就是完全透明的. ]]> http://zyan.cc/post/329/#blogcomment692 <![CDATA[[评论] dbcached──“分布式 key-value 数据库内存缓存系统”发布[原创]]]> 乐百氏 <user@domain.com> Thu, 21 Feb 2008 01:51:42 +0000 http://zyan.cc/post/329/#blogcomment692
感觉这个dbcached和sina的memcachedb作用差不多。

dbcached的设计的和实际的出发点有些别离，感觉有些南辕北辙 ]]> http://zyan.cc/post/329/#blogcomment693 <![CDATA[[评论] dbcached──“分布式 key-value 数据库内存缓存系统”发布[原创]]]> Roast <user@domain.com> Thu, 21 Feb 2008 03:03:14 +0000 http://zyan.cc/post/329/#blogcomment693 咋的不直接用QDBM了了？ ]]> http://zyan.cc/post/329/#blogcomment697 <![CDATA[[评论] dbcached──“分布式 key-value 数据库内存缓存系统”发布[原创]]]> sumdunk <user@domain.com> Fri, 22 Feb 2008 02:55:47 +0000 http://zyan.cc/post/329/#blogcomment697
举个例子,发一个文章,同时POST的数据有很多,TITLE,CONTENT.DATE.等,.如果先进行DBCACHE,怎么进行保存,后端进行QDBM备份时候,逻辑应该也会很复杂吧. ]]> http://zyan.cc/post/329/#blogcomment698 <![CDATA[[评论] dbcached──“分布式 key-value 数据库内存缓存系统”发布[原创]]]> 非狐外传 <user@domain.com> Fri, 22 Feb 2008 08:55:15 +0000 http://zyan.cc/post/329/#blogcomment698 http://zyan.cc/post/329/#blogcomment699 <![CDATA[[评论] dbcached──“分布式 key-value 数据库内存缓存系统”发布[原创]]]> 代码罐头 <user@domain.com> Fri, 22 Feb 2008 09:35:11 +0000 http://zyan.cc/post/329/#blogcomment699

引用

想问一下.如果单笔数据量很大.且有很复杂的关联性.dbcached会不会胜任.因为MEMCACHE似乎只是KEY->VALUE的存储,

举个例子,发一个文章,同时POST的数据有很多,TITLE,CONTENT.DATE.等,.如果先进行DBCACHE,怎么进行保存,后端进行QDBM备份时候,逻辑应该也会很复杂吧.

呵呵.这个问题恰恰就是memcache的本质性的弊端了
因为他要求开发人员手动对缓冲内容进行处理.
开发人员需要预判缓冲可能发生的最高的情况.
如果实际状况和预判的不同
则命中率低下的开销会大过开发难度的提升.
而实际情况中,对于缓冲内容是会根据不同用户的不同时期的需求发生改变的.

而针对数据库的缓冲层(以下简称mysqlcache).我觉得和memcache的工作机理相同,但是还有很多本质区别.
其差别基本上等同于xcache这类的op cache和memcache这种内容cache
1.mysql缓冲层对于上层是透明的.程序员应该和操作mysql数据库一样去操作mysqlcache,而memcache则是由开发人员来决定哪些内容放入cache.上层是需要针对memcache来做操作的.
2.mysqlcache可以和其他的虚拟层一样,通过本身的策略来决定cache的保留与丢弃,这些用户只需要在配置文件内修改,同样保证了透明性,而memcache需要在应用层内决定保留哪些,丢弃哪些,如果不对已经缓冲资源进行丢弃.势必导致超出memcache服务器的内存容量,导致swap,引起性能下降.
3.mysqlcache是对整条mysql语句进行hash,而memcache是对某特定内容进行hash,memcache从某种程度来说(mysql使用过多如selecte *等未优化语句)占用内存更小
4.mysqlcache可以轻易加入负载均衡或者高可用性功能,由于其是代理层,可以对后端的mysql状态或者查询进行分发,memcache其实是和mysql平行的一个模块.是在应用层使用的缓冲技术,从理论上来说如果没有独立的mysql负载均衡或者HA措施,memcache对这两者是无能为力的.因为memcache的数据是由应用层取出并放入,而不是它本身直接去操作数据库的.

对mysql的透明代理应用感兴趣的.可以看看mysql proxy项目,不过目前还不是stable的.所以在性能以及稳定性方面还没有确切的保证.但是其可能的用途是非常好的.
1.mysql的HA.这点已经做到了
2.mysql的负载均衡.这点也完成了
3.mysql的读写分离.这点也完成了
4.mysql的数据表的纵向分割,这点我没有实验是否可行,但是理论上是可以的.我们可以通过分析获取到的查询所针对的表名,然后将不同表的查询分发至不同的mysql后端
5.mysql的数据横向分割,理论上也是可行的,但是难度很高.可以分析where子条件中来语句属于哪一段,从而分发到不同的后端.但是开销很大.我很怀疑这样做了以后.mysql proxy本身会变成瓶颈 ]]> http://zyan.cc/post/329/#blogcomment814 <![CDATA[[评论] dbcached──“分布式 key-value 数据库内存缓存系统”发布[原创]]]> Robin <user@domain.com> Thu, 20 Mar 2008 06:50:39 +0000 http://zyan.cc/post/329/#blogcomment814 http://zyan.cc/post/329/#blogcomment982 <![CDATA[[评论] dbcached──“分布式 key-value 数据库内存缓存系统”发布[原创]]]> tim <user@domain.com> Wed, 23 Apr 2008 09:35:04 +0000 http://zyan.cc/post/329/#blogcomment982
我目前的情况是用memcache作session数据处理,后端用了mysql来做持久,如果改用dbcached有风险吗? ]]> http://zyan.cc/post/329/#blogcomment983 <![CDATA[[评论] dbcached──“分布式 key-value 数据库内存缓存系统”发布[原创]]]> 空格 <user@domain.com> Wed, 23 Apr 2008 16:32:37 +0000 http://zyan.cc/post/329/#blogcomment983