关键字: memcachedb
memcachedb是一个由新浪网的开发人员开放出来的开源项目，给memcached分布式缓存服务器添加了Berkeley DB的持久化存储机制和异步主辅复制机制，让memcached具备了事务恢复能力、持久化能力和分布式复制能力，非常适合于需要超高性能读写速度，但是不需要严格事务约束，能够被持久化保存的应用场景，例如memcachedb被应用在新浪博客上面。
memcachedb给memcached添加了一些数据库才具备的特性，但是我们还不能说memcachedb已经是一个数据库了，这是因为memcached不支持内存对象的遍历操作，当然更加不能支持复杂的查询操作，只能支持根据已知的key去查询对应的value。因此如果想把memcachedb当成一个高性能的分布式内存数据库来使用的话，查询的问题就没有办法解决，只能在应用程序里面配合其他方案做一些折衷。
然而memcached的另外一个开源项目完美的填补了这一个缺陷，就是memcache_engine。
memcache_engine是一个MySQL数据库的存储引擎，目前只支持MySQL5.1数据库，他能够把memcachedb作为MySQL数据库的一个存储引擎和MySQL集成起来，让用户通过标准的SQL查询语句访问memcachedb中存放的数据，请看如下示例：
创建表a，存放在分布式memcached server：localhost:6666和localhost:6688当中。然后我们就可以使用标准的SQL语句随意的进行CRUD操作去使用memcachedb了，这实在是太酷了！有了memcache_engine，我们就可以用SQL去访问memcached，有了memcachedb，我们就不必担心数据丢失问题，事务恢复问题了，简直是绝配，让memcached真正成为了一个高性能的分布式数据库系统了。目前memcache_engine项目还是早期试验阶段，让我们期待memcache_engine项目早日发布正式版本吧！
顺便多说几句：最近一年来，特别是最近一个月以来，围绕memcached的开源项目发展的非常非常活跃：
1、最近刚刚发布了memcached的新的高性能C客户端接口: libmemcached
2、由于有了libmemcached，该组织又发布了memcache_engine存储引擎，cool！
3、由于libmemcached的发布，不到一周时间，ruby的两个崭新的memcache client就问世了，他们是Caffeine和New memcache-client，让ruby访问memcached的速度大幅度提高，请看：libmemcached发布了，ruby访问memcached提速20倍
4、memcachedb发布了，这是中国的互联网公司贡献的开源项目
以上几个项目都是在2008年1月发布的，真的不是一般的繁荣阿。再加上之前发布的新的支持异步访问的Java Memcached API和C#接口，可以说除了Python，其他主流非主流编程语言都可以使用memcached了。其实即便是Python还没有公布出来的开源接口，我们也知道国内的web2.0网站豆瓣就是使用Python访问memcached，并且支持了极大的访问量，因此目前围绕memcached的开源项目发展的情况非常的繁荣。
memcached最近两年这么受欢迎，其实和互联网web2.0的流行有很大的关系，web2.0网站通常需要个性化页面，依赖于页面局部和数据细颗粒度的缓存来提升性能，并且web2.0网站流量都很大，因此memcached这种高性能分布式缓存服务器就大行其道了。
当然我觉得最具有革命意义的还是memcache_engine和memcachedb这两个项目的发布，他们能够让memcached的用途不仅仅限于缓存服务器而已，而是能够真正充当分布式数据库来使用了，这无异是诸多大流量web2.0网站和开发人员的福音阿。
memcachedb给memcached添加了一些数据库才具备的特性，但是我们还不能说memcachedb已经是一个数据库了，这是因为memcached不支持内存对象的遍历操作，当然更加不能支持复杂的查询操作，只能支持根据已知的key去查询对应的value。因此如果想把memcachedb当成一个高性能的分布式内存数据库来使用的话，查询的问题就没有办法解决，只能在应用程序里面配合其他方案做一些折衷。
然而memcached的另外一个开源项目完美的填补了这一个缺陷，就是memcache_engine。
memcache_engine是一个MySQL数据库的存储引擎，目前只支持MySQL5.1数据库，他能够把memcachedb作为MySQL数据库的一个存储引擎和MySQL集成起来，让用户通过标准的SQL查询语句访问memcachedb中存放的数据，请看如下示例：
Sql代码 
- CREATE TABLE `a` (
- `a` int(11) NOT NULL DEFAULT '0',
- `b` int(11) DEFAULT NULL,
- `c` int(11) DEFAULT NULL,
- PRIMARY KEY (`a`)
- ) ENGINE=MEMCACHE DEFAULT CHARSET=latin1
- CONNECTION='localhost:6666\;localhost:6688';
创建表a，存放在分布式memcached server：localhost:6666和localhost:6688当中。然后我们就可以使用标准的SQL语句随意的进行CRUD操作去使用memcachedb了，这实在是太酷了！有了memcache_engine，我们就可以用SQL去访问memcached，有了memcachedb，我们就不必担心数据丢失问题，事务恢复问题了，简直是绝配，让memcached真正成为了一个高性能的分布式数据库系统了。目前memcache_engine项目还是早期试验阶段，让我们期待memcache_engine项目早日发布正式版本吧！
顺便多说几句：最近一年来，特别是最近一个月以来，围绕memcached的开源项目发展的非常非常活跃：
1、最近刚刚发布了memcached的新的高性能C客户端接口: libmemcached
2、由于有了libmemcached，该组织又发布了memcache_engine存储引擎，cool！
3、由于libmemcached的发布，不到一周时间，ruby的两个崭新的memcache client就问世了，他们是Caffeine和New memcache-client，让ruby访问memcached的速度大幅度提高，请看：libmemcached发布了，ruby访问memcached提速20倍
4、memcachedb发布了，这是中国的互联网公司贡献的开源项目
以上几个项目都是在2008年1月发布的，真的不是一般的繁荣阿。再加上之前发布的新的支持异步访问的Java Memcached API和C#接口，可以说除了Python，其他主流非主流编程语言都可以使用memcached了。其实即便是Python还没有公布出来的开源接口，我们也知道国内的web2.0网站豆瓣就是使用Python访问memcached，并且支持了极大的访问量，因此目前围绕memcached的开源项目发展的情况非常的繁荣。
memcached最近两年这么受欢迎，其实和互联网web2.0的流行有很大的关系，web2.0网站通常需要个性化页面，依赖于页面局部和数据细颗粒度的缓存来提升性能，并且web2.0网站流量都很大，因此memcached这种高性能分布式缓存服务器就大行其道了。
当然我觉得最具有革命意义的还是memcache_engine和memcachedb这两个项目的发布，他们能够让memcached的用途不仅仅限于缓存服务器而已，而是能够真正充当分布式数据库来使用了，这无异是诸多大流量web2.0网站和开发人员的福音阿。
- 12:05
- 浏览 (16842)
- 论坛浏览 (7066)
- 评论 (17)
- 分类: Tech
- 相关推荐
评论
不过原来的双向八车道也缩水成了半边断路施工的101国道？
这个一个很正常的trade off，如果这点trade off都没有，那你让Oracle/DB2们还混什么混？
不过原来的双向八车道也缩水成了半边断路施工的101国道？
前面 robbin 提到的这个问题，在 memcache_engine 还不知道是怎么解决的。而且解决方案的性能还未知。
其实这到不难，MySQL有一个系统数据库叫做mysql，里面存放系统表，包含了MySQL数据库里面每个用户数据库里面的对象的meta信息，因此首先是把memcachedb映射到MySQL的相关表结构上。然后在具体的CRUD操作上面，MySQL会给每个数据库表创建索引，即便你没有创建用户索引，主键列也有索引，此外每条记录还有时间戳属性，这些信息都被保存到该表的索引列里面，具体来说会写在数据库的数据目录下面的索引文件。
当对memcachedb类型的表进行SQL查询的时候，首先是从系统表获取该表的meta信息，例如字段什么的，然后到索引里面去查找符合条件的记录，最后根据符合条件的记录的主键id去memcachedb里面get就行了。当然你会问，如果没有索引，导致全表扫描怎么办？ 那我想，对该表的全表扫描也无非是根据一堆主键id对memcached发送multiget操作而已，还是比传统的读数据库表，引起硬盘IO来得快很多。
用MySQL的好处在于，通过MySQL的系统数据字典和表索引，给memcachedb里面的数据“创建了一份清楚的地图”，有了这份地图在手，我们就不必对memcachedb盲人摸象了。
前面 robbin 提到的这个问题，在 memcache_engine 还不知道是怎么解决的。而且解决方案的性能还未知。
而且更糟糕的是mysql cluster和mysql replication是两个不同的概念，还混为一谈：
抠字眼有意思吗，我说的是mysql集群，mysql cluster和mysql replication都是他的实现，搞java编程的，抽象和具体就这么难分清楚？
memcachedb是用来解决特定应用场景的特定问题的，而不是用来和传统的关系数据库PK玩的，两者的应用场景是不同的，所要解决的问题也不一样，硬扯在一起说XX也可以替代XX，那就是辩论收的纯辩论技巧了，不是在讨论技术了。
memcachedb自然就是cache+db了，当然要和db+cache的方案pk。要拿特定应用场景说事，那就比较一下两种方案的优劣，memcachedb得最大缺点就是管的太多，就像ejb2，有重量级容器的坏味道。
memcachedb和mysql cluster又是两个应用于不同场景，解决不同问题的技术，你扯到一起来，硬要说mysql clustre可以替代memcachedb，他们还真没啥可比性，而且也无法替代，这个例子举得真糟糕，而且更糟糕的是mysql cluster和mysql replication是两个不同的概念，还混为一谈：
memcachedb是解决高性能读写问题的，比方说某些大型网站应用，每秒钟有超过1万次的写请求，10万次的读请求，那你就得用memcached来缓存数据了，这个时候你用mysql cluster或者mysql replication根本无济于事，，硬盘IO WAIT就把你所有的MySQL线程阻塞了，用memcachedb是为了能够解决数据库服务器的IO性能瓶颈的；
反过来说，某复杂的企业应用，每秒钟有超过3000次的SQL查询请求，这个时候memcachedb根本就用不上，因为memcachedb是不支持SQL查询的，那单台数据库服务器的CPU计算量也不足以支撑这么大的查询运算，所以replication或者cluster到n台计算器上面，去分担CPU负载，用mysql replication是为了能够解决数据库服务器的CPU性能瓶颈的。
一个是解决IO瓶颈的，一个是解决CPU瓶颈的，你怎么替代？
再说一遍，要比较的是cache+db而不是db，不要老是跑题，因此你写的这一大堆我就不一一回了。
集群有高可用和负载均衡等分类，难道这个还要讨论？
1.要和cache+db的方案比优势，而不是仅仅比较db。cache+db的好处在于分层逻辑清晰，cache是一层，db是一层，比方说，那天Berkeley DB不爽了，换mysql、postgresql都是可替代的选择，cache层更换也是一个道理。若要用楼主的方案，好了，没有cache层，绑死在数据库上了，你要换数据库，那cache层代码是不是还得新写。
memcachedb是用来解决特定应用场景的特定问题的，而不是用来和传统的关系数据库PK玩的，两者的应用场景是不同的，所要解决的问题也不一样，硬扯在一起说XX也可以替代XX，那就是辩论手的纯辩论技巧了。
2.关于分布式方案，要选择，拿mysql来说，我肯定会选择mysql官方提供的集群方案，而不是一些非专业数据库开发人士提供的所谓的透明的高效率的分布式方案，真要用起来，怎么死的都不清楚。
就拿楼上的例子来说，用memcache集群+mysql集群（主从复制）一样满足需求，不但系统扩展性好，用的也放心。
memcachedb和mysql cluster又是两个应用于不同场景，解决不同问题的技术，硬要说mysql cluster可以替代memcachedb，他们还真没啥可比性，而且也无法替代，这个例子举得真糟糕，而且更糟糕的是mysql cluster和mysql replication是两个不同的概念，还混为一谈：
memcachedb是解决高性能读写问题的，比方说某些大型网站应用，每秒钟有超过1万次的写请求，10万次的读请求，那你就得用memcached来缓存数据了，这个时候你用mysql cluster或者mysql replication根本无济于事，，硬盘IO WAIT就把你所有的MySQL线程阻塞了，用memcachedb是为了能够解决数据库服务器的IO性能瓶颈的；
反过来说，某复杂的企业应用，每秒钟有超过3000次的SQL查询请求，这个时候memcachedb根本就用不上，因为memcachedb是不支持SQL查询的，那单台数据库服务器的CPU计算量也不足以支撑这么大的查询运算，所以replication或者cluster到n台计算器上面，去分担CPU负载，用mysql replication是为了能够解决数据库服务器的CPU性能瓶颈的。
一个是解决IO瓶颈的，一个是解决CPU瓶颈的，你怎么替代？
好处有两点：
1、远远超过数据库的高性能
其实这是废话，如果数据库IO性能够好的话，这个世界上就不会有DB Cache这种东西。比方说新浪博客每天上亿的点击量，而博客这东西很难动态页面静态化，你不上Cache Server试试看？
2、分布式
你见过Oracle Grid可以轻松的分布式的吗？他底层的数据库文件还是要单点存储的，但是memcachedb天然就是分布式的，你可以把他分布到几十台上百台服务器上面去。这个优势对于上亿的大负载网站的好处根本不用多说什么废话。
1.要和cache+db的方案比优势，而不是仅仅比较db。cache+db的好处在于分层逻辑清晰，cache是一层，db是一层，比方说，那天Berkeley DB不爽了，换mysql、postgresql都是可替代的选择，cache层更换也是一个道理。若要用楼主的方案，好了，没有cache层，绑死在数据库上了，你要换数据库，那cache层代码是不是还得新写。
2.关于分布式方案，要选择，拿mysql来说，我肯定会选择mysql官方提供的集群方案，而不是一些非专业数据库开发人士提供的所谓的透明的高效率的分布式方案，真要用起来，怎么死的都不清楚。
就拿楼上的例子来说，用memcache集群+mysql集群（主从复制）一样满足需求，不但系统扩展性好，用的也放心。
好处有两点：
1、远远超过数据库的高性能
其实这是废话，如果数据库IO性能够好的话，这个世界上就不会有DB Cache这种东西。比方说新浪博客每天上亿的点击量，而博客这东西很难动态页面静态化，你不上Cache Server试试看？
2、分布式
你见过Oracle Grid可以轻松的分布式的吗？他底层的数据库文件还是要单点存储的，但是memcachedb天然就是分布式的，你可以把他分布到几十台上百台服务器上面去。这个优势对于上亿的大负载网站的好处根本不用多说什么废话。
建个内存盘(memdrive)，把MySQL设置成数据库文件存放到内存盘里。再写个脚本每隔一段时间把instance拷到硬盘上。完事
你写个脚本出来给我看看？ 不要说你把整个内存里面的instance热拷贝到硬盘上了，你就是把innodb里面的数据在线热备份出来，你都办不到！ 因为你必须考虑内存数据的同步问题。所以innobase的hotbackup工具才能卖1万多块钱。
再者memcachedb是分布式的，可以把n台物理服务器组成一个逻辑数据库，那你MySQL你怎么给我分布式到n台机器的内存里面去？ Oracle的Grid都办不到，不要说你可以办到。
Robbin出品，必属精品！
目前它们又有一个新的开源项目发布了