「リレーショナルデータベースはもうおしまいだ」
――Teradataとしては、非構造化データの分析ではHadoopを必須としているのか。
Brobst 必須というわけではない。Teradata Databaseでもできる。実際、大型のオブジェクトを保存して、非構造型のテキストや画像、音声をのせることはできる。だが、できることとうまくできることは別だと思っている。たとえば画像を保存して処理するというときに、SQLを活用するとしても、SQLは画像処理に適した言語ではない。できないことはないが、それが適した方法か考える必要がある。
（分散並列処理フレームワークの）「MapReduce」は非常に使いやすいし、クリーンなやり方だし、ファイルシステムに画像を保存できるし、分散型のファイルシステムを構築できるし、安いし、簡単だし、使いやすい。構造型データであればリレーショナルデータベースに付加価値を付けることができる。だが、非構造型データであるのならば、リレーショナルデータベースではない方がいいだろう。
この業界、みんながそれぞれ信じているものがある。その中には絶対SQLをやらないという人たちが存在する。「データベースはもうおしまいだ」「SQLはもうダメだ」「Hadoopこそが次世代のテクノロジーだ」というリレーショナルデータベース反対派だ。そうしたあるテクノロジーを信仰している人たちがいるが、思いこんではいけないと言いたい。
Teradataはテクノロジーに対する極端な思いこみをやらないようにしている。適切なスキルセットで適切なツールを活用すれば、簡単にデータを処理することが可能だ。つまり、HadoopとTeradataのデータウェアハウスをうまく組み合わせることが重要だ。決して「こっちのテクノロジーこそが……」という思いこみはしないようにしている。そうした考え方がユーザー企業にとってメリットを提供できることになる。
Teradataの研究開発では、インテグレーションをいかにしてうまくできるか、に焦点を当てている。たとえば、Teradataのリレーショナルデータベース基盤とHadoopをいかにうまくインテグレーションできるかとということだ。Hadoopのような分散型のデータシステムに対して、いかにしてアクセスの性能を上げるか、Teradataのデータベースの機能を活用するにはどのようにしたらいいのかを考慮している。
MapReduceは、（それぞれの検索プロセスに対してハードウェアリソースやデータが論理的に分散されている構造の）シェアードナッシングのプログラミングモデルを使っていて、Teradata製品のアーキテクチャにとてもよくフィットする。そこで、Teradata DatabaseとHadoopのような分散型ファイルシステムとの相互運用性や統合性をスムーズにすることにわれわれはフォーカスしている。
