エンジニアにとっては、基本的な技術要素について、その活用の仕方を実践的に学ぶとともに、その技術の歴史や実用化された目的、思想についての理解を深めることが大切です。
この記事では、エンジニアであれば誰もが知っているであろう「データベース」という技術要素について、深く考えてみたいと思います。
なぜ「データベース」が必要か
コンピュータの基礎理論では、コンピュータに対してインプットデータを与えると、予め準備されていたロジックに従ってコンピュータが演算を行い、コンピュータはアウトプットデータを出力する、と考えます。
この時、複雑な演算であると一連の処理のためにデータを大量にコンピュータ内部に持っていなければいけないために、CPUの周りのレジスタ、メモリ、ハードディスク等に演算に必要なデータを保存する必要があるとされます。
しかし、この一連の説明の中に、「データベース」という概念は登場しません。何故でしょう？
極論を言うと、コンピュータが動作するのに、必ずしもデータベースは必要ないのです。
コンピュータに演算をさせる度に、コンピュータにインプットデータを与え、ロジックに従って都度コンピュータに演算をさせることで、アウトプットを得ればよいのです。
そして演算が終われば、演算に必要であったデータは消去してしまうことも理屈の上では可能です。
とはいえ、現実今日のコンピューティングシステムでは、ほぼ例外なく「データベース」が存在します。
言い換えますと、演算の都度、コンピュータ外部から得られるインプットデータのみを使うのではなく、コンピュータ内部の「データベース」に蓄積してあるデータもまたインプットデータとして用いています。
(演算された結果は、アウトプットとしてコンピュータ外部に出力されるだけでなく、「データベース」に書き込まれることになります。)
それは、データベースをコンピュータ内部に持つことにより次の効用があるからです。
演算の度にコンピュータに投入されるデータは、これをためていくとそれ自体として価値を持ちます。
それは、類似の演算の際に改めてコンピュータ外からのインプットを得ずに済むという意味合いもあります。
また、コンピュータ内部に蓄積されたデータベースのデータを参照することで、何らかのインサイト(洞察)を得られる可能性が出てくることもデータ蓄積の効用です。
「データベース上のデータを演算の際に参照する」という目的を追求すると、データベースは多数のアプリケーションから参照可能な(どのアプリケーションに対しても中立な)形式で作られることが望ましいということになります。
皆さんが簡単な練習用のプログラムを組んで、そのプログラムに対してインプットデータを与えるとき、おそらくデータのインプット形式はプログラム(ロジック)に沿った形になっていると思います。
例えば、「男の場合は1, 女の場合には2をポップアップ画面のフォームに入力する。」という設計にしていれば、コンピュータに対して与えられるインプットデータは「1」か「2」になります。
インプットされるデータは、ロジックが「1は男と、2は女として処理する」、というロジックを前提にしているからです。
しかし、個々のアプリケーションにたいして中立なインプットとしては、「男」や「女」という情報こそふさわしいのです。
なぜなら、他のアプリケーションは、男に「1」、女に「2」という符号を割り振っているとは限らないからです。
そこで、どのアプリケーションでもこの性別情報を利用することができるように、個々のアプリケーションとは別にDBMS(データベースマネジメントシステム)が、出来上がったのです。
データベースの歴史―階層型データベースの時代―
コンピュータが「汎用機」「メインフレーム」等といわれ、ソフトウェア・ハードウェア・ストレージが一つの筐体(箱)にまとまっていたころ、つまりサーバ・クライアント構成が登場する前の時代、最初コンピュータはデータをファイルとして保存していました。
しかし、これだと保存されているデータの参照が非常に面倒になります。
そこで、取り込んだファイルをファイルの集合とは別の「データベース」に格納するようになりました。
とはいえ、メインフレーム(汎用機時代)に主流だったのは「構造型データベース」というもので、後述する「リレーショナルデータベース」とは全く質を異にするものでした。
下図を参照ください。
この表は、あるSI企業の社員管理システムを念頭において作った階層型データベースの組織図です。
例えば、人事部の職員に関するデータは、あたかもフォルダを開いていくかのように、「社員」→「バックオフィス」→「人事」という具合に参照する領域をソースに書くことで、呼び出すことができます。
【無料あり】エンジニアが解説！プログラミングスクールおすすめ５選階層型データベースの長所
階層型データベースの長所は、比較的少ないデータ処理量で効率的にプログラムが呼び出したいデータにアクセスできる点にあります。
というのも、必要なデータにたどり着く経路は1つしかありえないので、データを探すための処理をする必要がないのです。
ハードウェアの処理能力が低い時代、この長所は非常に重要でした。
階層型データベースの短所
逆に短所としては、プログラムを作る際に、プログラマが上図のようなデータベースの階層構造を頭に入れたうえで、その構造に従ったコードを書かなければいけないので、データの呼び出しのロジックを変えるにはソフトウェアのコードまで書き換えなければいけないなど、非常に手間を取ることです。
リレーショナルデータベースであればSQLのSelect文のWhere句を書き換えることで簡単にデータの取得条件が変更できるのと比較すると、その不便さが理解いただけると思います。
また、より実際的な理由として、メインフレームの製造は当時のIBM社が極めて高いシェアを誇っており、そのIBM社が階層型データベースの利用に固執したために、実際上それ以外のデータベースが広まりにくかったことが指摘できます。
階層型データベースの問題点として、あるデータが複数の場所に生まれてしまうことが認められていました。
上図でいうと、「製造業担当のコンサルタント」でかつ「長期の他社出向者」である社員のデータは、上の構造の中で2か所生まれてしまうことになります。
同じ属性を持つデータが複数あるとデータベースの中で矛盾が生じ得るので、好ましいことではありません。
この問題を解決するため、親：子＝1：多とする階層型データベースではなく、親：子＝多：多とするネットワーク型データベースも登場したのですが、IBM製品の壁に阻まれてあまり普及しませんでした。
データベースの現在とこれから―リレーショナルデータベースとNoSQLデータベース―
「リレーショナルデータベース」とは、皆さんが普通「データベース」の扱い方として勉強する類のデータベースです。
リレーショナルデータベースの特徴は、複数の表形式のデータ(テーブル)からなり、複数のテーブルをテーブル間で共有するキー項目(Foreign Key)によって結びつけることによって、色々の情報を整理する点にあります
さて、既述した階層型データベースからリレーショナルデータベースへの移行が本格的に始まったのは、1980年代末から1990年代初頭にかけてです。
実は、IBMはリレーショナルデータベースをIBM DB2として1983年に製品化したのですが、あまり普及を見ませんでした。
その理由は、当時のハードウェアの性能水準が、リレーショナルデータベースを大企業で実用運用するほどに高くなかったからです。
既述したように、構造型データベースでは、予めプログラムにデータを呼び出すロジックを書き込んでおき、それを変更することは基本的にありませんので、処理速度が速くなります。
しかし、リレーショナルデータベースではSQLの発行によって都度データを呼び出すロジックを変えますので、ハードウェアにデータ検索の負荷をかけてしまいます。
その結果、処理速度が遅くなってしまったために、特に大企業の定型業務を処理する基幹系システムでは、リレーショナルデータベースの普及は進みませんでした。
しかし、1990年前後に、状況は変化します。
この頃になると、基幹系システムのデータ呼び出しロジックを変えるのに、いちいちプログラムを修正しなくてはならない保守コストの高さ、そしてメインフレーム市場をほぼ独占していたIBMへの過度な依存が問題視されるようになり、ハードウェアの処理速度の向上やネットワーク回線の高速化を背景に、多数の小型のパーソナルコンピュータ端末をネットワークでつなぎ、少数のサーバ端末に主な機能を担わせて多数のクライアント端末にアプリケーションを利用させるサーバ=クライアントシステムの導入が急激に進みました。
このIBMの汎用機から解放されたユーザは、当時リレーショナルデータベースのDBMS(DataBase Management System)を売り出していた新興のOracle社等のDBミドルウェアをこぞって導入し始めたのです。
この頃にはハードウェアの性能も向上しており、一般的な企業の基幹システムに求められる情報処理量であれば、都度データを抽出するリレーショナルデータベースでも運用に耐えうるようになりました。
他方、尚も超大量・超高速のデータ処理が要求される学術用・軍事用コンピュータや銀行の勘定系システムなどでは、今日でもメインフレームで構造化データベースの活躍領域が残されています。
リレーショナルデータベースは、ACID特性と呼ばれる特徴を有していた点で、大企業のエンタープライズシステムとの親和性を持っています。
以下で解説します。
リレーショナルデータベースの特徴 Atomicity(原子性)
まず、Atomicity(原子性)は、トランザクション(データの一塊の処理)について、これが完全に終了するか、全く行われないかのいずれかであることを保証します。
これによって、例えば「ある商品が拠点Aから拠点Bに入庫された」というデータと、「ある商品はまだ拠点Aに残っている」というデータの矛盾が絶対に起きなくなります。
リレーショナルデータベースの特徴 Consistency(一貫性)
次に、Consistency(一貫性)は、「ある商品が拠点Aから拠点Bに入庫された」というデータと「ある商品はまだ拠点Aに残っている」というデータがの矛盾が生じた時には、必ずトランザクション処理が中断され、データは変更されないことが保障されるということです。
リレーショナルデータベースの特徴 Isolation(独立性)
Isolation(独立性)は、あるトランザクション中に行われる操作が、他のプロセスから隔離されて行われることを意味します。(※これは並列処理が不可能になるので、実務上部分的に緩和されます。)
リレーショナルデータベースの特徴 Durability(永続性)
Durability(永続性)は、トランザクションの操作が終了した(一度commitされた)あとは、決してそのデータ変更の結果は失われないことを言います。
大きな企業の基幹システムの規模はとても大きいのですが、顧客からの受注から、顧客への商品の引渡に至るまでに、データの矛盾があると正しく顧客にサービスを提供できなくなります。
また会計監査に耐えうるデータを持っていることができなくなります。そこで、ACID特性を保証するリレーショナルデータベースは広く利用されるようになりました。
ところが、このリレーショナルデータベースの圧倒的シェアは、主にビックデータの出現により部分的に脅かされつつあります。
いわゆるビッグデータとしては、大量の構造化されていない(レコード・カラムの形式で整理されていない、例えばツィッターのつぶやきのような)非構造データや、画像・動画等のリッチコンテンツが扱われます。
しかし、そのそも、リレーショナルデータベースは、テーブルの中にレコード・カラムとして整理できない情報を格納するつくりにはなっていないため、この種の非構造データやリッチコンテンツをどう扱っていいか、答えを提供できません。
また、ビックデータ時代に入ってデータベースに格納されるデータ容量がかつてなく多量になったわけですが、既述したACID特性を保証するために、一般的なリレーショナルデータベースではデータの一元管理をする必要上、従来は1つのサーバに1つのデータベースを割り当てることとし、1つのデータベースを複数のサーバに担わせることはしませんでした。
1つのサーバに1つのデータベースを割り当てる原則を維持したければ、データベースサーバのスペックをよくする(スケールアップ)する手段が考えられます。
しかし、スケールアップは比較的高コストとなりますし限界もあります。
ここで、1つのデータベースを複数のサーバに担わせる(スケールアウト)手段が考えられますが、既述したACID特性を維持する場合には、各サーバ間をネットワークで結んでデータベースの更新・追加を共有しなければいけません。
すると、結局サーバ間のネットワーク速度がボトルネックになって、結局データベースの性能が上がりません。
その為に、No SQLと呼ばれる新しいタイプのDBMSでは、ACID特性を厳密に維持することを放棄し、データ処理が終了した時のデータの整合性のみ保証するという設計思想の下に売り出されています。
具体的には、データベースサーバのスケールアウト(サーバを複数とする)際に、サーバ間の通信を放棄します。
そして、アプリケーションからデータベースへの操作要求があると、並列するデータベースサーバとアプリケーションの間にあるロードバランサが、その処理をどのデータベースサーバに振り分けるかを決定し、そのサーバに要求を処理させることになります。
この場合、ロードバランサが正しく処理を適当なサーバに振り分けられるか、また、各サーバの担うテーブル(あるいは領域)が、データベースの整合性の担保に役立つ形で分割されているか、といったことがポイントになってきます。
これからのデータベース技術の見通し
既述したとおり、リレーショナルデータベースのシェアは圧倒的であり、しかも大企業・公共機関のデータを決まった形式で矛盾なく処理するのに最適な構成になっています。
今、盛んにビックデータの活用が歌われており、ビックデータの処理(特に検索処理)にはリレーショナルデータベースはあまりに時間がかかると指摘されています。
No SQLが提唱されている一つの理由はここにあります。
しかし、私が思うに、ビッグデータの活用は、ビッグデータの処理を必要とするだけのハードウェア機器の諸性能の爆発的な向上が先にあって、「大量のデータが操作できるように」なり、現在は「この処理能力を活かして何ができるだろうか？」ということを世界中の企業や技術者が模索している段階だと思います。
もっと直接的に言えば、ビッグデータで何をできるようになるか、確かな答えが得られていないのです。
ですから、エンジニアは、目下リレーショナルデータベースに必要な技術に見切りをつけるのではなく、リレーショナルデータベースの改良の動向をフォローすべきだと思います。
まだ実用化の用途が見いだせていないビックデータ用のNo SQL対応よりも、クライアント企業が強く求めているのはデータベースサーバのスケールアウトによる性能向上ではないかと思います。
すでに、データベースサーバ以外のサーバは、仮想化やクラウド化の技術の導入により、短期間にサーバの立ち上げを可能にするスケールアウトが実用化されています。
現在のエンタープライズシステムで、性能向上のボトルネックになっているのがDBMSといわれていますので、データベースの性能向上への期待は大きいと思われます。
しかし、データベースサーバをスケールアウトしようとすると、これまで自明の前提とされてきたデータベースのACID制約の一部を緩和する必要が出てきます。
AmazonやGoogleより、データベースのスケールアウトが可能な製品も生まれています。
このような最新製品の動向を注視しながら、クライアント企業のニーズを見極め、最適なアーキテクチャの提案を求められることになるでしょう。