データベース研究者から見た"ビッグデータ"の意義「HadoopもNoSQLも邪道だけど…」

高校生の頃まで、パソコンが苦手だった

原隆浩氏：まず、今日データベース研究会のほうから代表ということで来ましたので、自己紹介を兼ねてお話したいと思います。私は今、大阪大学で准教授をしていまして、42歳になります。なので、大学を卒業してちょうど20年経っているぐらいです。

研究の専門分野は、あんまりデータベースっぽくなくて、どちらかというとネットワークとデータベースの境界領域みたいなことをやって、アドホックとかセンサーネットワークにデータ管理のフレーバーを入れるみたいことをずっとやってきました。

P2P、Web、ユビキタス、プライバシーなど境界領域が好きなんで、分野が違う皆さんともいろいろな話ができるんじゃないかと思います。研究歴、論文執筆歴がだいたい20年で、過去に論文誌160点、国際会誌220点、その中でも特にIEEEのトランザクションとかメジャーな論文誌だったりにいくつかの論文を公表しています。

これはちょっと、国内外でも珍しいパターンだと思うのですが、データベースとか、知識処理とか、地理情報システム、Web通信、信頼性、ユーザインターフェース、分散処理とか、とんでもなく広い分野のトップ会議や論文誌の論文を出しています。ということで、割とちゃんと研究はしてますというところなんですが、この自己紹介にはちょっと裏があります。

実は私自身は、高校生まですごいパソコンが苦手というか、ヘイトでした。パソコンやってる人とは生涯一生、友達にはならないだろうなと思っていて。高校の時はフィジカルにいろいろと遊んでいました。

実は志望コードを書き間違えてですね、受けてない阪大の電気系、この中に情報系学科が入ってるんですけど、そこからなぜか合格発表が来てしまってですね、別の第一志望の大学の入学手続きに行くついでに、受けてないよということを阪大にアピールしに行ったら、受かってますという話になって。何となくそれがつぼにはまっちゃって、阪大に行ったという、これが私の阪大生活スタートです。

実は入学説明会まで学科のことをまったく知らなくて、それで情報系学科があるっていう話を聞いてとんでもないとこ来ちゃったなというので、ものすごい後悔しました。その後に紆余曲折あって、西尾研究室、情報処理学会の前の副会長で、データベース学会の前会長をされていた西尾先生のところに縁があって入って、20年間ずっと研究室に変わらず残ってるというのが、私の研究者としての生活になります。

ここでまずメッセージ1「現在は未熟でも必死で頑張れば何とかなる」。私自身が22歳で研究室に配属してから初めてまともにプログラムを書く、まともに研究する、まともに情報について取り組むみたいなことをやり始めて、それで20年後にここに至るということは、今は苦手意識を持っていたり、専門分野に自信がない人でも、この20年後、情報処理祭の講師をしているかもしれない可能性もあるわけです。

なので人生って選んだところで必死にやることで、けっこう道が開けることがあるというのは、私自身の体験としてあります。

データベース研究家は、データベースをやってない!?

さて、本題のデータベースの研究なんですが、実はデータベースの研究って、研究分野自体がすごく広くて、データベース研究者の考え方はこれです。

基本的に全部のアプリケーションというのは、データを触る。ということは、データを触るんだったら、データを触るものは全部がデータベースの研究じゃないというふうに本気で考えています。

なので、実はデータベース分野でデータベースそのもの、皆さんが教科書で関係データベース、SQLとか、インデックスとかいろいろやりましたよね、ああいう感じのデータモデルや問合せの処理の方法とか、データベースエンジンの研究してる人っていうのはデータベース分野の人は本当に少ないです。もしかしたら1～2割ぐらいかも。

だからデータベースの研究者は、実はそんなにデータベースそのものはやってないんですね。これには実は理由があって、データベースの研究者っていうのは、長い歴史の中で自分たちが必死で頑張って何十年と築き上げた技術、純粋な原理というのは、結局社会の中で主流にならないという苦汁を何回もなめさせられているんです。

流行らないと思っていた考えが、データベースの主流に

一番いい例がWeb、XML、あと今日、お話するビッグデータ。WebとXMLは実は、World Wide Web コンソーシアムの人たちなどのデータベース研究者以外の人が定義して、主流になったものです。当時データベース研究者は、こんなのデータベースとしては絶対に流行んないと言ってたんですけど、結局流行っちゃったんですね。それで主流になってしまった。

ビッグデータもしかりです。Hadoop、MapReduce、NoSQLはデータベースの研究者、技術者から出た技術ではないです。そこで、データベースの研究者は、結構シフトチェンジしまして、これは伝統にとらわれてたら話にならんなということで、ちゃんと主流の中で流行ってる技術の中で、自分たちの持ってるデータベースの研究者としての専門技術をどんどん取り込もうということを考えたわけです。

なので、データベースの非専門家がWebだったりとか、Hadoopを開発して、すごく流行ったときに、ここで腐らずに、しかも自分がやっている古い技術に固執せずにずっと頑張ってきたわけです。そして、やっぱりWebしかり、Hadoop、MapReduceもそうですが、データベースの技術だったり、データ管理の詳しいところがわかってないので、非専門家だけだと最終的には息詰まるんですね。

技術って簡単なものが一気に流行って、結局は元の複雑な理論のところにどんどん行くという傾向があります。なので、ここでデータベースの専門家が自分の持っている技術、自分の持っている技術的な視点を使うことによって、今流行ってる技術が飛躍的に進化するということがあるんです。

なので実際はWebとかは、裏ではほとんどデータベースが動いてますよね。データベース技術者はこういうところも頑張ってやってて、ピュアにデータベースをやってるばかりじゃないわけです。

差別化できる技術を2つ持っていると強い

今日は、私のメッセージは2つしかないんですけれども、差別化できる技術を持っているのは非常に強いです。これは技術者、研究者に限らず何にしても、他の人が持っていない技術を持っていると、とても強い。

データベースの研究者でいうところのデータベース技術というのは、まさにそれです。皆さんは若いので、いろんなことに興味があって、いろんなことに手を出したがる傾向があるんですけれども、とりあえず1つは絶対に誰にも負けないという技術を身に付けることが重要です。

あと研究者として本当に大成して頑張ろうと思うと、これを2つ持つとめちゃめくちゃ強いです。なぜかというと、1個でも持ってないような技術を2つ持っていると、それを融合したり、別の分野にその2つをセットにして、また取り組んだりすると、普通の人がしないような研究ができるんですね。

実は私はデータベースをもともとやってたんですけど、それ以外にもネットワーク、無線だったりとか、高速ネットワーク、モバイル、ユビキタス、いわゆるネットワーク系の技術というのを真剣に勉強してそっちのほうだけでも論文を書いていたりしました。そして、この2つを融合することで、20年間研究者としてご飯を食べているわけです。

データベース研究の変遷

データベースの研究に戻りますと、データベースの研究の長期的な変遷をまずちょっとみてみたいと思います。

ポイントはとにかくここです。インターネットが普及する1990年代中盤に大きな変革がおきます。この図の上の方は、商用の技術とか、研究じゃない一般的な技術がどのように発展したかというのをあらわしています。まず、1970年代と1980年代の境ぐらいに、IBMからデータベースの商用システムが登場しました。

インターネットが普及して、Webが出てきて、モバイルのデータベースだったりXML、P2P、センサ、スマートホンの爆発的普及だったり、ビッグデータですね。こういう流れが世の中で起きてるわけです。

この中で、研究ではどのようなことが起きていたかというと、黎明期というのはインターネットが普及するまで、世の中で何が起きるか漠然としかわからなかった。

なので、実は古典的なデータベース技術とか、インターネット内、LAN内、WAN内などネットワーク上のデータベース技術とか、モバイル環境におけるデータベース技術というのは、先見性を持っている、つまり10年後のことを予測するのがうまい人たちが、今ないものを想像して研究を始めて、それが研究分野として確立していったのです。

これ以降にインターネットが普及すると、さっき言っていた苦渋をなめさせられたWebの登場だったり、XMLなどのいろんなものがおきてきて、何か昔の技術だけ使ってたら話にならないようになったんですね。

そうするとどうなったかというと、実際の技術の登場と、研究の開始というのはほぼ同じタイミングで起きてます。これが今のデータベースの、先ほど言ったデータベース研究者のスタイルをよく表しているんですね。

研究がネットワークとかシステムの環境に依存して発展していくのは共通していますが、黎明期は割と技術の進歩が緩やかなんで、10年程度は先読みしていたわけです。最近は、新しい技術が出てきたらそれに対して、いち早くデータベースのフレーバーをどんどんのせていくという形で新技術の研究の流行というのはおきています。

トレンドは、ビッグデータ

次は、特にここ数年の流れを見てみたいと思います。データベースの研究者は真面目なので、数年に1回ですね、著名な世界的研究者が30人ぐらい集まって、今何が起きている、今後何が起こるかみたいなものを議論する会があります。

この最新のもので、「Beckmanレポート」があります。ちなみに、Beckman というのは、カリフォルニア大学アーバイン校にあるセンターの名前です。そのBeckmanレポートで言われているのは、本当にとにかく今、ビッグデータ一色です。

実はデータベースの業界だけじゃなくて、今日もいろんな講演の中に話がありましたが、すべての業界で、ビッグデータは必ずでてきます。しかも、実は研究だけじゃなくて国策レベルで、中国、アメリカ、日本しかり、ビッグデータを制する者が国を制する、世の中の主流になるという感じで、国レベルで国策として研究開発を進めているという状況です。

なのでそれに従って、データベース業界も本当にビッグデータ一色です。これが流行った理由は皆さんもご存知かと思いますが、今日もセンサ、スマートデバイス、ソーシャルサービス、IoTといういろんなお話があったように、様々なデータ発生源からいろんなデータが出てきています。

おまけにそのデータを蓄えるストレージがどんどん安くなってくる。データを蓄えることに対してお金があんまりかからなくなった。そしてこれも先ほどからお話がでていますが、ハイパフォーマンス系の技術の発展だったり、クラウドですね。自分がシステムを持っていなくてもすごい安いお金で高性能のマシンを使えたり、ソフトウェア自体を買わなくても、オープンソースのソフトウェアで非常に高性能のものが手に入るので、溜めたデータを解析することも非常に安くできるようになってます。

そして人間そのものが一般の人も含めて、データを生成、消費し始めています。ブログを書いたり、ソーシャルネットワークにデータを投稿したり、あと科学技術のデータとかもいろんなところでオープンデータ化されていて、データ自体も多様化しているというのが、ビッグデータの特徴になるわけです。

ビッグデータの特徴は「Volume, Velocity, Variety」

ビッグデータの特徴、3Vというのを聞いたことありますか？　「Volume, Velocity, Variety」です。ビッグデータの特徴はなんだと言われれば、そのまんまなんですけども、まず大量、これは誰でも思いつくことですね。そして、高速に生成されるセンサなどのストリームデータ。ストリームで1秒間に非常に大量のデータが処理しきれないほどに生成する場合もあります。さらにその種類もいろんなデータ発生源があるので、今まで常識的に考えていた技術では手に負えないだろうというのが、ビッグデータ研究の始まりです。

じゃあなんでみんなこんなに研究するのかというと、手に負えたらいろんなことができるわけです。今ほとんどのネット系企業でやっていると思いますが、顧客の情報を解析したり、ソーシャルネットワークの情報とか、ブログとかTwitterの情報を解析して、マーケティング戦略を立てる。

同じようにオバマさんが大統領選挙で、それを使って、カルフォルニアのマダムはこういう俳優が好きなんで、応援演説をしてもらうとか、そういうベタな話まで含めて、いろんな世の中で起きてる全般のことを大量にデータを集めることで、定量的解析ができる。要は世の中で何が起きているのかということを、ちゃんと証拠付きで解析できるというのがビッグデータですね。

それをちゃんと解析してモデルが1回できてしまうのと、今の状況に対して将来を予測することも可能になってくる。ここがビッグデータの狙いです。ここも先ほどからお話がありましたが、データが多ければ多いほど、実は同じ技術を使うと飛躍的に性能は高まります。

例えば音声認識の場合、50％の認識精度だったのが、コーバスが増えてどんどんデータが増えてると、同じような技術で95%を超えるとか、そういうことが平気で起こるんです。

なので、データをたくさん集めてそれをしっかり解析するというのは、どの業界からも今注目されているし、必須なものになるわけです。

ビッグデータにおける研究分野のトレンド

次に研究分野のトレンドについて話しましょう。このリストのはじめ2つはより一般的な課題です。まずは、1つ目。今現在ではこのトピックに関して研究しているデータベース分野の人が7割くらいかなというところです。

まずスケーラブルなビッグデータ基盤は、ビッグデータを実際に解析したりとか、処理するための基盤開発です。ダイレクトにビッグデータを扱うための課題ですので、主に「Volume」と「Velocity」に対する作戦を立てるという感じです。データベース分野におけるビッグデータの研究としては、これが王道です。

次に、こちらも20年間くらいの歴史がある研究分野ですが、データの管理形態が多様化して、データが多様化しているので、「Variety」に対して何とかしようよという研究です。概ねこの2つがこれまでの研究分野の主流で、だいたい8割超えていると思います。

ただ最近、特に注目されているのが、今からお話する3つの課題です。まず、エンド・ツー・エンド、ユーザー指向の処理とデータ理解です。これは何かというと、データマイニングとかやってる人はわかると思うのですが、マイニングして出てきたルールがよくわからん。よくわからん数値が並んでいたり、データが並んでるけど、これなんなのっていうのが、一般のユーザーとか技術者には分からない。だから解析結果をわかる形で、役立つ形で見せようという技術の開発です。

次に、クラウドですね。そもそも解析とかデータ自体のストアをデータセンターだったり、他のクラウドの計算機にやってもらうみたいな感じなことになった途端に、今までのデータ解析技術とかデータベースの技術をそのままでは使えなくなるんですね。

人が生成するデータをどうコントロールするか

最後に、さきほども少し話しましたが、データサイクルの中で人が入ってくる。人が生成する、人がデータを消費する、人が解析するっていうところを、どううまくコントロールするかっていう研究が今注目されています。

システム図で見るともっと分かりやすいと思います。ビッグデータを構成するのは、センサだったりIoT系のものというモノが生成するデータ、人が生成するソーシャルブログだったりとか、マイクロブログだったり、ソーシャルネットワーク系のデータ、あとはアプリの履歴だったり、ネットワークの履歴だったりっていうログデータですね。Webの検索の履歴とかもここに含まれます。

それらをビッグデータとして吸い上げて、計算機で解析するということが今行われていて、これの結果をエンドユーザー、例えばデータアナリストがその結果を見て、自分達に必要なもの、目的に対する戦略を立てる。

おまけにこの処理システム自体は外注でクラウドに頼むということも考えられます。

ビッグデータをダイレクトに解析することの研究が課題1で、データを吸い上げてバラバラなものを何とか統合利用するというのが課題2。これらが先程言った中心部にあるところで、主流の研究分野です。

最近はこの末端のクラウドをどう使うのか、ユーザーに見せるときにどうするのか、人がデータを生成する場合にはどうやってコントロールするのかっていうのが研究の流行になっていると思ってください。

Hadoopの起源はGoogleの検索エンジン

ここから1つずつの課題をお話したいと思います。まず課題1の前提知識は、HadoopとNoSQLです。Hadoop、NoSQLは皆さんがデータベースの授業でやったような技術と比べるととても簡単なので、さわりだけお話します。

Hadoopっていうのはビッグデータの分散処理のフレームワークで、おそらく皆さんの中でも趣味とかで使っている方がいるんじゃないかと思います。それとNoSQL。これはNot Only SQLの略で、実は何かのデータベースのことを言ってるんじゃなくて、関係データベースでは性能が十分に出ないようなアプリケーションを対象とした新しいデータベースおよびその技術全般のことをいいます。

なので特定の言語とか管理システムではないです。あとこれもよく言われるんですけども、No! SQLとかNo more SQLとかではなくて、やっぱりSQLも重要なので、Not Only SQLなんです。

さて、これらの技術についてお話したいと思いますが、まずHadoopの起源というのは実はわりと皆さんの身近なもので、Web検索、GoogleのWeb検索エンジンです。GoogleがWebの検索システムを作ったときは画期的で、そのおかげで一流企業になってるんですけど、当時は誰も考えつかなかった方法を採用しました。具体的には、プログラムが大量のWebページを自動で収集して、解析してインデックス化しているんです。こんなやり方は絶対に手に負えない、実現できないと思っていたら、非常に簡単でシンプルな、だけど強引な超並列分散の処理で、実現してしまったのです。要はWebページの重要度とかを、Webページのリンク構造を解析したり、中身を解析することで数値化して、インデックスにしちゃったわけです。

なので、検索はこのインデックス、つまりデータベースを管理しているサーバにクエリを投げて、クエリに対応するインデックスのエントリーが返ってくるっていうシンプルな仕掛けになっているので、0.1秒で検索結果が返ってくるということを実現できたわけですね。

これって実は本当にすごい技術で、この強引な超並列分散処理、今数十万台と言われていますが、その並列分散処理をするところにGoogleは力を注いだんです。そして、この成果を別のものに使えないかっていうので出てきたのが実はHadoopなんですね。

つまり、このWeb検索の強引な並列分散処理の技術を、検索アルゴリズムの方ではなく、プラットホーム、システムのアーキテクチャー自体を他の用途に再利用して、超大規模なデータの分散処理をしようと提案されたのがHadoopです。

HDFSとMapReduceの特徴

HadoopはMapReduceとHDFS、Hadoopの分散ファイルシステムの2つからになります。MapReduceがプログラミングモデルで、HDFSのほうは分散ファイルシステムです。

HDFSはシンプルで、特に何がすごいわけじゃないんですけど、ネームノードという管理ノードがデータをどこに配置するかとか、あるデータノードが消えたらそれがもつデータをどういうふうに移動するかっていうのを決めてます。データは、データノードに蓄えられています。

データ自体はデフォルトで64MBで、デフォルトで3つで別のノードに対してコピーを作ります。こうすることで、コピーがあるので1個壊れても大丈夫ですし、1つのデータを並列処理することができるようになります。

ここで、たくさんのコピーを作っているので、上書きなし、つまり更新しないことが前提になっています。こうしないと、更新があったら全部のコピーのバージョンを管理しないといけないので、大変なわけです。そのためHDFSでは、データは追加するだけというふうに限定して、データをまとめて解析するために高速に呼び出すことだけに力を入れた構造になっているわけです。

クライアントがネームノードに対して、どのデータがどこにありますかっていうのを聞いて、後はデータノード、データを持っている人と直接やりとりするっていう形になってます。

一方、MapReduceはそういうデータを並列分散処理をする枠組みです。まずはすごくシンプルにデータを小さなタスクに分割するためにデータ自体も分割する、その分割したデータをタスクに割り当てる、つまり、そのデータをもっているノードのところにタスクを割り当てて処理します。そして、この中間結果を今度はReduce処理します。Mapっていうのはタスクとかデータをマッピングするという意味で、Reduceは出てきた中間結果をリデュース、つまり減らして最終結果を得るというような意味です。

例を示すと、こんな感じですね。ある大量文書内で、その文書の中で地名がどのくらい出てくるかカウントするような処理はよくあるんですけども、そういうカウント処理を、データの分割を決めて、それぞれのサーバでどんどんカウントをしていく。

その後のReduceの処理では、例えば「あ行」は「サーバQ」ですとか、「さ行」は「サーバR」ですみたいなことを決めると、Map処理を行った各サーバから中間結果を、それぞれ該当する「あ行」とか「さ行」とかを担当してるサーバに対して送って、結果をカウント、集約するということをやっています。非常にシンプルですよね。

要はデータとタスクを分割する、中間結果をまとめるっていうようなフレームワークになっていて、非常にシンプルで特にすごくない。単純なタスクをとにかく超並列分散をすることのみを考慮して設計されたアーキテクチャーなんです。

関係データベースの3つの利点

次に、Hadoopの問題点を話す前にNoSQLの話をします。NoSQL自体も出所はもちろん、関係データベースじゃだめだとか、パフォーマンスがでないというところから始まってるんですが、関係データベースには、皆さん授業で習った通り、3つの大きな利点があるんです。

1つ目、スキーマ定義がしっかりしている。始めに、表の構造をしっかり定義することで、みんながその構造をベースにして、例えば表と属性名を指定して簡単にSQLでアクセスできるという特徴があります。次に、表を複数に分割して、共通の属性で結合処理をすることでサイズの大きなデータ空間とかも間接的に表現できるし、その上で無駄とか情報欠損とか一切なく、超エレガントな数学に基づいて対象を表現できるという利点があります。

あとはそのデータベースのエンジンとして、処理の整合性やトランザクションの管理だったり、複製間の一貫性、バージョン管理っていうのが綺麗に保障される。ただ、実はこれら3つの利点は、ビッグデータでは全然だめなことが多いんです。

まず問題1。とにかく色々なところから情報が発生していて、データをかき集めて処理するのにはじめに枠組みを決めとけって無理ですよね。このせいで、まず関係データベースは使えないってことになるんです。要はスキーマなんて最初に決められるわけないじゃないですか。

次は結合処理。授業で習った結合処理を思いだしてもらいたいんですけども、表が複数あって、共通属性を指定すると、その値が一緒なものをマージして、大きな意味のある表を再現するっていう処理です。でも、この処理ってそれめちゃくちゃ重いんですよ。

当たり前ですけど、1個1個のエントリーを比べて、結合して、また別の表を作るので、とてつもなく重いわけです。なのでどうするかっていうと、ビッグデータの表は正規化なんてしないんです。

正規化して複数の表に分けると、ややこしくて時間がかかるだけでしょうがないので、1個の大きな表を作っちゃって、結合処理をしないということをするわけです。

3つ目の一貫性の保障ですね。これもビッグデータでは好まれないです。とにかく色々なデータがあって、コピーとかも色々なところに分散してるのに、コピーの一貫性をきっちり管理するとか、トランザクション単位でしっかりと処理を実行すること自体のコントロール、これをマネージメントする負荷が大きくて話にならないということがあるので、これもやりたくない。

というので、実は関係データベースの利点というか狙ったところ全部が否定されているということが起きているわけです。だからこそNoSQLという名前がつけられたのでしょう。

NoSQLで1番有名なキーバリュー型

ビッグデータの運用ではNoSQLという名前で色々なデータベースが登場しています。例えば、キーバリュー型、これが一番有名です。

キーというものとデータを、一緒くたにバリューっていう形で扱います。つまり、大きなデータをバリューとして、構造自体を無視する。なので構造がないので、前出の問題を色々と解消できます。ただもちろん構造がないので構造を意識した処理はできない。

ここが面白いところですが、ここからだんだんやっぱりデータベースに近づいてくるんですね。ここから出てきたのが列指向型。キーバリュー型はちょっと使えないぞっていうアプリケーションが出てきて、列の集合くらい使えるようにしようっていうのが列指向型です。列自体は自由に定義できるので、関係データベースのスキーマよりはゆるいんだけど、属性を指定したデータアクセスみたいなものはできるわけです。

さらにキーとバリューみたいにまとめたら、せっかくXMLで書いたのにXMLの問合せ言語だったり、処理系は使えないじゃないということで、ドキュメントはドキュメントの元になっている言語とかの機能をちゃんと使えるようにしようっていうのがドキュメント指向型です。

あとちょっと志向が違うのですが、キーとバリューみたいなものをまとめたデータ、これをエンティティと言うんですけども、このデータ間の関連性をダイレクトにグラフのエッジとして定義することで、色々なソーシャルネットワーク内のユーザーの関係性の解析だったりとか、自然言語処理の構文解析みたいなことに使えるだろうというので、でてきたのがグラフ指向型です。

NoSQL、Hadoop、MapReduceはデータベース研究者からしたら、ある意味邪道

こういうふうにNoSQL、Hadoop、MapReduceが開発されてきたんですけども、流れとして今次のようなことが起きているんですね。現場のデータ解析者からすると古典的なデータベース技術はビッグデータの解析には使えないな、というのから始まって、データベース研究者からしてもしょうがない、実際にパフォーマンスも出ないねっていうので納得していたんですけども、そこでMapReduce、NoSQLが出てきたわけです。はじめはデータ解析技術者は、みんな浮かれて、こういうシンプルなのいいよねって。

一方で、データベース研究者の多くは、こういうのはデータベース的には邪道なんだけど確かにパフォーマンス出るし利にはかなってるよねっていう感じでした。しかも、この裏で将来起こることを予測して、今後起こりうる問題を解決するような技術を粛々と開発していくわけです。

例えば、このデータ解析者が信頼性のあるデータ処理だったり、一貫性が欲しいなとか、解析結果を再利用したいとか、いろんな高度なことをやりたいなと思ったときに、データベース研究者は温めておいた自分の技術を使って、ここで連携していく。データベースの分野っていうのは実はこういうことがいろんなところで起きているのです。

話を戻して最近の流行ですけども、MapReduceやNoSQLに、今言ったようなデータベースの技術、つまりSQLの処理、インデックスだったりとかトランザクション管理を入れていったり、あとクエリの応答時間の短縮だったりを拡張することが行われています。また、データの途中結果の監視です。これは、データ解析自体に長い時間がかかるので、トランザクションを小まめに分割してサンプリングしたりデータマイニングすることで、柔軟な実効制御ができるような仕組みを開発したりするなどです。

データベースは様々な研究分野の基盤になっている

課題2っていうのは、先程言っていたように、色々な複数のデータを横軸を通して統合的に解析できる技術をどうするかっていうので、自動的にメタデータを付与する技術などが開発されています。

課題3のエンド・ツー・エンドの処理に関して言いますと、生データから出てきた解析結果が人にはわかりにくいときどうするかっていうので、個々の解析結果を、ブロックを組み合わせるようにエンド・ツー・エンドでアプリケーションを組むような技術が注目されています。

これは図で説明するとすごくシンプルです。例えば加速度データの解析で人の動きがわかります。ソーシャルメディアの解析で人の意見がわかります。アプリのサービスログの解析で、アプリケーションの嗜好みたいなのがわかります。これまでは個々が全部こういうふうに解析されて、個別に利用されていたんですけども、これらを組み合わせることで、いろんな新しいことができます。例えば、人がどうして密集してるのか、その時にどういうアプリが使われるのかというのを統合的に色々なことがわかります。このような仕掛けを、ピースを組み合わせるような形で実行しようというのが課題で、新たな研究分野として流行ってます。そのための連携技術をどう開発するかっていうのが問題になるわけです。

あと、それらをクラウドに持ってくると、さらに話がおもしろくなります。例えば今言っていたような、解析器だったりデータですね、これら自体がいろいろなクラウドに任されることを想像してください。つまり、データセンターにばらばらに置かれたり、解析自体を別々のクラウドでやったりみたいなことが起こると、何が起こるか想像つきますよね。

さっきのデータの流れとか、処理の流れみたいなのが、クラウド間、つまり別々のシステム間で連携しないといけない。ここで何が難しくなるかっていうと、複数のサーバにデータをどう配置するのかとか、処理をどうするか、どうチューニングするのかとか、どういうふうにコントロールするかってことを考えないといけない。要はみんな個別にサービスを立ててるだけなのに、それを連携させる仕掛けをどういうふうにデータベースの技術を使って作るのかっていうところが今とても流行りつつあります。