ここでは、Linux上でリレーショナルデータベース＊1を扱っていくうえで、基本として理解しておいたほうが望ましいリレーショナルデータベースマネジメントシステム(RDBMS)の概論や、その必要性、SQL＊2や基本的なサーバサイドでの使われ方などを中心に述べていく。
RDBMSの必要性と歴史
データベースが一般化する以前は、情報を保存する仕組みはファイルが普通であった。ファイルはアプリケーションプログラムの入出力バッファとしての意味が強かった。この場合、アプリケーションプログラムが書き変わるごとにファイルのレコード定義は変わるし、ファイルの中のデータの意味はプログラムのソースを見ないと厳密にはわからない。
■データベースはなぜ出てきたか
しかし、一般にアプリケーションよりもデータ構造のほうがシステムの中で安定的に長い期間存在し続けることが経験的にも分析的にも明確になってきた。そこで、データそのものを集中して一元管理する必要性が認識され、「データベースシステム」が登場した(図1)。
 |
|---|
| 【図1】ファイルとデータベース |
データベースの必要性は1960年代早期(文献によっては1950年代末)から指摘されている。計算機がビジネス用途で使用されるのにほぼ合わせて、データベースへの要求は出てきたと言ってもよい。
その後いくつかのタイプのデータベース製品が出現した。そのデータ構造から階層型やネットワーク型と呼ばれるデータベースであり、企業や銀行の基盤業務を支えていた。これらの特徴はデータベースのレコード中にポインタがあり、それが互いのつながりを定義していた点にある。
これらは1990年代の初め頃までは広く使われていたが、今日では一部の基幹系業務を除いて見かけることは少なくなっており、現在ではリレーショナルデータベース(RDB)が主流を占めるに至っている。
データベースはデータ自体の集中管理を行ったり、パフォーマンス向上の要求から、以下のような機能をデータベース自体で持ち、管理者やプログラマーの負担を減らしている。
・データを重複して持たない
同じ意味のデータを、別々に管理したのではメンテナンスが大変になる。たとえば顧客データを受注情報と出荷情報で、それぞれ独立して管理したのでは大変なのは容易に想像できるであろう、このように「1つの事象を1カ所で管理し、その構造を維持する」ことはデータベースの設計上非常に重要である。
・データの独立性の確保
アプリケーションとデータの分離である。アプリケーションの改造がデータベースの構造に影響を与えてはならず、データベースの構造変化があっても、その変化した部分を使ってないアプリケーションに影響を与えてはならない。
・安全保護
データを1カ所で集中管理する場合、そのままではデータベースを検索する手段を持つものは、すべてのデータを閲覧可能となってしまう。そこでデータごとにアクセス可能な権限を設定でき、資格のないユーザーからはアクセスを禁止するような機構が必須となる。
・エラーからの回復
データをデータベースで集中管理することは、データベースに破損が生じた時の影響範囲が広くなることを意味する。そのためバックアップ／リカバリ機能はデータベースの重要な機能である。各社のDBMSが差別化を試みる大きな分野であると同時に、この部分をサポートするサードパーティ製品も多く登場している。
・並行処理
データベースでは複数のアプリケーションから同一のデータがアクセスされることが当たり前となる。そうなるとあるデータをアプリケーションが参照している時に、別のアプリケーションが更新要求を出す、あるいは複数のアプリケーションが同時にデータベースの同じ場所に更新要求を発行するという事態も考えられる。
データベースエンジンは、これらの処理を上手に、かつパフォーマンスをなるべく落とさずにさばくことが要求される。いわゆる排他制御であるが、この部分の実装の仕方も、各社のデータベースエンジンごとに特徴が出てくる部分である。
■RDBの誕生
リレーショナルデータベースという概念は、IBMのサンノゼ研究所に勤務していたE.F.Codd博士が1970年に発表した論文が理論的な基盤となっている。 集合論と関係代数を研究していた彼は、データ構造や定義自体に互いに関数的な制約を与える構造をベースとした、リレーショナルなデータベースを実現することによって、真の意味でデータの独立性や一貫性、そして安全保護が可能になると考えた。データベースがリレーショナルであるために必要な条件は、以下の点にあると最初の論文の中で述べている。
(1)フラットなテーブル構造であること(Row＝行とColumn＝列の構造)
(2)データはテーブルの中の値によってのみ結びつけられる
(3)数学の集合理論に基づいた演算子が用意されていること
(4)正規化条件を満たすこと
(1)のテーブル構造にすることにより、人間が直感的にデータ構造を把握しやすく設計がしやすくなるとともに、データベースを制御するプログラムから見ても、各種参照制約のチェックなどが行いやすくなる(実際には集合論的なデータの扱いを容易にするには、このような型式が最適であったということであるが)。
(2)は、ポインタや順番などの概念を廃し、列中のデータの値のみが互いのデータを関連づけるキーとするという発想である。これにより各種制約が記述しやすく、うまく使えば基本的なデータ同士の矛盾などを特別なプログラムを作ることなく防ぐことができる。
(3)の演算子が、今日のSQLである。データベースに対して集合理論に基づいた命令を発行することにより、比較的単純な命令の組み合わせで、望むデータを取り出すことが原理的に可能である(ただ、次項のデータベースの正規化がまずいと、このメリットをうまく活かせないこともある)。
(4)正規化条件とは、RDBの設計を行ううえで一番重要な概念であり、これをうまく行えば、上記(1)～(3)までのRDBのメリットを有効に活かすことができ、データの保全性、独立性を高め、ひいてはシステム作成、保全時の生産性を上げることができる。
具体的には、配列や入れ子のグループなどをRDBのテーブル構造から排除することが必要である。なお、ORDBMS(オブジェクトRDBMS)では、あえて繰り返し項目などが設定できるようにしている場合もある。
ここで述べてきたような機能や特徴を、部分的ながらも持ち始めたRDBMSが実際に市場に出てきたのは、70年代末から80年代初めにかけてである。1978年にUNIXシステムの上で動くOracleが登場し、1981年にはDB2の大元となるSQL/DSが登場している。
1980年代には、既存のDBMSにSQLエンジンの皮をかぶせた擬似的なRDBと呼ぶべき製品もいくつか出てきて、パフォーマンス面や価格的メリットを強調し、純RDB製品と市場シェア争いを繰り広げた。またRDBMSの生産性、保守性の高さは魅力的とされてきたが、インデックスによる検索処理、参照整合性のチェック、SQLの構文解析などは、当時のコンピュータにとっては、ディスクアクセスの削減以上に多大なCPU負荷を要求し、パフォーマンス面の不安が長く言われてきた。
しかし90年代に入りハードウェアの価格性能比の改善に伴い、これらのデメリットはほとんどデメリットと言えないものになり、データベース市場ではRDBがほぼ標準としての地位を占めるに至り、今日では各社RDBMS製品が互いにシェアを競っているのが実情である。
90年代末以降、Javaに代表されるオブジェクト指向技術の浸透やXMLの登場は、一時期RDBMSの時代が終わり、OODBMS(オブジェクトオリエンテッドDBMS)が次の時代の覇者になると言われる原因となった。
しかし、RDBの性能と機能、柔軟性は未だに強力であり、一部オブジェクト指向に対応したり、Web開発言語向けのインターフェイスやXML向けの連携機能を用意することなどにより、今日でも主流の地位は揺らぐには至ってない。一方、OODBMSは今ひとつ広がりが小さいままである。これは、RDBが曲がりなりにもSQLという共通的な管理開発のベースを持ち、トランザクション制御、バックアップ、リカバリ管理などの信頼性の面でアドバンテージを保ち続けているためと考えられる。今後もしばらくは企業のデータ管理の中心にRDBMSが使われ続けると予想される。
余談だが、PC向けにはDOSが登場して間もない頃からカード型のデータベース製品がいくつかあった。こちらは住所録や小規模商店などで簡単な顧客管理、製品管理などの用途によく使われていた。
また、SQLこそ使わないがRDB的なことができるdBaseというソフトもあり、こちらはもう少し本格的な中小企業の業務用途などで使われていた。dBaseの上で動く業務システムやパッケージ開発を行う、小規模なソフトハウスや個人開発者が存在し、PCの黎明期に大きな役割を果たしている。これらの用途や人は今日ではAccessなどのデスクトップデータベースに移行している。
Linux上でのRDBMSの状況
今日では、Linuxの上で動くRDB製品も一般的となり、オープンソースのRDBエンジンや、各種市販の有償ライセンスRDB製品など、選択肢も多くなっている。Linuxがブレークし始めた5年ほど前は、サーバとしてのLinuxはWebのフロントエンドとしては強力だが、メジャーで信頼性のあるRDBエンジンが欠けているのが弱点と言われてきた。しかし、1998年のOracleの正式サポート対応を機に各種商用データベースエンジンの対応が進み、今日では小規模な組み込み用から大規模なエンタープライズ用途向けの製品まで、真っ先にサポート対応されるプラットフォームとして、Linuxが取り上げられるようになっている。
一方で、PostgreSQL、MySQLに代表されるオープンソースのデータベースエンジンもここ数年で着実なバージョンアップと機能強化を繰り返し、今日ではこれらのプロダクトが使われる裾野は確実に広がっている。
基幹系での使用をも視野に入れた開発が進められているPostgreSQLと、軽量軽快な操作性が特徴なMySQLと、得意分野に差はあるようではあるが、SQLエンジンとしての進化は今後とも双方共に続いていくだろう。
また商用データベースでも、OracleやDB2のようなメジャープレイヤーに加え、SymfowareやHi-RDBなどの国産ベンダーのデータベースエンジンも動作するようになってきているし、DBMasterなどの商用軽量DBMSもLinuxに対応している。
オープンソースでも、従来のPostgreSQL、MySQLに加え、InterBaseとAPIやSQLで互換性を持たせたFirebirdという製品の注目度も上がり始めている。このプロジェクトは2000年に発足して、まだ歴史は浅いがそのわりに利用率は上がっているように思える。
このように、今やLinuxは最も多様なRDBMSの選択肢が提供されているOSであると言ってもよい状況である。
一方、PCサーバは、データベースエンジンを動かすプラットフォームとして見たとき、いわゆるPC/AT互換アーキテクチャは、I/O周りが弱点と言われ続けてきた。これらの問題点は、SolarisやHPのUNIX専用機と比較して以前から指摘されてきており、しばしばWindows自体への批判とセットで取り上げられてきている。CPUは高速でもそれ以外は遅いというわけである。
その後のPCIバスの登場により大幅にI/O周りの性能は改善されたが、まだまだというのが特にハイエンドでの状況であろう。
最近のPCアーキテクチャでは、まずチップセットのノーズブリッジに相当する部分から機能強化が始まり、メモリの高速化やビデオ入出力の高速化が進んできた。メモリはサーバ用途でもDDR SDRAMメモリが一般化され、PC2100から、2700、3300と高速化が進んでいる。AGPバスも最近では8倍速が一般化してきている。
それに比べればサウスブリッジ側の進歩はやや遅かったが、サーバ用途ではこれまでのPCIバスの性能を大幅に拡張したPCI-X規格がミッドレンジクラス以上のPCサーバでは一般的となり、Ultra320 SCSIとも相まってI/O周りの弱点はかなり是正されつつある。
ストレージ分野では、SAN＊3やNAS＊4の採用も進んでおり、PCクラスタの技術と組み合わせれば、かなりのスケーラビリティを持たせることも可能になっている。
ローエンドクラスのサーバでも、シリアルATAなどの採用が今後進めば、この分野でのパフォーマンス向上も今後望めるだろう。
一方、ソフト面においても、Linuxはカーネル2.4以降、全体的なパフォーマンス向上、メモリマネジメントの改善、マルチプロセッサやスケジューリング処理、ジャーナルファイルシステムの採用など、OSレベルでの信頼性向上が図られている。
リーナス氏自身はデスクトップ用途での強化に関心が強いようであるが、カーネルコミュニティに送られているコードは、サーバ提供企業群からのものが増えており、結果としてサーバとしてのLinux機能強化には拍車がかかっている。
今まで述べてきたように、RDBを高速で動かすプラットフォームとして、Linux＋PCサーバという選択肢は確実に普及し、そのシェアを伸ばしつつあると言ってよいだろう。
＊2 SQL:テーブルの定義やデータ操作、関係演算など、リレーショナルデータベースを操作するための言語。ANSIやJISで標準化されている世界標準規格。
＊3 SAN(Storage Area Network):ファイバチャネルでサーバ／ストレージ間を接続する専用の高速ネットワーク。デバイス間の制御プロトコルにはSCSIコマンドが利用される。
＊4 NAS(Network Attached Storage):RAIDハードディスクを内蔵し、NFSやCIFS(SMB)などのネットワークファイル共有プロトコルを使用して、ネットワークに直接接続する形式のストレージデバイスまたはアプライアンス製品。
