NoSQLの現状。これまでの成功と失敗

2013年1月7日

NoSQLの登場は、「データベースといえばリレーショナルデータベース」という状況を大きく変えました。リレーショナルデータベースと比べて高速でスケーラビリティに優れたNoSQLデータベースは登場当初から注目されましたが、一方でいまに至るまでさまざまな種類の製品が登場して混沌としているようにも見えます。

NoSQLの現状

InfoQの記事「NoSQLの現状」は、こうしたNoSQLの現状を俯瞰し、整理するうえで重要な情報を提供してくれる記事になっています。許可を得て転載します。

NoSQLの現状

(作者 Stefan Edlich、翻訳者 大田 緑 - (株)チェンジビジョン、投稿日 2013年1月1日)

NoSQLは厳しい批判に少なくとも4年間さらされてきました。そして、今、NoSQLの現状について中間報告する時がやって来ました。NoSQLの周辺ではいろいろなことが起こったため、全体像をつかんで、どのような目的を達成したか、また、NoSQLはどこで失敗したかを評価するのは簡単なことではありません。

様々な分野において、NoSQLは産業的にも学問的にもかなり成功をおさめてきました。大学は、カリキュラムにもっとNoSQLを取り込まなければならないことを理解し始めています。データベースの標準化について、あれこれ教えるだけでは十分ではありません。もちろん、難解なリレーショナルデータベースの基礎が間違っているという意味ではなく、NoSQLの追加は間違いなく理想的で重要なことなのです。

何が起きたのか?

NoSQLは、たった4、5年で50から150の新しいデータベースを増やしました。nosql-database.orgは、そのようなデータベースを150程紹介しています。その中には、Object Databaseのように、非常に古いけれども、まだ強力な時代遅れのものも含まれていました。そして、もちろん、いくつかの興味深い合併があり、CouchDBとMembaseはCouchBaseになりました。この記事では、主要なシステムについて後ほど触れたいと思います。

多くの人々は、NoSQLの世界では大きな合併が起きていると考えてきました。ところが、本当はそうではありません。NoSQLは、ただ急激に増えただけであり、まだ増え続けています。プログラミング言語のようなコンピュータサイエンスのすべての分野と同様に、非常に多くのデータベースのギャップはますます広がっています。これはインターネット、ビッグデータ、センサー、そして、もっと多くの将来の技術が急激に増えることにつながり、より多くのデータや処理に関する様々な要求へと続いています。ここ4年間で、重要なシステムがステージから去るのを見たのはたった1つ、ドイツのグラフデータベース、Sonesだけです。多くのNoSQLデータベースは、あまり金銭的な見返りのないオープンソースの世界か、商業的なところで、うまく生き残っていくでしょう。

見通しと資金

もう1つの重要な点は、見通しと業界での適用です。この分野において、投資を守る古い業界と大抵は新興企業である新しい業界の間では、大きな違いが見られます。PinterestやInstagramなどのほぼすべての新しいウェブ関連企業は、SQLとNoSQLを組み合わせたハイブリッドなアーキテクチャを使いますが、「古い」業界は、なかなかNoSQLを適用できないでいます。しかし、ここで注目すべきなのは、ますます多くのこのような企業がデータストリームの一部を切り離し、HadoopやMongoDB、CassandraのようなNoSQLのソリューションを使って処理し、分析しようとしていることです。

このため、NoSQLの知識を持つ開発者やアーキテクトに対する需要が高まってきています。最近の調査によると、最近必要とされる開発スキルは次の通りです。

  1. HTML5
  2. MongoDB
  3. iOS
  4. Android
  5. Mobileアプリ
  6. Puppet
  7. Hadoop
  8. jQuery
  9. PaaS
  10. ソーシャルメディア

技術的要求のトップ10の中で、NoSQLデータベースは2つあります。1つは、iOSよりも上です。これがNoSQLをほめているのでなかったら、何なのでしょう?!

しかし、一見したところ、NoSQLはますます速く深いところまで適用されるようになっています。2011年の夏に、有名な報告書の中でOracleは次のように述べました。NoSQL DBがアイスクリームの味のように感じるかもしれないけれど、あまり深入りしない方がいい、NoSQLはそれほど長く残らないかもしれないから。そのわずか2、3ヶ月後、OracleはHadoopのBig Data Applianceへの統合を示しました。さらに、OracleはBerkeleyDBを作り直して、自分たちのNoSQLデータベースを作ったのを、私たちは目にすることになりました。それから、あらゆるベンダがHadoopを統合し始めました。Microsoft、Sybase、IBM、Greenplum、Pervasiveやその他多くのベンダが、すでにきっちりと統合していました。戦うのではなく、受け入れようというパターンはどこでも見られました。

しかし、NoSQLが幅広く適用されていることを示す、静かだけれどももっとも強いサインの1つは、NoSQLデータベースがPaaS標準になってきていることです。多くのNoSQLデータベースは設定や管理が簡単なので、RedisやMongoDBのようなDBは、Cloud-Foundry、OPENSHIFT、dotCloud、Jelasticなど数多くのPaaサービスの中で見られます。すべてクラウドに移行されていく中で、これによりNoSQLが昔からあるリレーショナルデータベースにプレッシャーを与える勢いが増しています。MySQL/PostGresか、MongoDB/Redisのどちらを選ぶか選択させることで、例えば、モデルや要求についてもう一度考えさせたり、他の重要な疑問がわいてきたりします。

技術的に興味深い指針は、ThoughtWorksレーダーです。ThoughtWorksレーダーは、すべて完全に同意できなくても、常に数多くの興味深い事柄が含まれています。図1に2012年10月のレーダーがあるので見てみましょう。

fig 図1: ThoughtWorksレーダー、2012年10月 - プラットフォーム

プラットフォームの四分円で、以下の5つのデータベースがあります。

  1. Neo4j (採用)
  2. MongoDB (トライアルだが、採用間近)
  3. Riak (トライアル)
  4. CouchBase (トライアル)
  5. Datomic (評価中)

これを見れば、5つのデータベースのうち、少なくとも4つは多くのベンチャーキャピタルを受け取っているのが分かります。NoSQLの分野全体でベンチャーキャピタルをすべて足したら、1億ドルから10億ドルの間になるでしょう! Neo4jは、シリーズB投資ラウンドで1千百万ドルを手に入れた例の1つです。投資家から1千万から3千万の資金提供を受けた企業には、Aerospike、Cloudera、DataStax、MongoDB、CouchBaseなどがあります。しかし、もう一度リストを見てみましょう。Neo4j、MongoDB、Riak、CouchBaseは、ここ4年間この分野にいて、特定の要求に関して市場のリーダーであることを絶えず証明してきています。5番目のDB、Datomicは、突然現れただけでなく、完全に新しいデータベースであり、小さなチームによって書かれた完璧な新しい範例です。これは、本当に新しいことに違いありません。そのため、手短にDB全体について述べた後で、Datomicをもう一度詳しく取り上げます。

標準

多くの人たちがNoSQLについて尋ねましたが、かなり広範囲のモデルや要求をNoSQLがカバーしていることには気付きませんでした。そのため、ワイドカラム、キー/バリュー、ドキュメント、グラフデータベースなどの主要分野の統一言語は、これらすべての分野をカバーできなかったため、長い間利用できませんでした。Spring Dataなどのいくつかのアプローチでは、統一レイヤを追加しようとしていますが、それは、このレイヤが複数の分野において、永続化環境を構築する飛躍的な手段になるかどうかをテストする読み手次第です。

主に、グラフとドキュメントデータベースは、独自のドメインにおいて標準となっています。グラフの世界は、TinkerPop Blueprints、Gremlin、Sparql、Cypherなどでより成功しています。ドキュメントの分野では、最初はNoSQLデータベースの実世界でのサポートはありませんでしたが、UnQLやjaqlがニッチを狙っています。しかし、Hadoopの力によって、多くのプロジェクトはPigやHiveなどの有名なETL言語を他のNoSQLデータベースへブリッジすることに取り組んでいます。そのため、標準はかなり断片的になっていますが、それはNoSQLがかなり広い分野であるという事実のためなのです。

展望

データベースの展望を示す最もよい要約は、Matt Aslett氏のthe 451 Groupのレポートのレポートで見ることができます。Aslett氏は最近カテゴリについてさらに洞察し、その図を更新しました。以下にその図を示しますが、展望はかなり断片的で、重なりあっています。

fig 図2: Matt Aslett氏 (451 group) によるデータベースの展望

ご覧の通り、この1つの図はいくつかの部分に分かれています。リレーショナル対非リレーショナル、分析対操作、NoSQL対NewSQL。最後の2つのカテゴリには、キー/バリュー、ドキュメント、グラフ、NoSQLのビックテーブル、ストレージエンジン、クラスタリングとシャーディング、新しいデータベース、クラウドサービスソリューションなどのよく知られたサブカテゴリがあります。この図の興味深いところは、データベースを決まった場所に置くのがますます難しくなっていることです。どのデータベースも他の分野で見つけたデータベースから機能を統合しようと躍起になっています。NewSQLシステムは、NoSQLのコアな機能を実装しています。NoSQLシステムは、SQLのサポートやACID、または、少なくとも時には設定可能な永続性などの「昔からある」機能をできるだけ多く実装しようとしています。

今では多くのリレーショナルデータベースが提供するHadoopの統合ですべては始まりました。しかし、他の例も沢山あります。例えば、MarkLogicはJSONの波に乗り始めていて、そのために位置を定めるのが難しくなっています。さらに、ArangoDB、OrientDB、AlechemyDBなどのより多くのマルチモデルデータベースが現れています。AlechemyDBは、今では将来有望なAerospike DBの一部です。これらは、ドキュメント/JSONモデルのように1つのデータベースモデルで始め、新しい要求が上がってきたら、グラフやキー/バリューのような他のモデルを追加できるようになっています。

書籍

成熟の始まりを示すもう1つの素晴らしいサインは、書籍市場です。2010年と2011年にドイツ語の本が2冊出版された後、Shashank Tiwari氏のWileyの本を見かけました。ハリケーンのように構造化され、素晴らしい考察にあふれた本でした。2012年にも優れた本が2冊出版されました。「Seven Databases in Seven Weeks」(7週間で7つのデータベース)は傑作に違いありません。新しく書かれたもので、実践的な洞察にあふれています。6つの有名なNoSQLデータベースを取り上げ、PostGreSQLを付け加えて、1番目に推薦しています。もう1つは、P.J. Sandalage氏とMartin Fowler氏の本であり、もっと全体的なアプローチを用いてすべての特徴をカバーし、NoSQLに関してあなたが進むべき道と決定を評価する手助けをしています。

しかし、さらに付け加えることがあります。Manningから出版されるのも時間の問題でしょう。Dan McCreary氏とAnn Kelly氏が「Making Sense of NoSQL」(NoSQLを理解する)と呼ばれる本を書いていて、最初のMEAPに関する章はすでに読むことができます。

コンセプトとパターンから始めて、3章は確かにおもしろそうです。

NoSQLビッグデータのソリューションを構築する NoSQL検索のソリューションを構築する NoSQLの高い可用性のソリューションを構築する 機敏性を高めるためにNoSQLを使う これは、新しいアプローチであり、確実に読む価値があります。

リーダーの現状

ここでNoSQLのリーダーについて少し考えてみましょう。明らかにマーケットリーダーであるHadoopは奇妙な動物だと言えます。一方で、非常に勢いがあります。前述したように、昔ながらのデータベースベンダは、大急ぎでHadoopのサポートをアナウンスしようとしています。ClouderaやMapRのような企業は成長し続け、新しいHadoopの拡張や継承を毎週アナウンスしています。

HiveやPigでさえ、ますます受け入れられています。それにもかかわらず、うまくいっていない部分があります。企業は、構造化されていない混乱(ファイルの読み込みやパースがもっと速くなるのではないか)についてまだ文句を言っています。MapReduceはバッチ処理が多すぎる(Googleでさえ、手を引いています)し、管理はまだ難しく、安定性の問題もあります。地元でトレーニングやコンサルタントを見つけるのも簡単ではありません。しかし、いくつかの問題に対処できたとしても、Hadoopがそのまま成長するか、または、劇的に変わるかというのは、注目すべき疑問です。

2番目のリーダー、MongoDBも激しい議論に苦しんでいます。先頭に立つDBがもっとも批判にさらされるのは必然なのかもしれません。それにも関わらず、MongoDBは速いペースで進み、批判は大体次のようなものです。

a) 古いバージョンに対する懸念
b) 正しい方法でMongoDBを扱う方法について知識がないため。最近盛り上がっているのは、32ビットバージョンが扱えるのは2GBだけだというばかばかしい不満です。MongoDBは、このことについてはっきりとダウンロードの部分で述べていて、64ビットバージョンを推奨しています。

それはともかく、MongoDBのパートナーシップと投資ラウンドによって、最新情報を含む野心的なロードマップが示されました。

  • セキュリティが必要な産業 / 現在開発中のLDAP機能
  • フルテキストサーチはすぐに追加される
  • MapReduceのV8がリリースされる予定
  • 細かいレベル、それからまとまったレベルでのロックも実装される予定
  • ハッシュシャードキーは実現間近

特に、最後の点で多くのアーキテクトの関心を引いています。MongoDBは、しばしば簡単で首尾一貫したハッシングが実装されていないことで、競合相手を含む人々から批判されていました。MongoDBのハッシングは、すべて正しい訳ではなく、キーは簡単に定義できるものでした。しかし、将来、ハッシュシャードキーの設定ができるようになります。つまり、シャーディングのハッシュキーが役に立つかどうか、自分自身のシャーディングキーを選ぶことで、おそらくめったにない利益を得る必要があるかどうかをユーザが決めることができます。確実に、このことは他のベンダへのプレッシャーを強め、シャーディングキーをいつ使うかという有益な議論へとつながっていくでしょう。

Cassandraは次の位置にいて、よりよいクエリのようなより優れた機能をうまく追加しています。しかし、Cassandraのクラスタを動かすのは簡単ではなく、大変な努力が必要だといううわさはなくならないでしょう。しかし、ここでもっとも魅力的なのはDataStaxです。Cassandraを扱う新しい会社 - 2千5百万のC投資ラウンド - は、分析論といくつかの運用上の問題を扱います。最初の頃、Cassandraは強力なクエリマシンではなかったので、特に分析論は多くの人たちにとって驚きでした。ところが、最新バージョンでは変化が見られ、クエリの性能は現在の分析には十分なものになっています。

Redisの開発スピードも注目すべきものがあります。Salvatore氏が、Pieter Noordhuis氏の手助けとコミュニティがなければ何もできなかったと主張しているにも関わらず、素晴らしい独り舞台のようです。指標のフェイルオーバーやLuaプログラミング言語を用いたサーバサイドスクリプティングは最近できたものです。コミュニティの人たちはサーバサイド言語としてJavaScriptを統合していたので、Luaの決定はコミュニティに少しショックを与えました。それにも関わらず、Luaは優れた言語で、Redisが可能性の新しいパンドラを開く手助けとなるでしょう。

FacebookやZyngaが今直面している強い風にも関わらず、CouchBaseもまた、スケイラビリティと待ち時間に関して、最高のソリューションのようです。CouchBaseは、確かに最新のクエリマシンではありませんが、将来クエリを改善できれば、ポートフォリオはかなり完成されたものになります。CouchDB創設者との合併は、確かに強力なステップであり、CouchBaseの中のCouchDBに大きな影響を与えているのは見る価値があります。データベースのカンファレンスで、Damien氏、Chris氏、Jan氏が去った後、CouchDBが良くなったか、それとも、悪くなったか議論しているのを聞くのはおもしろいでしょう。ここでは極端な意見だけを聞けますが、DBが動いている限り、誰も気にしません。CouchDBは動いていますからね。

ここで紹介する最後のNoSQL DBは、もちろんRiakです。Riakは機能性とモニタリングに関して、劇的な改善を見せています。Riakは安定性に関して良い評判を得ています。「信頼できて、目に見えず、あなたの眠りにも良い。」 この技術のモデュラリティに関して、Riak CSを提供しているのも興味深いものがあります。

おもしろい新参者

マーケットリーダーは別にして、新参者を評価するのはいつでもおもしろいことです。ここでいくつか詳しく見てみましょう。

Elastic Searchは、確実にもっとも注目集めている最新のNoSQL製品の1つであり、シリーズA投資ラウンドで1千万ドルを手に入れたところです。これには正当な理由があります。Lucene上のスケーラブルなサーチエンジンとして、多くの利点があります。a) サービスを提供している会社であること。b) Luceneが昨年成し遂げたことを強化していること。Elastic Searchは、半構造化された情報の分野において大きなプレーヤーを攻めつつ、過去に例を見ないほど確実にこの業界に浸透していくでしょう。

Googleもまた、小さいけれど速いLevelDBをこの分野に送り込んでいます。そして、圧縮統合のような特定の要求で使われる基礎として機能しています。Riakでさえ、LevelDBを統合しました。DremelやSpannerのようなすべての新しいGoogleのインターナルデータベースが、Apache DrillやCloudera Impalaのようなオープンソースプロジェクトとして活路を見出せるかどうかはまだ分かりません。

もう1つの構造上のシフトは、間違いなく2012年の初めのDynamoDBです。DynamoDBは、Amazonが今までに始めた中で一番速く成長したサービスだと言われています。DynamoDBは、究極のスケーリングマシンです。新しい機能の追加はゆっくりしていますが、SSDに注目していて、待ち時間はかなり素晴らしいと言えます。

マルチモデルデータベースは、見てみる価値のあるところです。有名なものでは、OrientDBがあり、OrientDBは新しくはありませんが、非常に速く性能を改善しています。おそらく性能の改善は速すぎるかもしれません。OrientDBがバージョン1.0になったことに満足し、安定性を高めてほしいと望んでいる顧客もいます。トランザクションとSQLに組み合わされたグラフ、ドキュメント、キー/バリューのサポートは、もう一度試してみようというユーザを十分に引きつけています。特に、SQLの優れたサポートは、Pentahoのような分析的なソリューションにとって興味深いものです。この分野のもう1つの新参者は、ArangoDBです。ArangoDBは速く動き、すでに使われているデータベースに対して、ベンチマークで比較されることにひるむことはありません。 しかし、もう一度言いますが、ネイティブのJSONやグラフのサポートは、新しい要求を実装しなければならない場合や、新しいデータが別のモデルで永続化されなければならない場合に、多くの労力を省くことができます。

今年の最大の驚きは、間違いなくDatomicです。信じられないほど短期間でClojureプログラミング言語のロックスターによって書かれたDatomicは、新しい枠組み全体を明らかにしています。さらに、ThoughtWorksレーダーで取り上げられて、Datomicを見てみるように推薦されています。Datomicは構築されたデータベース上にあるただのレイヤですが、大きな利益をもたらします。

  • トランザクション
  • タイムマシン
  • 最新で強力なクエリアプローチ
  • 新しいスキーマアプローチ
  • キャッシングとスケーリング機能

現在、DynamoDB、Riak、CouchBase、InfinispanとSQLは、基礎をなすストレージエンジンとしてサポートされています。そして、同時に異なるDBを使用したり、問い合わせたりできます。多くのベテランたちは、そのような急進的なパラダイムシフトが可能であることに驚いています。運よくそれは可能だったのです。

まとめ

結論として、以下の3点があります。

  1. CAP定理に関するEric Brewer氏のいくつかの新しい記事は、数年早く発表されるべきでした。この記事の中で、Brewer氏は「3分の2」は誤解させるものであり、なぜ世界がACID/BASEの選択のようにシンプルなCP/CAよりも複雑であるかその理由を述べています。それにも関わらず、何年もの間、何千という講演や記事では、批判的なレビューもなくCAP定理を賞賛し続けています。Michael Stonebraker氏は、NoSQLの動きに関して最強のセンサーを持ち、(NoSQLの分野は、Stonebraker氏に多くの借りがあります。) 何年も前にこれらの問題を指摘しています。残念なことに、それほど多くの人が耳を傾けてはいませんでした。しかし、今では、Eric Brewer氏はその定理を改め、シンプルなCAPを主張する時代は完全に終わっています。どうか本当の、そして、多様なCAPの潜在的重要性を表立って指摘してください。

  2. 私たちみんなが知っているように、昔からあるリレーショナルデータベースの弱さが、NoSQLの分野をもたらしました。しかし、帝国が反撃するのも時間の問題です。「NewSQL」という言葉のもとで、昔からあるソリューションやシャーディング、クラウドソリューションを改善した沢山の新しいエンジンをみることができます。(例えば、database.com、VoltDB、GenieDB、など。図2を参照のこと。) これというのも、NoSQLの動きのおかげです。

  3. しかし、多くのDBが各機能を実装しようとすると、明らかな境界は消えていきます。 データベースの決定は、今までになく複雑化しています。50のユースケースと50のDBを知らなければならず、少なくとも50の質問に答えなければなりません。50の質問は、2年以上もNoSQLのコンサルティングをしてきた著者が集めたものを、こちらで参照することができます。Select the Right Database(正しいデータベースを選択する)、 Choosing between NoSQL and NewSQL(NoSQLとNewSQLの間の選択)。

テクノロジのシフト - クライアントサーバやもっと前のものから - は、切り替えるのに10倍以上コストがかかります。例えば、メインフレームからクライアントサーバへの切り替え、クライアントサーバからSOA、SOAからWEB、RDBMSからハイブリッドな永続化などです。その結果、多くの企業はポートフォリオにNoSQLを追加することをためらい、苦しんでいます。しかし、両方の世界から良いところだけ手に入れて、NoSQLを速く統合しようとしている初期の導入者は、将来、より良い位置にいられるでしょう。この点において、NoSQLのソリューションは普及するでしょう。そして、常に評価に値する分野であり続けるでしょう。

著者について

Stefan Edlich教授は、Beuth HS of Technology Berlin (University of App. Sc.)の上級講師です。Apress、OReilly、Spektrum/Elsevierなどの出版社で10冊以上のIT関連の本を出版しています。NoSQL Archiveを運営し、NoSQLのコンサルティングを行い、NoSQLのカンファレンスを運営しています。また、世界最初のNoSQLの本を2冊書き、Clojureプログラミング言語を愛好しています。

あわせて読みたい

NoSQL データベース CAP定理 MongoDB




タグクラウド

クラウド
AWS / Azure / Google Cloud
クラウドネイティブ / サーバレス
クラウドのシェア / クラウドの障害

コンテナ型仮想化

プログラミング言語
JavaScript / Java / .NET
WebAssembly / Web標準
開発ツール / テスト・品質

アジャイル開発 / スクラム / DevOps

データベース / 機械学習・AI
RDB / NoSQL

ネットワーク / セキュリティ
HTTP / QUIC

OS / Windows / Linux / 仮想化
サーバ / ストレージ / ハードウェア

ITエンジニアの給与・年収 / 働き方

殿堂入り / おもしろ / 編集後記

全てのタグを見る

Blogger in Chief

photo of jniino

Junichi Niino(jniino)
IT系の雑誌編集者、オンラインメディア発行人を経て独立。2009年にPublickeyを開始しました。
詳しいプロフィール

Publickeyの新着情報をチェックしませんか?
Twitterで : @Publickey
Facebookで : Publickeyのページ
RSSリーダーで : Feed

最新記事10本


pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy