HBaseの開発者がHadoop、BigTable、分散データベースについて語る

作者 Scott Delap, 翻訳者 白石 俊平 投稿日 2008年5月30日 午後6時12分

コミュニティ

Java

トピック

データアクセス,

クラウドコンピューティング,

データベース設計

タグ

Hadoop,

Google

Google が最近リリースしたGoogle Application Engineと、それが持つBigTableへのアクセス機能により、（RDBの）代替となるデータベース技術への感心が新たに盛り上がっている。数週間前にInfoQは、GoogleのBigTableデータベースから着想を得て始められた、Hypertableプロジェクトの創始者であるDoug Juddにインタビュー(source)を行った。今週InfoQは、HBase(サイト・英語)の主要な開発者であるJim Kellerman 、Michael Stack、Bryan Duxburyへのインタビューを行った。HBaseはオープンソースで分散型、列指向のデータストアで、BigTableを手本として作成された物である。

1. HBaseについて初めて聞く、と言う方に対しての説明をお願いします。

HBase はオープンソースで分散型、列指向のデータストアで、Chang氏その他によるGoogleの論文「Bigtable: 構造化データのための分散ストレージシステム」(source)に倣って作られました。ちょうどBigtableが、Googleファイルシステムによって提供される分散データストレージを活用しているように、HBaseはBigtableライクな機能をHadoop(source)の上で提供しています。HBaseはApacheにおいて、Hadoopのサブプロジェクトです。

HBaseプロジェクトは年次のオラクルのライセンス代が小国のGNPに達するくらいかかっていたり、MySQLを、ほんのすこし、もしくは数百万行もあるテーブルのためにインストールするような人向けのものです。山ほどの体系化された、もしくは少し体系化されたデータがあったり、もしくは持っているRDBMS上限がわからないような時、HBaseを使ってみてください。これをよりよくするには、是非ともプロジェクトに参加してください。我々は、低いレベルのゴールを設定するつもりはありません。近いうちにユーザ、サポータ、その他貢献者の支援によって、超巨大なテーブルにバージョン管理されたセル、そして何億もの列、何百万ものコラムが、コモディティ化された、クラスタ化されたサーバの中に格納されるでしょう。

2. なぜこのプロジェクトを始めたのですか？

Jim とStackが働いているPowerset社が、そのwebtable - 幅広いWebドキュメントのテーブルで、その属性はURLをキーとする - を保持するために、Bigtableライクなデータストアを必要としていました。RapleafはBryanの雇い主ですが、プロフィールデータの巨大なテーブルや、その他の種類のデータを管理するためにBigtableライクなストレージシステムが必要なことが明らかになったとき、プロジェクトに加わりました。

3. Hypertableと比べると、どうですか？

明らかに、どちらのプロジェクトもほぼ同じ問題を解決しようとしています - オープンソースのBigtableです。HBaseはJavaで書かれていますが、HypertableはC++です。オープンな開発が行われてきた期間と、コミッタや外部のコントリビュータの数と言う点では、HBaseが一歩先んじています。

Javaを選択したおかげで、 Hypertableよりも緊密なHadoopとの統合が可能です - HDFSを使うときに、JavaとC++の間の仲介者として他のプロセスをスタートする必要はありませんし、JNIを使って"大きな溝"を埋める必要もありません。またJavaを使用したおかげで助かったのは、我々のコアタイプと機能の一部は既に出来上がっていたことです。それらはHadoop Coreプロジェクト上で、"スマートな"ソースブランチを作ろうと言う活発なコミュニティによって、既に書かれてデバッグされていました。

Hypertable プロジェクトは"パフォーマンス"の一点にフォーカスしており、C++のみがそれを達成できると強く思っています。興味深いことに、私たちの知るところではHadoopの開発のほとんどがC++を仕事で使っているYahooのチームによって行われていること、そしてHypertableの言い分とほとんど同じ理由で、JavaのMapReduceフレームワークに二の足を踏んでいたとのことでした。これによってわかることは、Hadoopチームは特定の関心事を克服したということです; Javaがパフォーマンスやその他の点で劣っているところでは、彼らは適切な改善と進歩を実現したのです。例えばHadoop/HBaseは、圧縮についてはJavaのパフォーマンスが貧弱なため、ネイティブライブラリを使用しています。

HBase は、パフォーマンス周りで多くの作業が必要なのは確かです -- 先に述べたコアタイプ、そしてRPCトランスポートはHBaseの利用パターンに最も適した形に書き直す必要があります -- しかし現在は、私たちのフォーカスは別のところにあります。私たちは、Hadoopプロジェクトと同じように、まずは堅牢性、スケーリング、正確さ、そしてコミュニティの構築に集中しようとしています。その後で、私たちは全てのスピードアップを行うつもりです。その時が来たら、あらゆる人を Hypertable対HBaseのドラッグレースにご招待しますよ。

スポーツライクなライバル関係として、Hypertableの人たちは私たちのパートナーです。私たちはかなり定期的に話し合いを持っていますし、概してお互いを助け合っています。

4. Google App EngineがBigTableを公開したのに関してはどう思いますか？

Google がAmazonを追随したと言う点では、非常に興味深く見ています。とりわけGoogleのシステムは、HadoopとAmazonの両方が従事している全てのコンセプトの"参照"実装だからと言うのがその理由です。しかし、App Engineが発表されてから多くの人が注意しているように、あなたのインフラを所有することと、それを借りることの間には大きな違いがあります。恐らく、あなたの（会社、サービスの）規模が非常に小さい場合は（インフラを借りることが）良いことですが、びっくりするほどすぐに、あなた自身がそれを主有する方が良くなるでしょう。

同様に、ロックインされると言う問題も存在します: 自身のハードウェアを持つことが経済的に意味があるとしても、App Engineは一度は人気を博します。ですが、App Engineからあなたのアプリケーションを移動しようとしてみてください。あなたの手元には、システムを構築する部品が全てそろってはいないのです。多くの場合、これはLAMPの利点から後退しているように見えます。

つまり、Google App EngineのDataStore APIをHBaseで実装したり、GQLをパースしたり、と言った寄与を我々は拒みはしない、と言うことです。

5. MapReduceのパラダイムは、データのバッチ処理に適しています。トランザクション/単一リクエストを基にしたパラダイムに、Hadoopを適合させるにはどうしたらよいのでしょうか？

MapReduce(GoogleとHadoopの両方) は、伝統的なデータベースでは扱えないような、巨大な量のデータ処理に理想的です。トランザクション/単一リクエスト処理には適していません。一方、 HBaseはHadoop CoreのHDFSを利用していますが、一般的な操作に対してMapReduceを使用していません。

HBase は効果的なランダムアクセスをサポートしており、あなたのビジネスに置けるトランザクショナルな要素に利用できます。MySQLのようなすばらしいパフォーマンスを得られるだけではなく、トランザクションのスループットが大きくなるに従って、規模の利点を得ることもできます。HBase はIBM研究所の人たちからすばらしい寄与を受けていますので、HBaseをMapReduceのソースとディスティネーションに使うことも簡単です。そのため、MapReduceによるバッチ処理の一部としてHBaseベースのデータを用いることも可能です。まさに一挙両得です。

6. Hadoopと作業をともにすることで、一番良かったことはなんですか？

Hadoop のサブプロジェクトになることで、ツインターボが搭載されたようなものです。最もありがたかったのは、Hadoopのコア開発者にアクセスできるようになったことです。またHadoopコミュニティの一部になったことで、ユーザがHBaseに引きつけられます。Hadoopで既に行われていた膨大な作業を活用することができます - HBaseの多くの部分は、Hadoopから再利用したものです。また、非常に大きな利益をもたらす、Hadoopコミュニティからのインプットとレビューにさらされてもいます。

二番目にありがたいことは、Apacheの一部となったことです。Apacheは開発済みのプロセスとインフラを多く持っているので、私たちはそれを活用できます。自身で開発する必要はありません。

7. 悪かったことは？

私たちはいい点しか見ていませんよ(笑い)。何か言わなければならないとすると・・・

Hadoop では多くの場合、HDFSとMapReduceは一緒に開発されています。そのため、私たちがHDFSを利用している方法との違いを理解してくれるような、コア開発者を見つけるのが難しいことが時々あります。例えば、通常MapReduceはランダムな読み取りは行いませんが、HBaseにとっては必須です。

あと、HDFSにはappend操作が欠けています(HADOOP-1700を見てください)。それなしでは、HBaseはサーバがクラッシュしたときにデータを失ってしまいます。この機能はHadoop 0.18.0で追加されるようです。

8. HBaseを使用しているのはどんな企業でしょう？

一番最初に使い始めたのはPowersetとRapleafです。私たちが知っている企業では、HBaseを活発に用いて、かなり大きなデータセットを扱っているのは、WorldLingoとWikiaですね。その他の企業の多くは、HBaseを使う最初のステップを踏み出そうとしているところです。もし HBaseのご利用に興味をお持ちの方がいらっしゃいましたら、我々に教えてください！

9. HBaseの将来はどうなりますか?

近い将来では、私たちは0.1ブランチを安定させようとしています。0.1.2を来週かそこらにリリースするでしょう。私たちは、ユーザベースとコントリビュータを開拓する上で、安定こそが鍵であると考えています。また、次の重要なリリースは5月にリリースされるバージョン0.2です。堅牢性の大きな向上、リージョンの再バランスのような、クラスタの自己管理機能における多くの向上、改善されたクライアントAPIなどを見ることができるでしょう。

原文はこちらです：http://www.infoq.com/news/2008/04/hbase-interview

• 次へ >