HBaseコミッター達による、NoSQLの記事への反論が面白かったので翻訳してみました。
著者の許諾取得済み。Thanks Stack and the other authors!
本文
原題: Taking the Bait
Information Weekは先日、「HBase はNoSQL を支配するのか?」という記事を掲載した。MapR の Michael Hausenblas は HBase の事例に「賛成」の論陣を張っており、Apache Cassandra の Jonathan Ellis とベンダーである DataStax は「反対」の側だった。
この「ディベート」をベンダーのセールストークとして却下し、Apache HBase に立ち戻り、HBase を使用し、改善していくのは、簡単な話である。しかし、この記事は特別に問題のある例だった。記事では、「賛成」と「反対」の双方とも、HBase コミュニティの仕事にはほんの少ししか言及していない。ここでは誤りを訂正する目的で、いくつかの点に言及したい。
まず、Michael は、Hadoop が急速に成長しており、そして、HBase は Hadoop から出てきたのであり、緊密に結びついているのであるから、HBase は上向きの上向きだ、と論じていた。HBase コミュニティの積極的な参加者でなければ、このような仮定を立てるのは容易である (HBase によって Hadoop の採用を推進されているところでは、その逆に出くわすことにもなる)。
Michael は次に、古い一貫性対 eventual-consistency の戦いに話を焼き直し、飽き飽きする HBase 対 Cassandra の機能比較に切り替えた。そして、最後には、Cassandra の源泉である Facebook がデータ保存のために、大きなサイズのいくつかのアプリの代わりに HBase を使用することにしたというだけの理由で、HBase の方が良い、と結論づけた。我々はその種の論争などしない。Apache HBase か Apache Cassandra を活用すべきであるかどうかは、多くの要因によるのであり、多くの規模の問題と同様に攻撃的な言い争いに巻き込まれすぎているといえる。
その次に Michael は、「我々は企業向けの HBase の「次のバージョン」を作り上げた・・・。我々は2013年5月に M7 のラベルの下でその新しいバージョンをGAにもたらした」と語り、おとり商法を行った。この引用での「我々」というのは、Apache HBase コミュニティのことを述べているのではなく、Michael の雇用主であるMapR Technologies のことを指している。また、Michael が言及する「企業向けの HBase」というのは Apache HBase のことではない。M7 というのは、我々が知る限り、構造上 Apache HBase とは根本的に異なっている、プロプライエタリの製品である。その製品はソースが明らかにされていないのであり、我々はこれ以上は言及できない。この話は、Apache HBase コミュニティが長年にわたり、ハードワークと、Apache HBase 以外の商業的なクローズドソースの製品への寄与を通じて築き上げてきた信用と善意をいただいてしまおうとする試みと見えた。
次は、Jonathan の「反対」の論に言及してみたい。Jonathan の主張のいくつかは今はもう真実ではないか、大いに主観的である。真実でないというのは、「RegionServer のフェイルオーバーは10分ないし15分かかる」という箇所である (HDFS-3703 および HDFS-3912 を見てほしい)。主観的であるというのは、「HBase をもとに開発を行うのは苦痛だ」という箇所である (我々の意見では、我々のクライアントAPIは、一般的に使用されているCassandra クライアントライブラリよりも簡単で使いやすい)。これら以外のものについては、どれもメーリングリストから Quora に至るフォーラムで何年にもわたり論議・再論議してきたものばかりだった。Jonathan の論は大部分は、我々が Apache Hadoop の HDFS ファイルシステムと緊密に結びついていることと、 Google BigTable アーキテクチャの輪郭をなぞっていることから来るものを、列挙しているだけである。HBase は HDFS の多くの機能を利用し、BigTable からは着想を得ている。その結果として、Cassandra にとっては問題となるユースケースのいくつかを、我々は得意としている。逆もまた真である。我々のユーザーが使用するハードウェアは進化するのであり、あるいは、新たなユーザーが新しいユースケースをもとにした経験をもたらすのであり、我々も HDFS もじっとその場に立ち止まったままではいない。
彼は、アプローチの違いを強調している。
我々は協調させるために、Apache HDFS の採用、Apache Hadoop MapReduce の統合、および、Apache ZooKeeper の使用を選んだことを、健全な関心の分離と見なしている。HBase は歴戦のコンポーネントで構築されている。これは特徴であり、バグではない。
Jonathan が組み込まれたクエリ言語やセカンダリインデックス機能をコア Cassandra に必要な複雑化と見なすのに対し、我々は、Salesforce の Phoenix のようなプロジェクトを、Apache HBase を中心とするより大きなエコシステムの一部である見なし、支援する。Phoenix の人たちは問題のその部分にドメインの専門知識をもたらすことができるが、我々 (HBase) は、安定したパフォーマンスの高いストレージエンジンコアを提供することに焦点を当てることができる。Apache Hadoop をここまで成功させてきたものの一部は、プロジェクトを支援し豊かにするそのエコシステム、HBase を含むエコシステム、である。そのようなエコシステムが、HBase の周囲で発展してきた。
Jonathan が、HBase コミュニティのことを「リーダーシップ」が分散されているために「断片化」されていると評する方向へとそれていくのに対し、我々は、そこで言及されているのはたぶん、Apache HBase プロジェクトは「所有」されたプロジェクト、つまりたった1人のベンダーに導かれたプロジェクト、ではないという事実であるのだろうと考えている。むしろそれは、多くの組織、ほんの数例をあげれば、Cloudera、Hortonworks、Salesforce、Facebook、Yahoo、Intel、Twitter、および Taobao ということになるが、それらの多くの組織からの多くのチームがみな協力してそのプロジェクトを推進していこうとしている、そのようなプロジェクトなのである。Apache HBase コミュニティのほとんどは、2つのブランチでの共同作業に参加している。ブランチの1つは新規の0.96のリリースに関するものであり、もう1つは現在の安定したリリースである0.94に関するものである。Facebook もまた、共有されているソース管理リポジトリにおいて、Facebook 独自の Apache HBase のブランチをもっている。このブランチはインスピレーションの源泉になっており、ときに他のブランチへの直接的な寄与となっている。我々のコミュニティのニーズと要望に応じた便利で効率的な協力モデルを発見したことについて、我々は謝罪するつもりなどない。たった1人のベンダーに導かれた他のプロジェクトにとっては、このことは完全に最適化されていないか、場合によっては混沌 (「断片化」) とすら見えることだろう。
我々はこれはそのまま残しておく。
いつもと同じように、我々は、我々のコミュニティと Apache HBase プロジェクトへのあなたの参加と寄与を歓迎する。我々には、偉大な製品と、特定の商業体への恩義がなく、エゴのない、摩擦の少ない意思決定プロセスとがある。もしあなたがかかなければならない痒みがあって、Apache HBase が解決策ではないかと思うのなら、あるいは、あなたが Apache HBase を使用していて、もっといい改善案があるはずだと感じるのなら、我々のところにやってきて、大いに話をしましょう。
