データベース技術の今後の動向

本屋で偶然見かけた「7つのデータベース 7つの世界」を立ち読みしたら、とても面白かった。
また、Twitterで見つけた「データベース技術の羅針盤」というスライド資料がとても素晴らしかった。
リンクをメモしておく。

Twitter / matsunobu: 昨日のDB Tech Showcaseで話した「データベース技術の羅針盤」の資料を公開しました #dbts2013 http://www.slideshare.net/matsunobu/ss-28303485 …

Twitter / g3akk: 現在Facebookで活躍されているMySQLスペシャリストの松信さん @matsunobu によるすばらしい資料→http://slidesha.re/1bEqr4u 衰退する技術にdedicateすることがいかに無駄か、これはデータベース技術者に限ったことではないとおもう。公開に感謝

Twitter / zyunnosuke:Facebookで働かれているMySQLエンジニアの松信さんが日本で11/15に発表されたスライド。俯瞰的な資料がまた素晴らしい！
データベース技術の羅針盤 http://ow.ly/qSJaR

Twitter / ezmscrap: DBの話だけでなく、エンジニアのキャリアの話が面白い。面白いが、先を見るのは難しい。例えば、私はXMLDB技術に詳しいという黒歴史がある。やってる時は役に立つ、広まると思ったんだけどねーw 「データベース技術の羅針盤 http://htn.to/4cYddK

データベース技術の羅針盤 from Yoshinori Matsunobu

7つのデータベース 7つの世界｜Ohmsha

DBと言えば、RDBを思い出すのが普通だが、最近はNoSQLのように、リレーショナルでないデータベースが雨後の筍のように出ている。
NoSQLについて僕は全く理解していないけれど、「7つのデータベース 7つの世界」では、次の7つのデータベースについて解説してくれているので、初心者には分かりやすい。

PostgreSQL : リレーショナルデータベース
Riak : キーバリューデータベース
HBase : カラム指向データベース
MongoDB : ドキュメント指向データベース
CouchDB : ドキュメント指向データベース
Neo4J : グラフ指向データベース
Redis : キーバリューデータベース

書籍「7つのデータベース 7つの世界」のご紹介 (コーソル DatabaseエンジニアのBlog)

何故、NoSQLが注目されるのか？
RDBだけでは解決できない問題領域において、NoSQLが役立つという状況があるからだろう。
そして、最近、「ビッグデータ」「データサイエンティスト」のようなバズワードが巷に出てきて、世の中の大量データからいかに意味あるデータを抽出すべきか、という問題が注目されているからだろう。

最近なら例えば、JR東日本がSuica利用データを、顧客の同意なしにビッグデータとして加工して販売して新聞に載った。
どの駅にどの時間帯にどんな傾向の人が乗降するのか、というデータは、住宅販売や小売業などのユーザに販売すれば非常に役立つだろう。

NoSQLの全貌は理解できていないけれど、個人的な興味を惹く内容は、MapReduceとの相性と、クラウドとの相性だ。

前者については、RiakやHBaseでは、MapReduceを使って、大量データを処理することができる。
特に、HBaseはHadoopでも使われている。
個人的には、HadoopがCobolのような古いバッチ処理の代替技術になりつつあるように思える。

基幹系バッチ処理をHadoopで高速化: プログラマの思索

歴史を振り返れば、RDBよりも以前は、固定長のテキストファイルをこねくり回すCobolのバッチ処理がエンタープライズ系では主流だった。
そして、今もなおCobolは生き残り続けている。
NoSQLはCobolの代わりに、固定長のテキストファイルの代わりに独自のデータ形式で情報を保持し、高速または大量に処理できるような仕組みとも言える。
つまり、NoSQLは、RDBがCobolを乗り越えようとした歴史の先祖返りと見なしてもいいかもしれない。

後者については、NoSQLはクラウドとも相性が良い。
「7つのデータベース 7つの世界」では、HBaseをクラウドに持っていく方法についても解説している。

最近では、業務系基幹システムのバッチ処理をHadoopでリプレースし、さらにクラウド上で動かす記事があった。

「オンプレミス・システムの終わり」の始まり～AWSでのミッションクリティカルシステムの稼働 - 急がば回れ、選ぶなら近道

NoSQLやHadoopの事例はWebシステムの大量データの処理しか今までなかったけれども、業務系基幹システムのバッチ処理にも同様に適用できる。
今まで、月次や年次の会計処理や、製造業における部品の所要量計算はバッチ処理で翌朝にならなければ出力されなかったが、Hadoopを使えば、1日数回実施できるので、あたかもリアルタイム処理のように扱える。
1日1回の結果が1日数回出力できるならば、在庫を減らしたり、会計報告書を見るサイクルを早めることで、経営判断を強力に支援することができる。

さらに、クラウドに業務系のバッチ処理が乗れば、サーバーのリプレースも関係なくなる利点もある。
オンプレミスではハードウェア障害として、HDD障害が非常に多いけれど、そんな障害対応からもインフラエンジニアは開放される。
何よりも、データ量の増加速度に応じて、スケールアップしやすい点もクラウドの良い点だ。

データベース技術の羅針盤の資料を読むと、そのようなデータベース技術の進化によって、DA(データ管理者)やDBA(データベース管理者)、インフラエンジニアが不要になり、コストを削減できる点も指摘している。
特に、クラウド上にバッチ処理もフロント側Webシステムも乗ってしまうと、従来必要であったDBAやインフラエンジニアの重要性は低くなる。

そんな歴史の進化を見ると、ソフトウェア技術の進化とは、ソフトウェア開発チームにおける数多くの役割を収斂させることだと言えるのではないだろうか。

「組織パターン」や「XPエクストリーム・プログラミング入門」を読み直すと、ソフトウェア開発チームにたくさんの役割が必要だった。
例えば、プロジェクトマネージャ、テスター、品質管理者(QA)、ドキュメントライター、トラッカ(XP)、など数多くの役割が出てくる。
もちろん、DA(データの論理構造を決める管理者)、DBA(DBの物理構造を保守する管理者)、インフラエンジニア(基盤技術者)も開発チームには必要だ。

しかし、すべての技術がクラウドに乗って、その保守コストを劇的に下げることが出来れば、今まで必要だった役割がなくなり、開発チームに必要とされる役割はもっとシンプルになっていく。
むしろ、開発者に要求される技術が非常に広く深くなってくるとも言えるだろう。
ソフトウェア開発に必要な役割の数が減ったように見えるのは、あくまでも、重要度が低くなった役割の作業が減っただけなので、一人の開発者が複数の役割を担当できるようにならなくてはならないのだろう。

アジャイル開発では、単能工よりも多能工を重視するけれども、上記の技術の流れによる役割の変化も、その流れに同一視できるかもしれない。