<第一周>key-value数据库集群的发现与思考（兼锻炼坚持能力）

1. 目标是找到一种如下的key-value数据库集群方案：
- 具备高性能的读写，支持亿级PV
- 具备灵活的可扩展性，同时也是支持上一条的基础
- 数据自动切分，即不依赖于业务逻辑
- 具备分布式事务功能以及不同隔离级别
- 具备数据的一致性或局部一致，最终全部一致
- 可独立提供网络层服务，以支持N（数据库集群）*M（WEB集群）结构，并支持二进制的网络协议
- 方便的客户端API

2. 我最初的思路
- 使用Memcachedb，由客户端API（改造spymemcached）实现分布式事务和隔离
- 由客户端API使用Consistent Hashing进行数据切分

3. 关于自己思路的发现
- 读写性能不错
- 不具备良好的可扩展性，由于Consistent Hashing，由于负载过高需要增加一倍的节点时，数据转移量是巨大的（5星级问题）
- 数据可以自动切分
- 分布式事务和隔离的实现只交由客户端API非常困难（5星级问题）
- 一致性满足
- 有独立的网络层服务，可以实现N*M架构，但不支持二进制协议（2星级问题）
- 客户端API相对方便，如spymemcached

4. 继续发现
由于自己是初学者，在这方面没有太多的经验，无法想出一个解决方案。于是我首先做的是去找其他已有的框架，并做粗浅的了解。
根据"菜鸟"和Robbin以及Google的提示，做了下大概的了解，除了上述提到的Memcachedb外，还包括：
- Cassandra，看看它能否解决我3中出现的三个问题，通过了解发现，它的扩展性是很好的，但没有分布式事务处理。
- Voldemort，面临跟Cassandra一样的问题，所以也让人纠结。
- Redis，主张以内存为主的存储，感觉用于生产会有问题。同时也不能解决分布式事务。
- JBossCache，提供了BDB Loader，但没有独立的网络层，需要与APP SERVER（如JBoss等）配合提供服务，有锁机制，由于配置复杂，也因为下面的Scalaris，我没有做进一步的了解。
- Scalaris，让我激动的框架，因为它支持分布式事务和隔离级别，并且以TC作为底层存储，目前正在研究它的扩展性和使用。由于不懂Erlang，这个过程比较费劲，但我仿佛看到一点光亮……

由于是这方面的初学者，加上基础不足，有些见解可能是错误的或不足的，敬请各位大侠指正，谢谢！

Tokyo Tyrant + Tokyo cabinet 应该可以满足你说的大部分要求，另外按我的理解对于键值数据库，你不应该在事物上对其有过多的要求，不知道对不对呵呵。

如果你对事物要求很高，同时还对扩展性要求很高，现在这种东西是有的，但是一般都是些大型的东西，例如亚马逊的dynamo, 一般的key-value数据库，除了这些富贵型的东西，现在没有多少哦可以解决事物，可用性都并存的问题。

根据我的了解，现在的key-value数据库在一致性性方面没有很好的表现，开发者大都需要自己去实现eventually consistency才能达到好的使用 （可以去做分布式事务等方法）， 关于这方面亚马逊的那篇论文还是很有指导意义的。

Key-value数据库发展很快（NOSQL解决方案）， 但是NOSQL的解决方案都很好的解决了可用性（availability）， 并且建议如果要对事物要求很高的话，不要使用。

Memcachedb虽然已经开始商用（Digg貌似在用），但是用法也是很单一，它仅仅适用于小数据量，高访问量的数据。

嗯～～感谢回复，我刚看了一下Tangosol（现在叫Coherence），按它的说明看来非常适合我的需求和目标，由于暂时不能下载试用，不知道它的持久化存储是怎么实现的。另一个比较郁闷的是它不是开源的了……

哦，Coherence没有提供独立的网络层，有与WebLogic集成的例子。

BTW：我开始怀疑我的理解了，Cache还是Cache Server的问题……Cache Server意味着我可以N*M，而Cache将是M*M，有人告诉我吗？

如果用 JAVA 的话， H2 挺不错的： http://www.h2database.com

1.重写client hash分布算法
当增加节点时可以进行两次hash从而增加节点
原:A-B-C
加过节点一次hash:A-虚B-C
加过节点二次hash:A-B-B1-C
可以减少数据迁移

2.你需要一个路由软件.

Bigtable/HBase/Hypertable could meet your requirements, except they are column based with version control, heavier than simple key-value caused some overhead.

While Tokyo Tyrant/Tokyo Cabinet or MemcacheDB is more agile, but missing distribution functions.

So my idea is:
1. B tree instead of hashing should be used to keep keys ordered for sharding.
2. Key-value store node is be able to splite it self when data grows. Node should write logs in case if fails, data could be rebuild on other nodes.
3. Using the same master/slave architecture as Bigtable uses to manage key shards and shard server assignment. And also a meta0 and meta1 indexes for key shards. I think this task could be even abstracted as a standard open source project.

That's it.