云计算背后的秘密（7）-YunTable的故事

作者 | 2011-01-05 21:06 | 类型 云计算 | 20条用户评论 »

Sina WeiboBaiduLinkedInQQGoogle+RedditEvernote分享




系列目录 云计算的秘密

  1. 云计算背后的秘密（1）-MapReduce
  2. 云计算背后的秘密（2）-GFS
  3. 云计算背后的秘密（3）-BigTable
  4. 云计算背后的秘密（4）-Chubby
  5. 云计算背后的秘密（5）-Google的数据中心优化技术
  6. 云计算背后的秘密（6）-NoSQL数据库的综述
  7. 云计算背后的秘密（7）-YunTable的故事
  8. 云计算背后的秘密（8）-RPC框架

 

在本系列之前的一篇文章，和大家提到过，其实业界已经出现很多NoSQL产品，那么我为什么在这些产品的基础上，研发新的NoSQL数据库呢？ 因为 在研发YunEngine的时候，我发现在业界还缺乏一款在架构上非常简洁，并同时可以适应各种云计算场景的NoSQL数据库，所以在那时我就开始进行YunTable的开发工作。YunTable的目标并不是做一个像BigTable那样大而全的数据库，而是主要做一个精简版的分布式Key-Value数据库，上层的云计算应用将会根据其自身的需求去利用YunTable或者做修改，从而使YunTable能适应云计算各种场景，并且非常易用。YunTable已经在10月初正式开源，并发布其0.8版，官方地址是http://code.google.com/p/yuntable/。下面将对YunTable进行分析和介绍，包括它的设计、架构和如何适应不同的云计算环境。

 

YunTable的设计

谈到一个NoSQL数据库的设计时，肯定离不开数据模型、分布式架构和数据存储这三方面。

在数据模型上，YunTable是Key-Value的，虽然Key-value这种数据模型在结构方面和传统的关系型相比较简单，有点类似常见的HashTable，一个Key对应一个Value，但是其能提供非常快的查询速度、大的数据存放量和高并发地操作，并非常适合通过主键（Key）来对数据进行查询和修改等操作，虽然不支持复杂的操作，但是可以通过上层的开发来弥补这个缺陷。

在分布式架构方面，YunTable选择了Single Master模式来管理整个集群，虽然这个模式存在单点失败的隐患，但是不论是在实现，还是在语义方面都非常简单，而且为了避免Master出现单点失败的情况，YunTable将会在今后版本中引入Shadow-Master这种机制。

在数据存储方面，YunTable选择了SSTable这种文件格式。简单而言，SSTable是一个用于存储已排序Key-Value对的文件格式，并且是不可变动的（Immutable），也就是写了之后，只能将其更新附加在其之后，而不能直接进行修改，这样是为了让系统能执行Disk所擅长的顺序访问，而不是随机访问。在内部格式方面，SSTable文件主要有Index和Data Block这两部分组成。在实际运行时，系统常会把Index载入内存，以确保查询的效率。

 

YunTable的架构

在架构方面，主要可分为Region、Master和Client这三个模块，而且这三个模块都是独立的，并负责各自的业务逻辑。

YunTable Arch

图1. YunTable的架构

首先，介绍一下Master节点，Master节点在功能上面属于比较“轻”调，主要负责维护Table和Region节点之间的对应关系，实际数据的查询和输入则都通过Region节点和Client端之间的交互完成，和Master节点无关，这样能有效地减轻Master节点的负担，使得其能支撑百台服务器以上的集群。举个例子，比如，当一个Client端需要处理某个Table的时候，它只需在第一次处理时候，向Master请求和这个Table相关的Region节点的地址，当之后再次处理到这个Table的时候，Client端无需再和Master节点进行沟通，而是直接和相关的Region节点进行交互即可。

其次，谈谈Region节点，其作用是负责处理来自Client端的请求，并存储和管理大量的数据，Region节点非常类似BigTable论文中所提到的Tablet服务器。每个Region服务器管理多个Tablet，每个Tablet对应一个Table，并负责存储属于这个Table的数据。除了管理多个Tablet之外，Region服务器还自带WAL日志，全称为“Write-Ahead Log”，主要用于暂存那些最新的数据更新请求，以避免当Tablet中的Memstore被意外关闭时所造成的数据丢失，而当Memstore完成对数据的写入之后，WAL也会清空那些对应的数据。用于存储数据的Tablet主要有两大部分组成：其一是Memstore：其是缓存在内存中的数据文件，主要存储最新添加的数据，当Memstore存储的数据接近限定值时，在Memstore上缓存的数据都将会被冲刷（Flush）到YFile中；其二是YFile，它是主要用于存储数据的持久化文件，它是基于上面提到的SSTable格式，YFile只会在当Memstore被触发冲刷时创建，平时常被顺序读，这样能有效地利用硬盘顺序读性能好的特性，文件的位置在其所属Tablet的目录中。

现在Client端主要以名为“YunCli”的命令行为主，主要用于让用户输入与数据处理相关的命令，并与后端的Master节点和Region节点进行交互，但随着时间的发展，在形式上，Client端有可能是类似JDBC的驱动等。

 

如何适应不同的云计算环境

云计算主要常见的有两类场景：需要低延迟和高并发的读写能力，数据量虽大，但称不上海量，估计最多在TB级别，大部分现在使用RDBMS的Web应用基本上都属于这一类，有点类似传统的OLTP（联机事务处理）；海量数据的存储和操作，比如PB级别的，这方面的例子有传统的数据仓库、Google海量的Web页面和图片存储等，有点类似传统的OLAP（联机分析处理）。

那么YunTable是如何适应这两种环境？首先，坚持Key-Value、Single-Master和SSTable这样经典和通用的设计。其次，在数据存储方面，加入Hotness这个机制，主要是通过设置Hotness值来决定之前为了完成查询而读取到内存中的Data Block的生存时间，假设如果是低延迟的情况，那么将Hotness值设置长一点，如果是海量数据，则相反。

 

最后，YunTable作为新一代的PaaS平台YunEngine的后端数据库已经投入实际运行中，而且即将发布其0.9版，在这个版本中，YunTable的单点性能和稳定性将会走上一个新的台阶。还有，下一篇将继续给大家关注NoSQL。

系列前一篇 系列下一篇
(2个打分， 平均：5.00 / 5)

工具箱
本文链接 | | 打印此页 | 20条用户评论 »

雁过留声

“云计算背后的秘密（7）-YunTable的故事”有20个回复

  1. 陈怀临 于 2011-01-05 9:08 下午

    IMHO，我感觉某个10万人的公司加起来都没有这个小吴懂云计算。。。唉，自古英雄出少年呀。未名湖畔孕育人才呀。。。佩服。

  2. 吴朱华 于 2011-01-05 10:34 下午

    呵呵，过奖了。但是年后，可以让他们团购由首席写推荐的《剖析云计算》一书:)

  3. 陈怀临 于 2011-01-05 10:38 下午

    愚兄我一定亲自做序，然后试图忽悠让几万人都来买你的书。。。

  4. 吴朱华 于 2011-01-05 10:40 下午

    呵呵，好的:)

  5. aaron.chen 于 2011-01-07 3:21 下午

    呵呵，完全同意首席对某10万人公司的评价。
    现在tektalk也被拦在墙外了，不讨论是是非非的自由也没有了。
    后悔当年没趁年轻无妻小时肉身翻墙啊。

  6. 冬瓜头 于 2011-01-11 1:09 上午

    翻墙出去，学一身本领然后再回来报效国家？但愿如此啊。

  7. jiangyou 于 2011-02-27 9:32 下午

    “我感觉某个10万人的公司加起来都没有这个小吴懂云计算。。。”
    IMO cloud computing is more about implementation (instead of the design). People tend to brag on the design just because it is easier and less boring but details are in the implementation. So did you ever read a single line of the source code of yuntable before making such a judgement?

    Yuntable is far from a mature project based on the total LoC, its usage of other libraries and the problem it claims to fix. You can have a look at memcached, redis, mongodb etc to see how others work.

  8. 吴朱华 于 2011-02-27 9:48 下午

    to jiangyou:
    Don’t underestimate the potential of YunTable, in next two month, YunTable gonna be so much better.

  9. jiangyou 于 2011-02-27 10:40 下午

    I didn’t mention the potential crap. And I don’t care.

    Software development is resource consuming and resources are always tightly limited. It is not about programming languages and tricks you learned from college classes. It is about making trade off all the time and tackling the non-ideal reality. Most of your time will be invested in supporting and error handling facilities (instead of features).

    Normally you need to envision how large your codebase will grow, plan how long you will get there (aka the roadmap) and decide how to allocate your limited resources (do things you are good at and leave the rest to others, e.g., library/framework usage).

    Yuntable is reinventing wheels, like memory usage/tracking, logging, basic data structure, RPC protocol, and honestly the code is just average if not below.

    Pardon me but have you ever read others’ code and participated in any serious software development?

    Unless what you are doing are just PR craps.

  10. 吴朱华 于 2011-02-28 12:32 上午

    Since You and I are different person,I don’t want to continue the conversion with you, We see the results in the future.

  11. Tech and I 于 2011-02-28 1:45 上午

    Believe me, he’s different with anyone.

  12. 理客 于 2011-02-28 2:11 上午

    Yuntable is not matured now, but I believe Mr. Wu’s substance of both personalities and capabilities

  13. 吴朱华 于 2011-02-28 2:16 上午

    to 理客:
    Thank you for your support. Now We are working 1.0 version, which is more stable.

  14. 瞎扯 于 2011-02-28 8:42 下午

    代码风格确实可以再整整，两个tab的缩进很少见。最长列限制是有道理的，如果你真的做过大项目的话。

    小团队没功夫弄文档可以用doxygen. 一点建议。

  15. 吴朱华 于 2011-02-28 9:22 下午

    呵呵，0.9版只是用于Demo的，1.0版代码风格将会更专业，关于两个tab的缩进和最长列限制的问题，我会和我的团队沟通一下，决定什么样最合适。关于doxygen，让我学习一下。

  16. 刘扬 于 2011-03-06 9:21 下午

    我觉得这个架构master node不是必须的，关键是找个好的hash算法。

  17. 吴朱华 于 2011-03-06 9:35 下午

    To 刘扬：
    谢谢关注，希望能稍微展开:)

  18. 刘扬 于 2011-03-06 11:25 下午

    memcached有个consistent hash,用它可以省略master上的look up table，楼主觉得可行么?

  19. 吴朱华 于 2011-03-07 12:27 上午

    呵呵，这个想法我们团队曾经想过的，觉得是一个不错，但比较有局限性的设计。

  20. yuhoo 于 2012-03-10 1:45 上午

    这个不就是BigTable的架构么，名字更都是山寨Hbase的