高性能数据库HyperTable(转载)

数据库领域近来吸引了不少眼球。IBM不久前投资于EnerpriseDB；EnerpriseDB有一个运行在Amazon EC2上的云版本。Amazon去年末发布了他们自己的云数据库。而Google的BigTable尽管并不开源，也得到了社区的广泛研究。同样是在这个 领域，两个开源项目——HBase和Hypertable利用开源Map/Reduce平台Hadoop提供了类似于BigTable的可伸缩数据库实 现。InfoQ与Zvents, Inc的理论研究架构师以及Hypertable项目的创立者Doug Judd一起讨论其实现。

1、你如何向第一次听说Hypertable的人形容这个数据库？

Hypertable是一个开源、高性能、可伸缩的数据库，它采用与Google的Bigtable相似的模型。在过去数年中，Google为在PC集 群上运行的可伸缩计算基础设施设计建造了三个关键部分。第一个关键的基础设施是Google File System（GFS），这是一个高可用的文件系统，提供了一个全局的命名空间。它通过跨机器（和跨机架）的文件数据复制来达到高可用性，并因此免受传统 文件存储系统无法避免的许多失败的影响，比如电源、内存和网络端口等失败。第二个基础设施是名为Map-Reduce的计算框架，它与GFS紧密协作，帮 助处理收集到的海量数据。第三个基础设施是Bigtable，它是传统数据库的替代。Bigtable让你可以通过一些主键来组织海量数据，并实现高效的 查询。Hypertable是Bigtable的一个开源实现，并且根据我们的想法进行了一些改进。

如果你运行一个高流量的网 站，那么就应该关心可伸缩的计算基础设施。网站服务器的日志包含了与用户行为相关的有价值的信息。你可以分析这些日志数据，并根据分析的结果提供更好的服 务。它让你可以回答这样一些问题：“如果客户购买产品X，他们还可能购买什么？”，“如果用户到达页面Y，那么在他们关闭会话之前平均会进行多少次点 击？”

2、为什么Hypertable团队要开始这样一个项目？

Zvents的工程团队启动这个项目是 因为我们认识到数据以及数据驱动工程的价值。我们认识到在高伸缩的条件下，传统的存储和信息处理工具力不从心。在我们启动项目的时候，还不存在 Bigtable的开源实现，于是我们决定自己来建造那么一个数据库。我们选择开源的理由是我们觉得注定会出现一个Bigtable的开源实现。通过领导 这方面的开发工作，我们可以在知识、专业技能和可靠性等方面促进竞争。

3、为什么Hypertable需要Hadoop才能运行？

不，Hypertable并不一定要Hadoop才能运行。Hypertable被设计成可以运行在现有的文件系统之上，比如Hadoop和HDFS。 面向底层文件系统的接口已经通过一种代理（broker）机制进行了抽象。Hypertable通过标准的协议与一个DFS代理交谈，从而实现与底层文件 系统的通信。我们使用的主要DSF代理是针对HDFS的代理，但我们也有针对KFS（Kosmos File System）的代理。还有一个“本地代理（local brocker）”只读写本地挂接的文件系统。“本地代理”是我们用来测试的，但同样可以用来在任何可通过FUSE挂接的分布式文件系统上运行 Hypertable。至于Hadoop的其余部分，我们打算写一个InputFormat类，让Hypertable中的表可被用作map- reduce任务的输入。

4、Hypertable相比HBase有何差异？为什么不直接贡献到HBase而要另起炉灶呢？

Hypertable与HBase的差别是，Hypertable是Bigtable的一个更高性能的实现（InfoQ同样采访了HBase的团队）。 我开始的时候跟Jim Kellerman以及Hadoop团队的一些成员一起为HBase工作。但我们对HBase应该变成什么样子有不同意见，对实现语言的选择也有不同意 见。他们坚持用Java，而我力推C++。于是我就分出来，开始了Hypertable项目。

下面的文档名为《为何选择C++而不选择Java》，里面解释了选用C++的技术原因。

http://code.google.com/p/hypertable/wiki/WhyWeChoseCppOverJava

虽然我们很早就与HBase项目分开，但两个团队仍然是很好的朋友。实际上我们上星期就一起出去吃午饭，同时还分享了很多实现中的情况和想法。

5、按照我对Hadoop的粗浅理解，M/R范型很适合用来完成数据的批处理。那么Hadoop用在比较突出事务/单次请求的范型中又如何呢？

Map-Reduce绝对是一个离线批处理系统。它很适合离线执行海量信息（如日志）的排序及筛选。这种大规模的离线计算经常会产生大量的信息供服务参 考，以提供更好的用户体验。信息可能包括对每个用户的描述数据，又或者对每次请求的统计信息。这就是Hypertable发挥作用的地方，它提供了一种可 伸缩的解决方案来存储经过主键索引的数据，并且可以在线查询。

6、你在使用Hadoop的过程中觉得哪一方面是最好的？

简而言之Hadoop运作得很好。我们在Zvents已经成功应用了Hadoop，还有很多公司在离线作业中使用Hadoop。Hadoop团队也在下面的新闻稿中描述了他们的成就：

http://developer.yahoo.com/blogs/hadoop/2008/02/yahoo-worlds-largest-production-hadoop.html

7、最坏的方面呢？

我觉得Hadoop最坏的方面是这个项目已经存在了几年都还没有一个稳定的1.0版。有时候很难找到一个稳定的版本。不过最近Hadoop项目已经稳定 了很多。Hadoop还有一个问题，在它的分布式文件系统中缺乏对“sync”操作的支持，因此不适合用来保存提交日志。他们已经在积极解决这个问题，在 我们发布Hypertable 1.0版的时候应该就会实现了。

8、1.0版预计在什么时候发布？

我们会在一两个月之内发布一个Beta版，紧接着就是1.0版。如果想随时了解Beta版和1.0版的情况，请加入Hypertable的公告邮件列表：http://groups.google.com/group/hypertable-announce

9、有什么公司在用Hypertable？

因为Hypertable还处在alpha阶段，所以还没有公司用Hypertable来构建服务。不过很多人都对Hypertable感兴趣，我们已 经有超过3000次下载。很多人也通过邮件列表给了我们很好的建议。比如Omaha, Nebraska一家企业有个人向我们报告了一个回归错误。经过邮件列表上的一番往来，他干脆把机器放到公司防火墙的外面，然后给了我一个VNC帐号去调 试这个问题。我最后终于找到了问题，程序在PST之外的时区运行时会发生时间戳的转换错误。还有一个来自纽约的Stony Brook大学的博士生，他用Hypertable重新完成了Google的Bigtable基准测试，而且得到了很好的结果。像这样的社区回馈给了项目 极大的帮助。上周我们给Facebook的30来位工程师做了Hypertable的演讲。他们感觉确实需要在后端工具链中加入这种类型的基础设施，并决 定在Hypertable接近完成的时候试用一两个月。我们很期待看到Hypertable发布1.0版的时候能出现一些真正的应用。

10、Hypertable有何未来目标？

短期来说，我们把精力放在高可用性上，尤其是服务器恢复。完成之后经过测试，项目就会进入到Beta阶段，紧接着就是1.0版。我们希望 Hypertable能在很多Web Service应用中取代MySQL。我们希望把LAMP这个缩写变成LAHP，显然H指的是Hypertable。这需要坚如磐石的可靠性和持续不断的 性能提升才能达到。这个目标应该能让团队忙好一阵子了。

hypertable 在table中存储数据，数据通过主键排序. cell中的数据没有类型,所有的数据都存储为字节串. 通过把table分段到集群来进行scaling.hypertable中有两种类型的server: Range Server用于存储数据段, Master Server负责任务管理和Range Server定位. 同一台机器上可以同时运行Range Server和Master Server程序. 一个Range Server上可能保存着不连续的range, Master Server负责智能的定位和管理数据, farming. 如果一个range被填满了, 此range会被切分并重新分配.前半部分range仍保留原位, 后半部分range被master指派到一个新的Range Server.默认情况下,最大的range尺寸为200MB. 如果整个Range Server填满了, Master把部分ranges迁移到其它server. range列表和它们的路径信息被存放在一个METADATA 表中, 同时也作为Hypertable中的一个普通表. 第三个元素: Hyperspace, 包含一个指向root METADATA表range的指针，负责给client充当路由. Hyperspace同时也提供了一个类似于文件系统的名字空间, 并为clients充当一个锁管理器的角色. Hypertable的Schemas非常灵活, 仅仅需要定义列族(column family):CREATE TABLE Items { tag, review, price}; 数据以名值对(key:value)的方式存储. 数据的所有版本都被存放在Hypertable中, 所以时间戳会作为key的一部分.针对单个cell的key典型格式为<row><column- family><column-qualifier><timestamp>. timestamps在查询时通常作为范围来传递, 所以在此范围内的值被返回. 这种方式方便老版本数据的查阅, 并确保所有数据的先前状态都被保存而非覆盖. 当然，你还可以指定固定保留的版本数量. 允许老数据被延迟进行垃圾收集. 随机更新的效率很高，这归咎于Cell Cache和Cell Store. 一个Range实际上由许多Cell Store组成. 在同一个cell store中保存的所有行按照行标识排序. 在向Hypertable执行写操作时, 信息被写入到DFS上的一个commit log中, 之后被存储在Cell Cache中. 当Cell Cache达到尺寸上限时会被压缩并作为一个cell store写入磁盘。Cell store不是连续的, 所以一个Heap Merge scanner负责合成cell cache和cell store中的key/value对并有序地返回.当range达到cell store的上限时, 会执行一个heap merge并把多个cell store压缩为一个. 在极端情况下，每个Range最终只有唯一一个Cell Store. Hypertable让用户可以控制数据如何使用Access Group机制在DFS上进行物理存储.每个column family属于一个单个Access Group. 同一个Access Group中所有column families的数据在物理上是一起存储的。这对于读写频繁的column families来说具有更好的性能.比如，一个table中存在100个column families, 但是只有2个column families被频繁访问. 如果这两列被存储在同一个access group中, 系统仅仅需要针对这两个column families进行磁盘I/O

Hypertable

Doug Judd (Zvents, Inc.)

hypertable.org

Background




hypertable.org

Scaling Mount Web 2.0 with Hypertable

    * Directly Created Content
          o Web pages
          o Blog posts
          o User reviews
    * Indirectly Created Content (user
          o Following someone on Twitter
          o Adding a friend on Facebook
          o Rating a review
    * Behavioural Data (server logs)







MySQL Doesn’t Work at Scale

    * Designed for a single machine
    * What it takes to make it scale
          o Major engineering effort
          o Solutions are usually ad hoc
          o Solutions usually involve horizontal partitioning + replication





hypertable.org

Google Solved the Problem

    * Google Stack
          o Google File System (GFS)
          o Map-reduce
          o Bigtable
    * Inherently scalable
    * Inherently cost effective





hypertable.org

Bigtable

    * Massively scalable
    * Most of Google’s major services are built on top of it
          o Crawl Database
          o Google Analytics
          o gmail
          o AdSense
          o Google Maps
          o YouTUBE
          o Blogger
          o Orkut





hypertable.org

Architectural Overview




hypertable.org

What is Hypertable?

    * A high performance, scalable database
    * Modelled after Google's Bigtable
    * Open source
    * Not a relational database







Hypertable Improvements Over MySQL

    * Scalability
    * High random insert, update, and delete rate





hypertable.org

Data Model

    * Sparse, multi(4)-dimensional table of information
    * Cells are identified by a 4-part key
          o Row
          o Column Family
          o Column Qualifier
          o Timestamp





hypertable.org

Table: Visual Representation




hypertable.org

Table: Actual Representation




hypertable.org

Anatomy of a Key

    * Row key is /0 terminated
    * Column Family is represented with 1 byte
    * Column qualifier is /0 terminated
    * Timestamp is stored big-endian ones-compliment







Concurrency

    * Bigtable uses copy-on-write
    * Hypertable uses a form of MVCC
      (multi-version concurrency control)
          o Deletes are carried out by inserting “delete” records







CellStore

    * Sequence of 65K blocks of compressed key/value pairs







System Overview




hypertable.org

Hyperspace

    * Chubby equivalent
          o Distributed Lock Manager
          o Filesystem for storing small amounts of metadata
          o Highly available
    * “Root of distributed data structures”





hypertable.org

Range Server

    * Manages ranges of table data
    * Caches updates in memory (CellCache)
    * Periodically spills cached updates to disk (CellStore





hypertable.org

Master

    * Single Master (hot standbys)
    * Directs meta operations
          o CREATE TABLE
          o DROP TABLE
          o ALTER TABLE
    * Handles recovery of RangeServer
    * Manages RangeServer Load Balancing
    * Client data does not move through Master







Client API

class Client {

void create_table(const String &name,

                    const String &schema);

Table *open_table(const String &name);

String get_schema(const String &name);

void get_tables(vector<String> &tables);

void drop_table(const String &name,

                  bool if_exists);

};




hypertable.org

Client API (cont.)

class Table {

TableMutator *create_mutator();

TableScanner *create_scanner(ScanSpec &scan_spec);

};

class TableMutator {

void set(KeySpec &key, const void *value, int value_len);

void set_delete(KeySpec &key);

void flush();

};

class TableScanner {

bool next(CellT &cell);

};




hypertable.org

Compression

    * Cell Stores store compressed blocks of key/value pairs
    * Commit Log stores compressed blocks of updates
    * Supported Compression Schemes
          o zlib (--best and --fast)
          o lzo
          o quicklz
          o bmz
          o none





hypertable.org

Caching

    * Block Cache
          o Caches CellStore blocks
          o Blocks are cached uncompressed
    * Query Cache
          o Caches query results
          o TBD
    * Bloom filter
          o Probabalistic data structure
          o Negative cache
          o Indicates if a key is not present





hypertable.org

Scaling (part I)




hypertable.org

Scaling (part II)




hypertable.org

Scaling (part III)




hypertable.org

Access Groups

    * Provides control of physical data layout -- hybrid row/column oriented
    * Improves performance by minimizing I/O
      
      CREATE TABLE crawldb {
        Title MAX_VERSIONS=3,
        Content MAX_VERSIONS=3,
        PageRank MAX_VERSIONS=10,
        ClickRank MAX_VERSIONS=10,
        ACCESS GROUP default (Title, Content),
        ACCESS GROUP ranking (PageRank, ClickRank)
      };





hypertable.org

Filesystem Broker Architecture

    * Hypertable can run on top of any distributed filesystem (e.g. Hadoop, KFS, etc.)





hypertable.org

Performance Test
(AOL Query Logs)

    * 75,274,825 inserted cells
    * 8 node cluster
          o 1 1.8 GHz Dual-core Opteron
          o 4 GB RAM
          o 3 x 7200 RPM SATA drives
    * Average row key: 7 bytes
    * Average value: 15 bytes
    * 500K random inserts/s
    * 680K scanned cells/s





hypertable.org

Weaknesses

    * Range data managed by a single range server
          o Though no data loss, can cause periods of unavailability
          o Can be mitigated with client-side cache or memcached







License

    * GPL 2.0
    * Why not Apache?



Before this infrastructure, many homegrown systems …


Genesis crawl database

…


Spend some time


Spend some time.


Row-oriented

Column-oriented