データ管理に RDBMS やハッシュテーブル，その他どのような機構を使っていたとしても，NoSQL や BigData について耳にしたことが一度や二度はあるはずだ。Google や Yahoo，Amazon といった企業はすべて，BigData/NoSQL ソリューションを利用して開発を行っている。しかしこのような非常に特殊なユースケース以外でも，これらの実装は本当に汎用的に利用可能なのだろうか？ Cap Gemini の Steve Jones 氏は 先日の記事で，Big Data は実は Big Con (大嘘) かも知れない，少なくとも一部で信じられているような，レガシーな RDBMS 実装に対する万能な解決策ではあり得ない，と断じている。
たくさんの 'Big Data' が波のうねりとなって市場に押し寄せています。一部の企業では，この爆発的なデータ増加を歴史の継続であるとして，新技術ないしは新たなアプローチであることは認めても，それは進化 (evolution) であって革新 (revolution) ではない，と評価しています。確かに Map Reduce はクールではありますが，SQL やデータベース設計に比べると技術的な難易度がはるかに高く，ビジネスにおいて万能の解決策というにはほど遠いのです。
氏はさらに，(RDBMS ベースの) インメモリデータベースが近い将来，データセットとサイズの面で現実的な選択肢となるだろう，という指摘をしている。これについて氏は，Yahoo が２ペタバイトのデータを格納するために，大幅な改造を施した Postgres を使用している (いた？) という，数年前の記事を引き合いに出して説明する。
Big Data のポイントはここです。つまり 95% 以上は理能力やストレージ容量の増加に伴う，あるいは少なくともそれらが追随する，データの継続的かつ指数関数的な増加に関するものなのです。[...] 確かにインデックスのチューニングは困難になりますし，データを SSD に移動するような方策が必要になるかも知れません。しかし事実として，それらはデータの '肥大化' なのであって，根本的な変化ではありません。
以前にも Mike Stonebreaker 氏などから，これとよく似た話を聞いたことがある。多くのユーザが RDBMS の再設計やカラムストアなどの恩恵を受け，潤沢なメインメモリと SSD を活用することによって，従来の強い一貫性と ACID セマンティックス，さらには SQL が利用され続けるだろう，という指摘だった。しかし Steve はここでもう一度，Map Reduce に話を戻している。この実装の背景にあるモデルにはデータ保存や問い合わせ，操作方法などの面で，これまでと違う考え方が必要であることを事実として認め，それがユーザにとって，この新技術を既存の IT 投資に取り込む上での障壁となっている点を指摘している。
マルチスレッド的思考のできる人が少ないのと同じように，Map Reduce 的にものごとを考えられる人の数も多くないのです。
だとすれば，新しいシステムやソリューションの採用を働きかけてくるベンダたちの話題が絶えない現在の状況において，これが Big Data にどのように影響するのだろう？ Steve の意見を見てみよう。
私たちは Big Data を SOA と同じよう扱う人たち，ロゴに飛びついて 'Hadoop 統合' やら 'ソーシャルメディアインテグレーション' やら ... 別の言い方ならば ... 'コネクタを構築しました' などと称する人たちを見てきました。振り返ってみると，何と浅はかなことでしょう。まさに，古びた EAI コネクタを新しいソースへ，あるいは新しい ETL コネクタへ ...
十把一絡げ，という感も多少あるが，その中に真実の芽吹きもありはしないだろうか？ 当面の作業に適さないような実装に対して，NoSQL/Big Data というレッテルを貼った誇大宣伝やベンダのあまりにも多い存在が，"新しいデータソリューション" という要件の背後にあるコアメッセージを見失わせるリスクになりはしないだろうか？ Steve が指摘するように，SOA とはほど遠いソリューションに対してベンダが SOA のレッテルを貼っていた，初期のSOA に状況は似ているかも知れない。しかし求めているものが Big Data ソリューションなのか，あるいは (Steve の言う) Big Con を掴まされようとしているのか，どうすれば正確に把握できるだろう？ 親切にも Steve は，少なくともベンダの提供するソリューションの評価が可能な方法をいくつか提案してくれている。次のようなものだ。
- ‘Big Data’ というフレーズを ‘Big Database’ に置き換えられるならば，アップグレードするべきである。
- '進歩' という目標は 'EAI コネクタの獲得' のような現実に還元可能か？
- 基本的には 2009 年のものに Big Data/NoSQL というラベルを付けただけの製品か？
- データのシフトよりも，むしろプロセスをデータに移行するものが存在するか？ これは Jim Grey 氏などが，これまで何度も指摘してきたものだ。
残念ながら，これらの "ルール" はいずれも科学的ではなく，ある一定レベルの主観性を必要とする。これら以外の適当な判定方法があるだろうか？ 読者が従来の RDBS から別のものに移行中であれば，その移行を必要と判断した理由は何だろう，そして，マイグレードする対象はどのように選んだのだろう？ 移行は成功したのだろうか，そうでないなら，それは何故か？