長年の混乱に終止符, MongoDBのオーナー企業10genが社名をMongoDBに変更

NoSQLデータベースMongoDBの開発とサポートを行っている10genが、社名を製品名と同じMongoDBに変えた。同社によると、その目的は、オープンソースのデータベースプロジェクトと、それを支える会社とを、一体とするためである。新社名は、ただちに有効となる。

MongoDBは知名度の高いドキュメントベースのデータベースで、2007年に10genの傘下でローンチした。10genそのものは、オープンソースのクラウドのためのプラットホーム、という構想でスタートした企業だ。しかしその後同社はMongoDBをメインのプロダクトにすることに決め、実質的にデータベース企業になった。今回の社名変更に関して会長で協同ファウンダのDwight Merrimanは、社名と主製品名の統一がその目的、と語った。

MongoDBプロジェクトとそのコミュニティWebサイトmongodb.orgは、社名の変更の影響を受けない。10genのWebサイトは10gen.comからmongodb.comに変わった。

それは、もちろん良いことだ。10genという名前は、これまでひたすら、混乱を招いていた。改名は、MongoDBにとってというより、会社にもたらす今後のブランド効果が大きいだろう。

なおこのところ、企業経営がますますデータドリブン(data driven, データ駆動型)になるに伴い、NoSQL運動が飛躍的に成長している。関係データベースの支配は今も続いているが、それはクライアント/サーバの時代に設計されたものであり、数テラバイトものデータを処理するには適していない。膨大な量のデータ処理は、いまや例外ではなく企業ITの定番になりつつある。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


データの高速化について現場最先端の6社が語る

このごろは、何ごとに関してもスピードが重視される。つまり、今でも、ネットワークからデータをかき集めるよりもFedExで送ってもらった方が速いことがある。データを飛行機で運んだ方が速いという、うそみたいな事実が、今でも実際にあるのだ。

数テラバイトのデータを転送するだけなら、丸一日とか一晩かかることはない。でもフィーチャーフィルムの収まった複数のハードディスクを単純に“大陸間移動”することと、正しいデータを取り出し、それを分析し、何かのアプリケーションでプレゼンすることは、状況や抱える問題がまるで違う。スマートフォンの爆発的普及や、言葉の違いなどの障壁、3Dプリンタ、データオブジェクトの限りない多様化と集積、などなど、現代は、データ移動と言っても後者のような複雑な処理ニーズを伴うものが、圧倒的に多くなっている。

このようなデータ移動の複雑性に対応するために多くのアプリケーションは、RAMやフラッシュメモリの有効利用に傾いている。ハードディスクは、もはや古いのだ。ハードディスクの機械的な部品は、現代の企業が分析するデータの量や速度に対応できない。データベースも、完全なメモリ常駐型など、新しいものが登場している。スタートアップだけでなくSAPのような伝統的なIT企業も、それらの開発に取り組んでいる。そしてNoSQLデータベースが、今ではデベロッパたちのコミュニティでは人気者になっている。

しかしアプリケーションのパフォーマンスやデータ分析のスピードを左右する要素は、非常に多面的だ。最近FirstMark Capitalの常勤パートナーになったMatt Turckは、先週ニューヨークの同社のオフィスで行ったインタビューで、物のインターネット(Internet of Things, IoT)がデータ転送の総量を爆発的に増大させる、と言った。彼はそのとき、その兆候としてMQTTの登場を挙げた。この、IoTのための通信プロトコルは、The New York Timesによると、“マシンツーマシン通信のための共通語であるだけでなく、データ交換のためのメッセンジャーでありキャリアだ”。

MQTTの作者は、ワイト島にある16世紀に作られた彼の藁葺き小屋をIoTで自動化しようとしているときに、メッセージングのプロトコルが必要だと気づいた。

物といえば、子どもが床に転がして遊ぶ、あのボールなどを連想するが、しかしTurckによれば、それはボールのような無表情なデータ片ではなく、それ自身の社会的な(かけがえのない、他と同じでない)自己同一性を持ち、いずれは何兆ものほかのオブジェクトと接続することになるデータオブジェクトだ。子どもが壁にぶつけてあそぶSpaldeen〔≒スーパーボール、ビックリボール〕のようなものではなく、それは何かのアバターにもなるデータオブジェクトだ。でも、このボールなどさまざまなオブジェクトから渡されるすべてのデータを、全世界規模で想像すると、それが簡単にゼタバイト級のディメンションになってしまうことが、理解できるだろう*。〔*: したがって通信方式はどうしてもメッセージング(==非同期)方式になる。〕

今では、何ものにも増して重要な話題かつ課題と思われる、IoTなどを契機とするデータ通信量の爆発的増大について、一部のエキスパートたちに話を聞いてみた。しかし彼らの視点は未来よりもむしろ、今まさに起きつつあることに向けられている。

MemSQL

4月の終わりにMemSQLは、同社のリアルタイム分析プラットホームを一般に公開した。このプラットホームは、インメモリデータベースと分散インフラストラクチャを使って大量のデータを分析する。そのデータベースは、スピード重視のアーキテクチャだ。

MemSQLのCEOで協同ファウンダのEric Frenkielは、最近の10年間で大規模なデータ保存技術に重要な改善が見られた、と言う。“企業は圧縮した列保存〔参考〕とHadoopを使って大量のデータを保存し、データの保存と分析を行っていない企業に対して競合上優位に立つようになった”、とFrenkielは言う。“しかしビッグデータは、データ量が十分に多くてしかもアクセス可能でないと無益だ。今企業が苦労しているのは、ビジネスの変化の速度にデータ処理のスピードを合わせること、後者を十分に速くすることだ”。

彼によると、企業がますますデータに依存するようになると、増大する一方のデータに正しいタイミングで対応するために、より高速なデータベースを必要とする。“大量データの保持(リテンション)と保存(ストレージ)という問題が解決されると、次の課題はスピードだ”、とFrenkielは言う。“ハードディスクをフラッシュストレージで置換するとある程度速くなるが、しかし本当に必要なイノベーションはデータを保存し分析するソフトウェアの進化だ”。

MemSQLは、データ分析のためのインテリジェンスとして機能するアグリゲータだ。データ分析は複数のノードにわたってオーケストレーションされ、それらがアグリゲータのコマンドを実行する。各データノード自身は何も知らない(処理インテリジェンスを持たない)、単なる歩兵である点がすばらしいのだ、とFrenkielは言う。

“企業が今インメモリコンピューティングに注目しているのは、それがビッグデータ問題を解決するための新しいアプローチだからだ。インメモリコンピューティングは速度という成分を解決するが、しかし、量という成分を満足させるためにはスケールアウトのためのアーキテクチャが同時に必要だ”。

彼によると、今企業は、既存のソリューションを利用しつつ、データウェアハウスを最新の高速化データベースで拡張して、高速なデータ分析により意思決定の高速化を支えようとしている。“これからは、データ分析が高速で、トレンドや異状を速く見つけられる企業が勝つ”、と彼は言う。“大量のデータを分析しなければならない、という状況は今後も変わらないが、今では速度を重視したアーキテクチャにより、重要な発見や洞察がリアルタイムで得られるようになっている”。

Enigma

Engima は、先週行われたDisrupt NY 2013で優勝した。協同ファウンダのHicham Oudghiriによると、スピードのニーズの背後には必ず、データ量の絶えざる増大というニーズがある。しかし彼によると、EnigmaやPalantirなどが抱えるスケールの問題は、多くのスタートアップが日々直面している問題とまったく異なる。

“ふつうスケールというと、ユーザ数が数千、数万、数百万と増えていくことへの対応だ。だから、問題の形は、どの段階でも同じだ”、とOudghiriは言う。“複数のサーバを並列で動かすとか、予備機を増やすといったワンパターンの対応になる。Webサーバの稼働のラウンドロビン化、CloudFlareのようなCDNの利用、Amazonのようなオートスケール方式でトラフィックのピークに対応する、などなどの方法がある。しかしユーザ数ではなくてデータ集約的なアプリケーションでは、問題がまるで逆になる。スケーラビリティの問題はユーザ数ではなくて、一つのクェリのために何十億もの行を調べるという問題になる。さらにしかも、集めてくるデータの形式や性質や内容がそれぞれバラバラで不統一、という問題に遭遇することも多い”。

彼曰く、これらの問題には、サーバの台数を増やすなどの単純な解はない。ただし、データの保存という点では、冗長性が何よりも重要である。

“唯一の正しいモデル、というものはない。SQLかNoSQLかグラフデータベースか、という選択の問題でもない”、とOudghiriは言う。“それらをすべて使うこと、それぞれに適した役所(やくどころ)を与えることが重要だ。そうやって、各方式の持つ利点を最大限に利用しなければならない。データベースを、一つの理想的なシステムと見なすのではなく、それぞれの声が互いを補い合うことによって生まれる“ハーモニー”だ、と考える。一つの問題を解くときに、頭の中にはつねに、効果的に使い分けられる複数の道具がある、という柔軟性がとても重要だ”。

“第二に、RAMが自分の親友だと考えること、パーシステンシ(persistency,データのオフメモリの持続的存続)はサーバのクラスタで実装することが重要だ(サーバはパーシステンシのための装備であり、実稼働はもっぱらオンメモリで行う)。うちでは、検索のスケール(規模拡大)をRAM内で行っている。今は、メモリがとても安いから、それが十分に可能だ。ただしそうなると、RAMに保存したデータのパーシステンシを確実にメンテできるソフトウェアの構築が、重要な課題になる”。

しかし、中には、RAMのコストを問題視する人びともいる。この点について、彼に聞いてみた。

“部分的にSSDも使っているが、非常に水平的な検索(列よりも行指向)では十分に速くない”、とOudghiriは言う。“しかも、SSDは、こっちが事前に予期できないタイミングでパフォーマンスが急に落ちる。それに比べるとRAMはまったくパーシステントではないけど、むしろノンパーシステントだからこそ頼りになる。リスクと、得られる利点との、トレードオフだね”。

10gen

10genの見方は違う。10genは、NoSQLデータベースMongoDBのスポンサー企業だ。10genの技術部長Jared Rosoffは、スピードには少なくとも二つの側面、アプリケーション開発とアプリケーションのパフォーマンスがある、と言う。

“MongoDBのアプリケーション開発が速いことには、異論がない”、とRosoffは言う。“データモデルに柔軟性があり、ドライバが定型化されていることにより、デベロッパの生産性が高く、機能の改良も速い”。

アプリケーションのパフォーマンスに関しては、MongoDBは余っているメモリのすべてを最近使ったデータのキャッシュに使うので、メモリが十分に大きければインメモリの高パフォーマンスが達成される。

しかしRosoffによると、ワークロードが大きくなるとDRAMはけっこう高いものになる。

“でもビッグデータの仕事を完全にインメモリのデータベースでやろうとすると、十分な量のDRAMを使わざるを得ない。問題は、一台のサーバに載せられるRAMの量に限界があることと、RAMの費用そのものだ。MongoDBは、ディスクやフラッシュストレージを使って、一台のサーバの上で相当大きなデータ集合を処理できる。MongoDBの顧客の多くが、SSDやFlashストレージデバイスを使って、比較的安く、インメモリに近いパフォーマンスを達成している。

また、MongoDBの(NoSQLの)ドキュメント型データモデルではデータのローカリティ…局所性…を維持できるので、複雑なデータモデルと違ってディスクI/Oの回数が少ない。これも、ハイパフォーマンスの重要な鍵だ。

SlashDB

SlashDBは、関係データベースのAPIを作る。ファウンダのVictor Olexの説では、ユーザが求めるスピードはデータベースそのもののスピードに帰結する。

“データアクセスの速度は距離(ネットワークのレイテンシ)だけでなく、ファイルシステムやデータベースからデータを取り出すのに要する時間と、その間のデータ変換の量(フォーマットの変換、エンコード、デコード、圧縮など)にもよる。また、データの取り出しの効率は、データ構造の実装にもよるし、間接参照の少なさも重要だ*。とくに今のデータベース上のエンタプライズデータは(そのデータ構造が)、Webを利用する情報システムにとってボトルネックになっている。関係データベースは宣言型(not手続き型)のクェリができるので便利だが、そのためにインメモリでもディスクからでも、必要なレコードを取り出す計算費用が高くなる。逆にNoSQLのようなドキュメント型のデータベースは、一般的に数値キーでデータを取り出す。データを保存するときに数値を割り当てて、数値とデータを対照するルックアップテーブルを作っておくのだ”。〔*: 直接参照は「n番地にあるデータを読め」、間接参照は「n番地にあるデータに書かれている番地にあるデータを読め」。〕

“さまざまなキャッシング技術がデータアクセスのスピード向上に貢献しているが、そこには精度の低下という費用が発生する(目的データがキャッシュにないこともある)。たとえばWebページでは、キャッシュには古い日付のものしかないことが、よくある。でもそれは、実際にデータベースにアクセスして最新データを取り出す処理費用との、トレードオフという問題だ。我慢できるトレードオフ、と言うべきか。キャッシングとWebアプリケーションのレイヤはスケールアウト(out)して同時に複数のサーバを動かせるから、複数のリクエストを並列に処理できるが、しかしデータベースサーバの方は、一台のサーバの容量やプロセッサを増強するというスケールアップ(up)しかできない。SlashDBは企業のシステムにWeb型のサービスを提供している。つまりURLの中にクェリがあり、結果をHTTPのレスポンスで返す、という形のサービスだ。それは複数のノードでも動かせるし、通常のHTTPプロキシにも対応して、頻用されるリクエストをキャッシュしている”。

“データ集約的な処理は主に、サーバサイドのシステムの領分だった。モバイルデバイスの普及で状況はやや変わってきたが、しかしそれでも、人間の情報処理能力は昔と変わらない。一説ではそれは、毎秒60ビットと言われる。だから、それ以上速いスピードでデータを配布しても意味がない、無駄である、という説もあるのだ。Twitterやメールだけは、別かもしれないがね”。

AlchemyAPI

“AlchemAPIはスピードにこだわっている”、とCEOでファウンダのElliot Turnerは言う。“うちの顧客はみんな、情報の時間価値を知っている。だからデータをできるだけ速く処理することとうちの業績は直接結びついている。しかしデータ処理アプリケーションをもっと速く動かすための簡単な秘訣はない。ボトルネックはいろんなところで発生する。データの保存、取り出し、分析など、いろんな局面で”。

“データの分析の効率化にはさまざまな方法があり、GPUによるハードウェアアクセラレーションや、分散コンピューティング、アルゴリズムのイノベーションなどいろいろだ。AlchemyAPIはこれらすべてを組み合わせて利用するとともに、RAMやSSDを多用することによってデータの保存、取り出し、そして処理を高速化している”。

“RAMは着実に価格が下がりつつあるが(http://www.jcmit.com/mem2013.htm)まだSSDよりも一桁高いし、ハードディスクよりは二桁高い。ペタバイト規模のビッグデータを完全にRAM上で処理するのは、ちょっと費用的に無理かもしれないから、うちも含めてRAMとSSDを併用するハイブリッド方式のところが今は多い。でも、テラバイト規模の小さな展開では、徐々にRAMオンリーに変わりつつある。今後さらにRAMが安くなれば、展開規模も大きくできるだろう”。

まとめ

データ処理の高速化の話は、SSDやRAMや最新のデータベース技術だけで終わるものではない。しかし、一つだけ確かなのは、世界が高度に分散したデータメッシュになり、そしてその負荷が日に日に増大するとともに、新しい高速化の方法が必ず必要になることだ。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))