memcache_engine + memcachedb = 高性能分布式内存数据库

1.要和cache+db的方案比优势，而不是仅仅比较db。cache+db的好处在于分层逻辑清晰，cache是一层，db是一层，比方说，那天Berkeley DB不爽了，换mysql、postgresql都是可替代的选择，cache层更换也是一个道理。若要用楼主的方案，好了，没有cache层，绑死在数据库上了，你要换数据库，那cache层代码是不是还得新写。

2.关于分布式方案，要选择，拿mysql来说，我肯定会选择mysql官方提供的集群方案，而不是一些非专业数据库开发人士提供的所谓的透明的高效率的分布式方案，真要用起来，怎么死的都不清楚。

就拿楼上的例子来说，用memcache集群+mysql集群（主从复制）一样满足需求，不但系统扩展性好，用的也放心。

memcachedb是用来解决特定应用场景的特定问题的，而不是用来和传统的关系数据库PK玩的，两者的应用场景是不同的，所要解决的问题也不一样，硬扯在一起说XX也可以替代XX，那就是辩论手的纯辩论技巧了。



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瓶颈的，你怎么替代？

memcachedb自然就是cache+db了，当然要和db+cache的方案pk。要拿特定应用场景说事，那就比较一下两种方案的优劣，memcachedb得最大缺点就是管的太多，就像ejb2，有重量级容器的坏味道。
再说一遍，要比较的是cache+db而不是db，不要老是跑题，因此你写的这一大堆我就不一一回了。

集群有高可用和负载均衡等分类，难道这个还要讨论？

抠字眼有意思吗，我说的是mysql集群，mysql cluster和mysql replication都是他的实现，搞java编程的，抽象和具体就这么难分清楚？

现在的问题是 memcache_engine 还未有具体的数据出来。
前面 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盲人摸象了。

不过原来的双向八车道也缩水成了半边断路施工的101国道？

这个一个很正常的trade off，如果这点trade off都没有，那你让Oracle/DB2们还混什么混？