现在的位置: 首页 > 综合 > 正文

YunTable开发日记2 – 前三天的总结

2013年10月09日 ⁄ 综合 ⁄ 共 1730字 ⁄ 字号 评论关闭

 

本文是《YunTable开发日记》的第二篇。 

 

本来想周二写这篇开发日记,可惜一直抽不出时间,所以延到了周四。在这篇日记中,会首先做一下前三天的开发总结,接着会解答博友的一些疑问。

 

前三天的开发总结

虽然在前三天花了很多时间在其它方面,比如写一些关于云计算的约稿等,但是基本完成了之前的计划,也就是实现了接口层和编译层,下面是YunTable一个非常简陋的截屏:

YunTable01 图1. YunTable的截屏

接下来,对已经涉及两层进行详述:

YunTable Arch

图2. YunTable v0.01架构图

接口层

在接口层这块,HBase的接口是以Shell和API形式为主,但我觉得Web接口在易用性方面更出色,所以我在接口层选用了Linux Socket技术来开放YunTable的存储和查询能力。

 

编译层

这层大家疑问很多,有的同学觉得这层看起来有点多余,其实为了在初期提供友好的用户体验,准备支持最基本的SQL语句,也就是CRUD,所以编译层主要是为了解析用户从接口层输入的SQL语句,并将它们转译为相应的对数据模型的修改。

 

除了项目之外,更重要的是,通过这几天的C语言实践,我个人已经基本上掌握了C语言,特别是比较难缠的字符串处理部分,总的来说,C语言比Java灵活很多,在使用Java的时候,除了在编写多线程相关代码的时候,其它时刻大都能做到心中有数,而C语言呢,如果没有深厚的底层知识和丰富的经验,是很难做到随心所欲的。估计,我在C语言方面的下两个挑战会是对内存的管理和与汇编的整合。

 

 

解答博友的一些疑问

这几天收到几位博友关于YunTable的一些问题,下面是对这些问题的回复,希望大家能满意。

 

为什么开发YunTable?

之前有一位博友向我提到既然在市面上已经出现了HBase和Hypertable这样的BigTable克隆,为什么我还要去开发?首先,第一个原因当然是因为接下来准备进行内核层的开发,所以想先选择一个基于用户层的应用来练手。其次,无论哪个行业,只有掌握最核心资源和技术才能处于最强势的地位和获取最高的利润,在云计算行业,什么是最核心的技术呢?我认为主要有两个:其一是虚拟机,相关的技术有开源的Xen和VMware的ESX,其二是分布式数据库,相关的技术有Google的BigTable,Apache的HBase和Facebook的Cassandra等,而且这两个技术在难度上也是最大的。虽然这两种技术都有开源版本,但是如果我们能掌握其核心的实现方法,这样不仅能使我们有机会开始出在性能和用户体验这两方面更优越的版本,而且同时也能按照不同的业务需求来做相应的优化。最后,就是我希望能通过YunTable这个项目结识一批具有实干精神的程序员。

 

为什么要写开发日记?

首先,当然是为了提升博客的人气,因为通过开发日记形式不仅能通过步步深入的方式将一个非常难懂的概念讲清,比如本系列将提供到的BigTable的数据模型和存储方式,还能通过开放整个实际的开发流程来帮助那些缺少产品开发经验的同学来理解一个在技术上有难度的产品是如何从无到有构建起来的。其次,希望以博客形式代替传统的开发文档,也省了我相应的文本工作。最后,我在考虑是不是将本系列作为工程实践部分加入到《剖析云计算》一书中。

 

会不会开源,怎么参加?

这个问题也是很多博友非常关注的,身为一名普通的开发人员,我也非常推崇开源这种形式,所以这个项目初期将会以Apache License的形式发布,我个人觉得GPL有点偏激,所以不是特别推崇,而Apache License总体而言,是比较温和的。关于参加这个项目,我对这些同学是非常欣赏的,也是非常欢迎的,而且能与这些同学共事也是我开发YunTable的初衷之一,但是因为在现在这个阶段项目不论是从代码质量还是在功能上面离最简单的原型还差的很远,所以我个人准备等到项目达到其0.1版的时候发布在Google Code,之后希望大家能在这个0.1版的基础上一起讨论这个项目的未来,并参与其中,这样才能做到“有的放矢”。

 

 

接下来的几天会对首先试着实现数据模型层的原型,同时也会对HBase的数据存储层进行研究,来探究如何实现对BigTable数据的持久,之后会以本系列博客的形式发布给大家的。

抱歉!评论已关闭.