データを複数のサーバに分散して配置し1つのデータベースとして扱う方式。
分散データベースとは、データを複数のサーバ(ノード=処理を担う1台1台のコンピュータのこと)に分けて置きながら、利用者からは1つのデータベースのように扱える仕組みのことです。それを管理するソフトウェアを DDBMS(分散DB管理システム)と呼びます。
身近な例で考えると、全国にある支店の倉庫に似ています。商品は東京・大阪・福岡の倉庫に分けて保管されていますが、お客さんは「1つのお店に注文する」だけで済みます。どの倉庫から取り寄せるかは店側が裏側で調整してくれる──この「裏側の調整役」が分散データベースの役割です。
上の図解では、利用者が SQL(データベースへの命令文)を1つ送るだけで、その下の透過性レイヤが3台のノードに振り分けてくれる様子を示しています。1台に集中させず分けることで、処理を分担して速くしたり、1台が壊れても全体は止まらないようにしたりできます。
分散データベースで最も大切な性質が透過性(とうかせい)です。透過性とは、「データが複数のサーバに分かれている」という複雑な事情を利用者から隠して、1つのDBのように見せることを指します。ガラスが透き通って向こう側の事情が見えないように、内部構造を意識させない、という意味です。
| 透過性の種類 | 隠してくれること |
|---|---|
| 位置透過性 | データがどのサーバにあるかを意識しなくてよい |
| 分割透過性 | テーブルが複数に分割されていても1つに見える |
| 複製透過性 | 同じデータが複数サーバに複製されていても1つに見える |
| 障害透過性 | 一部のサーバが故障しても処理を続けられる |
これらをまとめて整理すると、次のように覚えると分かりやすいです。
・位置透過性:「どこにある?」を気にしなくてよい
・分割透過性:「テーブルが分かれている?」を気にしなくてよい
・複製透過性:「コピーが何個ある?」を気にしなくてよい
・障害透過性:「1台壊れた?」を気にしなくてよい
上の図解の点線で囲んだ透過性レイヤが、これらの透過性をまとめて提供しています。利用者は SELECT * FROM 顧客 と書くだけで、その顧客データが東京・大阪・福岡のどこにあろうと、自動でまとめて返してもらえるのです。
データを分けると便利な一方で、1台のDBにはなかった難しさが生まれます。主な課題は次のとおりです。
・一貫性(いっかんせい)の維持:複数サーバのデータが食い違わないようにする必要がある
・分散トランザクション:複数サーバにまたがる更新を「すべて成功」か「すべて失敗」にそろえる必要がある
・ネットワーク障害:サーバ間の通信が切れると処理を進められなくなる
・管理の複雑さ:どこに何があるかの管理や障害対応が複雑になる
特に難しいのが分散トランザクションです。トランザクションとは「一連の処理をひとまとまりとして扱う単位」のことで、たとえば「Aの口座から引いてBの口座に足す」はどちらか片方だけ成功してはいけません。複数サーバにまたがると、これを保証するために2相コミット(2フェーズコミット)──全員に「準備OK?」と確認してから一斉に確定する手順──が使われます。
身近な例で考えると、離れた友人同士の待ち合わせに似ています。お互いに連絡が取れているうちは予定を合わせられますが、電話がつながらなくなると「相手は本当に来るのか?」が分からず動けなくなります。分散データベースも同じで、ネットワークが分断されると一貫性を保つのが一気に難しくなるのです。