DBアタマアカデミー
第1回 記憶装置のトレードオフとバッファの考え方―すべてをとることができないとき (1)
はじめに
意思決定に関する最初の原理は,「無料の昼食(フリーランチ)といったものはどこにもない」ということわざに言い尽くされている。自分の好きな何かを得るためには,たいてい別の何かを手放さなければならない。意思決定は,一つの目標と別の目標の間のトレードオフを必要とするのである。
── N.Gregory Mankiw
この講座は,システム開発で必ずといってよいほど利用されるリレーショナルデータベース管理システム(RDBMS)について,普段あまり意識しない内部のアーキテクチャやストレージのしくみについて解説することで,みなさんのデータベースについての理解を深めてもらうことを目的としています。
開発現場でみなさんを助ける知識が身につくよう,理論と実践のバランスを取りながら進めていきたいと考えています。また,基本的に特定のDBMSには依存しない,汎用的な内容を心がけています。もちろん,そうはいってもやはりDBMSは実装ごとに特徴があるため,実装依存の部分については,つどその旨を明記するようにします。
レベルとしては,SQLとDBMSを半年~1年ぐらいは使ったことのある方を対象に,中級入門ぐらいを想定していますが,今から初めてデータベースを触るという新入社員,新入生のみなさんにも理解できるよう,わかりやすく説明していきますので,ご安心ください。
それではどうぞ,よろしくお願いします。
- 対象読者
- データベースのパフォーマンスに悩みを抱えている人
- 今までブラックボックスだったデータベースの内部動作を知りたい人
- 新米DBA(Database Administrator)
- 対象環境
- すべてのリレーショナルデータベース
DBMSのアーキテクチャ概要
現在商用で使われているリレーショナルデータベースの管理システムには,主要なものだけで10種類ぐらいあります。Oracle,SQL Server,DB2,PostgreSQL,MySQLといったあたりが代表的です。これらの実装は,それぞれに特徴を持っており,内部のアーキテクチャも完全に同じではありません。
しかし,リレーショナルデータベースの機能を提供するという共通の目的があるのだから,基本的な考え方はそれほど異なるものではありません。図1は,DBMSのアーキテクチャの概要を示したものです。
図1 DBMSのアーキテクチャ
出典 :『 Database Management Systems 3rd ed.』Raghu Ramakrishnan, Johannes Gehrke 著,McGraw Hill,2002
上段の層が,ユーザなど使用者とのインタフェースを表します。ここから実行されたSQL文が,中段の層であるDBMSに届き,さまざまな処理が実行され,下段の記憶装置に蓄えられたデータにアクセスが行われます。
このうち,本連載で主に見ていくのは,中段DBMS内の各機能と下段の記憶装置の部分です。最初に簡単に説明しておくと,次のようになります。
- クエリ評価エンジン
ユーザから受け取ったSQLを解釈し,どのような手順で記憶装置のデータへアクセスに行くかを決定します。ここで決定された計画を「実行計画」と呼びます(その計画を実行に移すのが「アクセスメソッド」です)。いわば,DBMSの脳にあたる機能です。
- バッファマネージャ
DBMSはバッファという特別な用途に使うメモリ領域を確保します。そのメモリ領域の使い方を管理するのがバッファマネージャです。ディスクの使い方を管理するディスク容量マネージャと対になって動きます。今回解説するのが,このバッファマネージャの扱う「バッファ」というメモリについてです。
- リカバリマネージャ
DBMSの内部には,絶対に失われてはいけない大切なデータが多く保存されています。しかし,そうはいっても機械は使い続ければいつか壊れるものなので,定期的にバックアップを取得し,有事の際には復旧(リカバリ)できる必要があります。このバックアップとリカバリを管理するのが,リカバリマネージャです。
- トランザクションマネージャとロックマネージャ
データベースを使う人は,普通は1人ではありません。何人もの大勢でいっせいにアクセスしています。そうした一人一人の行う処理は,DBMS内部では「トランザクション」という単位で管理されます。このトランザクション同士をうまくデータの整合性を保ちながら実行させ,必要とあらばデータにロックをかけて誰かを待機させる,といった仕事をするのが,この2つの機能です。
大雑把な説明なのでこれだけで理解しろというほうが無理ですが,今はこれらの機能についてイメージが湧かなくてもかまいません。この連載の中でそれぞれ詳しく取り上げていきますので,全体像についてぼんやりとした絵を持っていただければ十分です。
それでは,今回はまずバッファマネージャの機能,およびそもそも「バッファ」というのが何なのか,ということを取り上げていこうと思います。
記憶装置のおさらい
DBMSのバッファ機能についてお話しする前に,まずシステムがデータを保存する記憶装置について,基本的なことをおさらいしておきましょう。今さら言われなくても知ってるよ,という人もいるでしょうが,復習も兼ねてお付き合いください。
この世にただ飯はあるか
図2は,記憶装置の分類を階層化したものです。一般的に,記憶装置は一次から三次まで3つの階層に分かれます。「記憶コスト」というのは,平たく言って,同じデータ量を保存するのにかかるオカネのことです。私たちは普段,パソコンのHDD(Hard Disk Drive;ハードディスク)は平気で何百Gバイトでも増設しますが,メモリは1Gバイト買うだけでも結構悩みます。これは,それだけHDDが安価で大容量データを保存できる(つまり記憶コストが安い)ことを意味します。ピラミッドの下位ほど面積が大きいのは,この「保存できるデータ容量の大きさ」を表しています。
それなら,下位階層のHDDやテープが上位層のメモリより優れた記憶装置かというと,そういう単純な話ではありません。確かにこれらの媒体は大量データを永続的に保持するには向いているのですが,データへのアクセス速度という点でメモリに遠く及ばないからです。みなさんも,自分のPCで大きなファイルを操作したときなど,「ガリガリガリ」というあのディスクアクセスの特徴的な音と共にマシンがうんともすんとも言わなくなり,長時間待たされた(酷いときはそのまま永遠に待たされる),というストレスフルな経験を持っているでしょう。
つまりここには,容量をとれば速度が犠牲になり,速度をとれば容量が犠牲になる,というトレードオフ(二律背反)の関係が成立しているわけです。いいとこ取りはできません。システムの世界にフリーランチ(free lunch;ただ飯)は存在しないのです。
- データベースの鉄則 1
- 記憶コストとアクセス速度はトレードオフ。
DBアタマアカデミー
- 最終回 治療としてのパフォーマンスチューニング―システムの病気はどう治す?(3)
- 最終回 治療としてのパフォーマンスチューニング―システムの病気はどう治す?(2)
- 最終回 治療としてのパフォーマンスチューニング―システムの病気はどう治す?(1)
- 第4回 クエリ評価エンジンと実行計画―“シェフおまかせ”はいつも美味しいのか(3)
- 第4回 クエリ評価エンジンと実行計画―“シェフおまかせ”はいつも美味しいのか(2)
- 第4回 クエリ評価エンジンと実行計画―“シェフおまかせ”はいつも美味しいのか(1)
- 第3回 バックアップとリカバリ―「もしも」に備え,転んでも泣かない子になる(3)
- 第3回 バックアップとリカバリ―「もしも」に備え,転んでも泣かない子になる(2)
- 第3回 バックアップとリカバリ―「もしも」に備え,転んでも泣かない子になる(1)
- 第2回 トランザクションを知ればデータベースがわかる―「データ復旧」「同時実行制御」を行う“不完全な”しくみ(3)


