YunTable开发日记（9） 0.2版的预览和今后的初步规划（转载）

最近两周除了写博客之外，还花了一定的时间在YunTable上，并且已经快接近YunTable的下一个Milestone，也就是0.2版。在整个开发过程中，我收到了来自很多朋友的热心关切，我在这向大家表示衷心感谢，同时让我感到更欣慰的是已经有多位有实力的同学和我沟通过了，希望将来有机会能参与YunTable的开发，而且还有几位博友也对我提出了一些批评和建议，那么在介绍0.2版的目标和今后的规划之前，为了方便今后和大家的沟通，我先介绍我的一些理念：

1.  
   1. 对于一个技术上不是很成熟的项目而言，一个接近完美的设计是可遇，而不可求的，但是坚持简单易懂的设计和精简优雅的代码风格总是一个不错的选择。
   2. 关于开源项目，虽然协作非常重要，但是初始者一定要为后来者准备基本稳定的代码和功能，让大家在一个非常强健的基础上一起协作，而不是仅将那些后来者作为免费测试员。
   3. 暴雪老总Mike Morhaime在谈到他们成功的原因时，他有这样的一个10%的理论，就是需要在游戏发布前的润色阶段上花许多时间，这个反复的润色阶段也是使暴雪的游戏与众不同的原因之一，Mike Morhaime在谈到这点时称，最后10%的润色阶段，实际上就是一个好游戏和一个差游戏之间的差别，从YunTable的角度而言，就是在所有被承诺的功能都是可用的情况下，要进一步对YunTable进行润色，来提升可用性和稳定性。

接下来将给大家介绍一下0.2版的预览和一些规划。

 

0.2版的目标和今后的初步规划

总体而言，YunTable 0.2版的目标是实现BigTable 80%的基本功能，并在分布式的环境下测试，下面是YunTable今后的初步规划，希望大家能提点意见：

在日期方面：

版本号	目标	预计完成时间
0.01版	实践一些BigTable的理念	2010-7-5（已完成）
0.1版	完成50%的BigTable功能，并完成基本的测试	2010-7-12（已完成）
0.2版	实现BigTable 80%的基本功能，并在分布式的环境下测试	2010-8-13
0.8版	实现BigTable所有的基本功能，并完成相应的测试	2010-10-1
1.0版	主要完成对0.8版的长时间的试运行和相应的bugfix	2010-12-1

表1. 在日期方面的初步规划

在功能特性方面：

特性	介绍	引入的版本
Key和Value的格式	可以是任意字节数组	0.1
Column Family	通过Column Family来对数据进行分类管理	0.1
支持SSTable的格式	让数据文件一次写入，之后不可更改，来为I/O做优化	0.1
Block Index	在SSTable文件的尾部加入相关的Index，以提升查询速度	0.1
Memstore	就是让比较新的数据放置在内存中以加快查询速度	0.1
Write Ahead Log	每个Region节点会有一个Write Ahead Log来记录数据修改的信息	0.1
CRUD命令	支持基本的数据修改和查询的命令	0.2
管理命令	支持命令行来管理Master和Region	0.2
轻量级Master	让Master所承受的负担尽量最小化，以让其支撑更大的集群	0.2
备份	通过将数据进行多次备份，来避免数据丢失的情况	0.2
Bloom Filter	用于让系统快速确定这个Region是否存有所需的值	0.2
Row排序	主要支持按照字典顺序（lexicographic order）对Row排序	0.2
Fault-tolerant	要确保当某个Region节点失效时，client也能很好地处理数据	0.2
批处理	能批量向YunTable插入大量的数据	0.8
压缩	通过压缩数据，来提升速度	0.8
客户端驱动	比如，Java驱动	0.8
Master standby	Master有一个standby节点，来应对Master失效的情况	0.8
模块化	使得YunTable整体更模块化，来轻松应对新功能的添加	0.8
访问安全	增强YunTable的安全性	0.8

表2. 在功能特性方面的初步规划

整个项目将在0.2版正式推出的时候正式在Google Code上开源，到时我会邀请几位已经联系好的同学一起研究今后的分工和明确将来的规划，如果你也对YunTable这个项目非常感兴趣的话，可以在留言或者发信至ikewu83@gmail.com。

新架构

为了让YunTable更适合一个分布式的环境，在架构上和0.1版相比，做了很多的调整，主要是三个方面：其一是支持分布式；其二是Master的作用；其三是代码分割。

支持分布式

与0.1版的伪分布式不同的是，0.2版已经支持完整的分布式，也就是将Master和Region进行分离，虽然这样做的结果是，有可能会加大用户在使用方面的难度，只要用过这类分布式软件的人都应该能体会到这点，但经过接下来的开发，应该能想出两全其美之策。

Master的作用

在Master的作用上，0.2版已经引入BigTable中轻Master的理念，也就是0.2版中的Master已经不负责在Region和Client之间对请求和数据进行分发，而只负责维护Table和Region服务器之间的对应关系，实际数据的查询和输入则都通过Region和Client之间的交互完成，和Master无关，这样能减轻Master的负担，使得其能支撑百台服务器以上的集群。举个例子，比如，当一个客户端需要处理某个table的时候，它只需在第一次处理时候，向Master请求和这个Table相关的Region服务器的地址，之后在处理这个Table数据的时候，Client无需再和Master节点进行沟通，而是直接和相关的Region服务器进行交互。

代码分割

就像上面所说的那样，由于整个YunTable的topology已经有了很大的改动，所以为了适应这个分布式的新架构，所以在代码结构方面做了很大的改动，已经从过去的铁板一块改为现在Region、Master和Client三块，这三块代码都主要负责各自的业务逻辑，而且它们也同时依赖Utils代码，Utils主要包含通信，字符处理和文件处理等基础代码，下面是最新的YunTable代码的结构图。

图1. 最新的YunTable代码的结构图

预览版代码

在这里提供预览版代码的下载，以供各位YunTable的爱好者尝鲜，但需要提醒的是由于预览版代码还处于开发和调试当中，所以代码还存在很多Bug，也只能跑比较简单的一些Testcase。