2010/07/29

BIGDATAは中国から

先日、Hibariのオープンソースについて、米国でプレスリリースをし、そのアクセス数からインターネット=英語がBig Dataを作り出すのではないだろうか?、とお伝えしました。しかし、プレスリリースから2日経って、HibariのダウンロードサイトであるSourceforgeのStatisticsを見て驚きました。わずか1日の間にダウンロード数で中国がトップになりました。米国、日本が続きますが、圧倒的な差です。


おそらく、発表から1日経って、英語版のプレスリリースが中国語に翻訳され流れたのでしょう。10億人を超える人口と急激な経済成長。すでにBIGDATAという課題に日々直面しているのかもしれません。そして、Hibari(雲雀)という名前や、日本の品質基準をクリアし商用化されている技術だという点も注目を集めたのかもしれません。Hadoopのダウンロード数は、米国に次いで日本が第2位であると聞いたのは、わずか数カ月前ですが、Hibariのケースは異なりました。

先のブログでは、日本と米国でのHibariのプレスリリースから類推しアクセス数の差は3倍以上だろうとお伝えしましたが、日本と中国と間の差はもっと大きいようです。BIGDATAの技術という領域でも、あっという間に中国が存在感を示すことになるのでしょうか。

2010/07/28

Open Source Release of Hibari, A Database for Big Data

このブログでご紹介しているHibariのオープンソースについてプレスリリースを行いました。実は、このプレスリリースは日本と米国で別々に2回に亘り実施しました。日本は、7月14日のワイヤレスジャパン2010でHibariのオープンソース化を発表し、同時にプレスリリースを行いました。米国では、7月27日に行いました。

通常、このようなプレスリリースは日米同時に行うのかもしれません。しかし、2つの理由から、2回に分けて行いました。ひとつめの理由は単純です。米国でのプレスリリースを日本と同時に行うための負荷がかなり高くなり、無理をしなかったということです。多くのシリコンバレーのベンチャー企業は、広報をアウトソースしていますが、そのコストもセーブすることにしました。

もうひとつの理由ですが、日本と英語圏での反応の違いを見てみたかったということです。とはいえ、その違いをはかる客観的な基準はありませんので、今回はプレスリリースに対するGoogle Searchの検索結果数、TwitterのTweet数、Hibariのダウンロードサイトへのアクセス数を比べてみました。

その結果は、人口分布の差からも明らかですが、いずれも3倍以上の差がありました。Hibariのようなプレスリリースでさえ、こうなのですから、インターネットと英語の組み合わせは、日本語の情報に比べ、簡単にBig Dataになると実感しました。

また、Tweetからも面白い発見がありました。英語圏での発表の際のTweetに、「もうひとつのKVS」というような表現が多く見られたとことです。つまり、Hibariのような分散型でBig Dataを処理する技術は、すでにずいぶんと浸透している、ということなのだろうと思います。

Hibariは、すでに中国、日本での商用実績がありますが、このような状況を見ていると、気がつけば、あっという間に、世界のあちらこちらで利用されているということになるのかもしれません。


プレスリリースのリンクはこちらです。

2010/07/24

Google's Big Table


Key Value Store、NoSQL、Non-Relational DBなどとさまざまな呼ばれ方をするBig Dataを処理する技術や製品は、このブログでご紹介をしているHibari、Hadoop/HBase、Cassandra以外にも、数多くあります。この主にKeyとValueというシンプルなデータモデルにより分散型処理をする技術が、特に最近、脚光を浴びています。

しかし、そもそも分散処理という概念や技術は長い歴史があり、特別新しいというものではありません。MITでコンピュータサイエンスを学んだ同僚が言うには、仮に分散処理派と集中処理派があるとすれば、しばらくはマシーン1台あたりの処理能力が飛躍的に高まったことで、集中処理派の時代が続いたそうです。しかし、インターネットの普及が分散処理派のプレゼンスを高めたといいます。

なかでもGoogleの貢献が大きく、特に、Googleが2006年に発表した論文、「Google's Big Table」に触発され、Hadoopを始めとする多くのキー・バリューやNoSQLと呼ばれる技術開発が活発になりました。

このブログにリンクしていますが"nosql summer reading"というコミュニティがあります。これは、このGoogleのBig Tableを始めとする様々なNoSQLの論文を関心ある仲間が集まって読むという読書会です。これは、プレゼンをしたり、一人が説明するという会ではなく、お互いに論文を読み、わからない点や面白いと思う点を話し合うといった形式で進めます。つい先日、東京でも第1回目を開催いたしました。プロから見ても、論文だけでは、どうやって作られているのかわからない謎がたくさんあったようです。利用した資料をスライドシェアにアップロードしています。

http://www.slideshare.net/geminimobile/bigtable-4820829


Summary of "Google's Big Table" at nosql summer reading in Tokyo

Check out this SlideShare Presentation:

2010/07/07

BIGDATAを処理する技術の性能比較をしてみると (YCSBの場合)

BIGDATAを処理する技術の性能比較の方法については、未だ統一された方法や基準はありません。Geminiは、これまで数回に亘り、試行錯誤しながら性能比較をしています。以前のブログで、ご紹介した方法は、100万リクエストの書き込みと読み込みをランダムとシークエンシャル(連続)で行い、バリューのサイズが1KB、10KB、20KBの場合のスループット(MB/秒/ノード)として性能比較をしてみました。

それ以前には、5万リクエストで200KBや400KBのバリューを用いた性能比較も行っています。いずれも、大きなバリューに優れるHibariの性能の高さが際立つ結果となりました。

しかし、これではHibariが最適化される設定で性能比較をしているように思われてしまうかもしれません。そう考えていたところ、2010年5月、Yahoo! Researchから”"Benchmarking Cloud Serving Systems with YCSB"というレポートが公開されました。このレポートは、いま話題を集めているBIGDATAを処理するHBASE、Cassandraに加え、Yahooで開発のPNUTSなどの性能比較をする方法を提案し、その結果をレポートしています。このレポートでは、次のように各システムの特徴を整理しています。



そして、その性能比較で利用したデータを生成するツールをオープンソースとして提供しています。このレポートにおけるテスト方法はGeminiで実施したテスト方法と異なります。1,000byteのレコードをWorkload (operation/秒)により測定しています。そして、その際に書き込みと読み込みを一定の確率で発生させています。

ただし、いずれのシステムもその開発者が最適にチューニングを行ったうえでテストをしたと報告しています。残念ながら、そのチューニングの詳細はわかりません。そのため、同じ結果を再現できるのか、Geminiにおいても、このツールを利用して再度、性能比較を行う準備をしています。その結果については、あらためてお知らせしたいと考えています。

2010/07/06

BIGDATAを処理する技術はどう使われているのか (Hibariの場合)


ここではHibariがどのように利用されているのかをご紹介したいと思います。

Hibariは、Geminiのシリコンバレー、San MateoのR&Dチームの「ブラウンバック・セッション」(茶色の袋に入ったランチを持ち寄るブレインストーミング)で、そのアイデアについて議論したことに始まります。

これは2005年のことです。その時点では、Hadoop/HBASEを始め、多くのNO-SQL関連の技術が触発されたと言われるGoogleの「Big Table」という論文は公開されていませんでした。そのため、Geminiは、このアイデアについて独自で研究しながら、開発に着手しました。

Geminiは国内外の大手携帯通信事業者のメッセージングシステムにおいて、それ以前にも、SQLとは異なる独自データベースを開発しており、Hibariは次世代のデータベースと位置付けられました。

そして、開発に数年を要したのち、携帯電話向けの3D(3次元)のSNSサービスにおいて、ユーザーのメッセージボックスやパーソナルボックスにデジタルグッズ(アバター、音楽、写真、動画など)をストレージするデータベースとして利用し、商用化しました。このサービスは現在、中国で提供されています。

その後、数百万人の利用者が想定され、各利用者に数GBのメールボックスを提供するWebメールサービスの開発においてHibariと同じ技術が採用されました。これは、数百万人に数GBという、まさにBIGDATAを処理できるという技術面の利点と同時に、Webメールの一般的なビジネスモデルとして求められる経済性が重視された結果です。

このWebメールにおいては、主に次の目的に使うデータベースとしてHibariの技術は利用されています。

  • メールのアーカイブとサマリー
  • アドレスブックのアーカイブとサマリー
  • メールのプロファイル
  • ユーザーのプロファイル
  • フィルターのプロファイル

このようにプロファイルやサマリーといった小さなデータから、画像やファイル添付のあるメールのアーカイブのような大きなデータに至る、多様なサイズのデータのストレージのために利用されることから、Hibariは幅広いデータサイズにおいて安定的な性能を発揮するよう開発されています。さらに、メールというアプリケーションであることから、読み込みと、データの一貫性という点で優れています。


その一方で、Geminiのラボテストによれば、数KBという小さなデータサイズを速く処理するという点においては、HBASEとCassandraが勝ります。

つまり、ノン・リレーショナル・データベースのそれぞれに特徴があり、利用するアプリケーションやその目的に応じて最適な技術を選ぶことが重要になるのでしょう。