データベース技術の今後の動向
本屋で偶然見かけた「7つのデータベース 7つの世界」を立ち読みしたら、とても面白かった。
また、Twitterで見つけた「データベース技術の羅針盤」というスライド資料がとても素晴らしかった。
リンクをメモしておく。
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のような古いバッチ処理の代替技術になりつつあるように思える。
歴史を振り返れば、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の物理構造を保守する管理者)、インフラエンジニア(基盤技術者)も開発チームには必要だ。
しかし、すべての技術がクラウドに乗って、その保守コストを劇的に下げることが出来れば、今まで必要だった役割がなくなり、開発チームに必要とされる役割はもっとシンプルになっていく。
むしろ、開発者に要求される技術が非常に広く深くなってくるとも言えるだろう。
ソフトウェア開発に必要な役割の数が減ったように見えるのは、あくまでも、重要度が低くなった役割の作業が減っただけなので、一人の開発者が複数の役割を担当できるようにならなくてはならないのだろう。
アジャイル開発では、単能工よりも多能工を重視するけれども、上記の技術の流れによる役割の変化も、その流れに同一視できるかもしれない。
| 固定リンク
「モデリング」カテゴリの記事
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか?~Software Processes are Software, Too(ソフトウェアプロセスもまたソフトウェアである)(2024.09.22)
- 「システム開発・刷新のためのデータモデル大全」を読み直した感想~親子頻出アンチパターンは初心者モデラーに多い(2024.08.31)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「システムアーキテクチャ構築の原理」の感想(2024.05.06)
「ソフトウェア」カテゴリの記事
- 「RedmineのUbuntu+Docker構築への移行」の感想 #redmineT(2024.11.24)
- Javaのモジュールシステムの考え方をまとめてみた(2022.10.21)
- Javaのenum型はシングルトンクラスみたいだ(2022.06.20)
- テスラが従来の自動車メーカーと異なるところは工場までソフトウェア化すること(2022.02.09)
- 「RubyやRailsは終わった」という記事のリンク(2022.01.09)
「ソフトウェア工学」カテゴリの記事
- Jiraの機能はTracに似ている気がする #redmine(2025.06.01)
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか?~Software Processes are Software, Too(ソフトウェアプロセスもまたソフトウェアである)(2024.09.22)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
コメント