前回、ハナちゃんから「『ビッグデータ』とは、他の普通のデータと同じ処理方式では扱いきれないデータのこと」と聞き、少しビッグデータのことがわかりかけてきたまさこさん。でも今度は、新しい疑問が湧いてきたようです。

データの特性よりも大切なコト

ハナちゃん、為替データやTwitterフィードみたいなデータがRDBで扱いきれないって言ったけど、Twitterはともかく為替データなんて昔からあるデータじゃない？ 同じ考え方でいくとPOSデータや荷物配送データなんかもそうだし、HTTPのアクセスログも同じようなデータよね。

さすがまさこさん。目の付け所がイイですネ。

お、おい、俺のExcel無視すんなよお！

データの処理方式を考えるとき、データの特性よりも大事なことってなんだと思いまスか? さっき星先輩がいいこと言ってましたヨ。

お、俺? 俺のボロPCのこと?

何だろう、「経営者が喜びそうなやつ」とか言ってたこと?

そうでスね。いくら大量のデータがあっても、目的が無いといわゆる”ディスクの肥やし”。「どう使いたいか」があって初めて、「どうやって使うか」が決まるんでスよ。その目的の1つが、期間ごとの売上集計や在庫変動の傾向調査、経営指標となるKPIの算出になることは多いですネ。実際にその数字を出すための費用対効果はさておきデスが。

そう言えば昔、データウェアハウス（DWH）の導入をやったことあるぜ。経営企画で半年くらい使ってたようだけど、こっそり「保守の更新止めてくれ」って言ってきてたから、元が取れたかどうかは聞くまでもないけどな。

そう。DWHも通常の仕組みでは実現は難しいですね。DWHでは、大量のデータを多次元からスムーズに集計操作するために、「CUBE」というインデックスの塊を生成しておくんでス。15年前くらいに導入が流行りましたが、当時としてはいわゆる「革新的な処理方式」でシタ。

「当時としては」ってことは、今は違うのね。

今の「革新的な処理方式」は、GoogleのMapReduceの登場とHadoopによる実用化から劇的に進化したんでス。「データは必ずしも同期的に処理しなくてもいい」ってことと、「目的別に処理方式を変えればいい」ってことに業界が気づいたんでス。いわゆる分散処理系のNoSQL製品が大量に出てきたのも、この流れでスね。2010年くらいの話でス。

なるほど。私が出向したのが2011年の春だから、その時期から出てきたIT用語の知識が空っぽなのよ。だからずっとITに関わってる星先輩に聞いてるのに、いつもテキトーなんだから。

……何も言えねえ。

まあまあ、落ち着いてくだサイ。別の観点から言えば、サーバ・ハードウェアの進化のおかげで、今までネックだったメモリとCPUが安くなって、「インメモリDB」や「カラム指向DB」が登場してきたことが挙げられマス。さらにNoSQLやインメモリ、カラム指向の技術をRDBが吸収して、再度RDBへの回帰も始まっているようデス。簡単にまとめるとこんな感じの図になりマスかネー。

わお、こんなにあるの！？

これは今思いついたものを描いただけデスから、ホントはもっとたくさんありマスヨ？ 他のも気になるなら、後で”database landscape”ってキーワードで検索してみてくだサイ。

（ハナちゃん、すげえ……）

私がいた頃は、それこそシステムを開発するならOracleとSQL Serverしかなくて、無料のDBを使うならMSDEかMySQLかなー、って言ってたような気がする。

そうなんでス。売上データや、契約なんかの業務で使うデータは昔から量が増えたわけじゃないんでスが、世の中全体が当時より格段にインターネットに依存する社会になって、インターネット上で生まれるデータが爆発的に増えたんでスね。それとともに、サイトやアプリは「快適に使えてあたりまえ」になってしまったんでス。例えば、ECサイトで商品検索して5秒待てないでスよね。

5秒待たされたら、サーバが落ちてるんじゃないの? って思うなあ。もしそんなサイトがあったら、二度と使わないかも。

デスよネ。元データがどんなに大きくても、検索したら一瞬で結果が返ることが当たり前になってるんでスよね。さっきの「売上集計」とともに、「高速な検索」や「顧客のサイト上の行動特性の把握」なんかもデータ処理の目的になってきた、って考えるようにするとわかりやすいでスよ。

なるほどね。目的別に製品が用意されているから、あんなにたくさんDBの種類が生まれてきたんだ! 私はずっと「システムにはDBが1個」で、「システム構成図のいちばん下におっきなドラム缶が書いてある」って思ってたけど、もうそんな時代じゃないんだね！

もちろん、DBが1個のシステムもたくさんありまスよ。でも多少データ量の多いシステムなら、検索はDBにクエリを投げるんじゃなくて、事前に検索エンジンのバッチ処理で結果データを作っておく、って方式も併用できマス。データ特性によっては、集計のバッチ処理をHadoopで並列実行して、処理時間を劇的に短縮したりできるようになりましタ。

おっけー、わかった! 要するに「ビッグデータ」って、「たっぷりデータがある」ってだけじゃなくて、「そのデータで何がしたいのか」ってとこまで考えなきゃダメってことだな！

で、その「したいこと」を「普通のRDBに入れておいても重すぎて処理しきれない」か「RDB向きじゃない」ときに、NoSQLとかHadoopみたいな他のDBの併用も検討してね、ってことね。

そのとおりでス! 「ビッグデータ」っていう決まったソリューションがあるわけではなくて、「大量に発生するデータを扱うソリューションの選択肢が増えた」って理解しておいてくださいネ。

しかも、その「大量」っていうのも時代によって変わるわけね。きっとうちの会社の取引データなんて、「今どきの普通のRDB」で快適に操作できちゃうような気がする！ ハナちゃん、ありがと! さっそくベンダーさんと話してくる！

「Excelで扱いきれなくなったらビッグデータ」という俺の仮説も、いちおう正しかったってことだ。

そうね。先輩と同じで、30年モノのビッグデータ”さん”と言えなくもないかな。

俺、そんなにキャリア長くないんですけどー。