loadinghttp://blog.sina.com.cn/mpl398235717
―dbcached 的 Memcached 部分‖查询自身的内存缓存未命中，则―dbcached 持久化存储管理器‖会通过―NMDB 客户端接口‖从 QDBM 或 Berkeley DB 数据库中取出数据，返回给用户，然后储存到 Memcached 内存中。如果有用户再次请求这个 key，则会直接从 Memcached 内存中返回 Value 值。
● 持久：使用 dbcached，不用担心 Memcached 服务器死机、重启而导致数据丢失。
● 变更：使用 dbcached，即使因为故障转移，添加、减少 Memcached 服务器节点而破坏了―key 信息‖与对应―Memcached 服务器‖的映射关系也不怕。
● 分布：dbcached 和 NMDB 既可以安装在同一台服务器上，也可以安装在不同的服务器上，多台 dbcached 服务器可以对应一台 NMDB 服务器。 ● 特长：dbcached 对于―读‖大于―写‖的应用尤其适用。
● 其他：《dbcached 的故障转移支持、设计方向以及与 Memcachedb 的不同之处》
列存系列
Hadoop之Hbase
Hadoop / HBase: API: Java / any writer, Protocol: any write call, Query Method: MapReduce Java / any exec, Replication: HDFS Replication, Written in: Java, Concurrency: ?, Misc: Links: 3 Books [1, 2, 3]
耶鲁大学之HadoopDB
http://blog.sina.com.cn/mpl398235717
http://blog.sina.com.cn/mpl398235717
GreenPlum
FaceBook之Cassandra
Cassandra: API: many Thrift ? languages, Protocol: ?, Query Method: MapReduce, Replicaton: , Written in: Java, Concurrency: eventually
consistent , Misc: like \ initiated by Facebook, Slides ? , Clients ?
Cassandra是facebook开源出来的一个版本，可以认为是BigTable的一个开源版本，目前twitter和digg.com在使用。
Cassandra特点
? 灵活的schema，不需要象数据库一样预先设计schema，增加或者删除字段非常方便（on the fly）。
? 支持range查询：可以对Key进行范围查询。
? 高可用，可扩展：单点故障不影响集群服务，可线性扩展。
Cassandra的主要特点就是它不是一个数据库，而是由一堆数据库节点共同构成的一个分布式网络服务，对Cassandra的一个写操作，会 被复制到其他节点上去，对Cassandra的读操作，也会被路由到某个节点上面去读取。对于一个Cassandra群集来说，扩展性能是比较简单的事 情，只管在群集里面添加节点就可以了。我看到有文章说Facebook的Cassandra群集有超过100台服务器构成的数据库群集。
Cassandra也支持比较丰富的数据结构和功能强大的查询语言，和MongoDB比较类似，查询功能比MongoDB稍弱一些，twitter的平台架构部门领导Evan Weaver写了一篇文章介绍
http://blog.sina.com.cn/mpl398235717
http://blog.sina.com.cn/mpl398235717
Cassandra：http://blog.evanweaver.com/articles/2009/07/06/up-and-running-with-cassandra/，有非常详细的介绍。
Cassandra以单个节点来衡量，其节点的并发读写性能不是特别好，有文章说评测下来
Cassandra每秒大约不到1万次读写请求，我也看 到一些对这个问题进行质疑的评论，但是评价Cassandra单个节点的性能是没有意义的，真实的分布式数据库访问系统必然是n多个节点构成的系统，其并 发性能取决于整个系统的节点数量，路由效率，而不仅仅是单节点的并发负载能力。 Keyspace
Cassandra中的最大组织单元，里面包含了一系列Column family，Keyspace一般是应用程序的名称。你可以把它理解为Oracle里面的一个schema，包含了一系列的对象。 Column family（CF）
CF是某个特定Key的数据集合，每个CF物理上被存放在单独的文件中。从概念上看，CF有点象数据库中的Table. Key
数据必须通过Key来访问，Cassandra允许范围查询，例如：start => '10050', :finish => '10070' Column
在Cassandra中字段是最小的数据单元，column和value构成一个对，比如：
name:―jacky‖，column是name，value是jacky，每个column:value后都有一个时间戳：timestamp。
和数据库不同的是，Cassandra的一行中可以有任意多个column，而且每行的column可以是不同的。从数据库设计的角度，你可以理解 为表上有两个字段，第一个是Key，第二个是长文本类型，用来存放很多的column。这也是为什么说Cassandra具备非常灵活schema的原 因。 Super column
Super column是一种特殊的column，里面可以存放任意多个普通的column。而且一个CF中同样可以有任意多个Super column，一个CF只能定义使用Column或者Super column，不能混用。下面是Super column的一个例子，homeAddress这个Super column有三个字段：分别是street，city和zip： homeAddress: {street: \\
Sorting
不同于数据库可以通过Order by定义排序规则，Cassandra取出的数据顺序是总是一定的，数据保存时已经按照定义的规则存放，所以取出来的顺序已经确定了，这是一个巨大的性能优势。有意思的是，Cassandra按照column name而不是column value来进行排序，它 定义了以下几种选项：BytesType, UTF8Type, LexicalUUIDType, TimeUUIDType, AsciiType, 和
http://blog.sina.com.cn/mpl398235717
http://blog.sina.com.cn/mpl398235717
LongType，用来定义如何按照column name来排序。实际上，就是把column name识别成为不同的类型，以此来达到灵活排序的目的。UTF8Type是把column name转换为UTF8编码来进行排序，LongType转换成为64位long型，TimeUUIDType是按照基于时间的UUID来排序。例如：
Column name按照LongType排序： {name: 3, value: \
{name: 123, value: \{name: 976, value: \{name: 832416, value: \
Column name按照UTF8Type排序： {name: 123, value: \{name: 3, value: \
{name: 832416, value: \{name: 976, value: \
下面我们看twitter的Schema： 我们看到一个叫Twitter的keyspace，包含若干个CF，其中StatusRelationships和 UserRelationships被定义为包含Super column的CF，CompareWith定义了column的排序规则，CompareSubcolumnsWith定义了subcolumn的排序 规则，这里使用了两种：TimeUUIDType和UTF8Type。我们没有看到任何有关column的定义，这意味着column是可以灵活变更的。 为了方便大家理解，我会尝试着用关系型数据库的建模方法去描述Twitter的Schema，但千万不要误认为这就是Cassandra的数据模型，对于Cassandra来说，每一行的colunn都可以是任意的，而不是象数据库一样需要在建表时就创建好。 http://blog.sina.com.cn/mpl398235717