最適化について

過去の桐井戸端ＢＢＳ　（桐ver.８）

8863	最適化について	小方博美	2000/12/11-18:50
桐を使用してデータベースを構築したいと考えますが、噂では大規模なデータベースを構築する場合には、最適化を定期的に実行した方が良いと聞いておりますが。最適化とは、何ですか・・・・・? また最適化では、なにをしているのですか・・・・? 何方か、ご教授ください。
8864	Re:最適化について	ぷぷり	2000/12/11-20:24
記事番号8863へのコメントこんばんは、ぷぷりです。ちょっと、言ってる事はおかしいかもしれませんが、とりあえず、もともとデータベースはデータの集まりです。大規模なデータベースになるとデータの追加や削除・更新などが頻繁に行われます。データベースではそれらのデータが正しいかどうかとか、追加・削除の更新のための作業情報や、データを早く処理するためにインデックス等をいろいろもっています。大規模になればなるほど、それらのデータがたまっていき、必要な情報を探すにも時間がかかっていき、データ量も増えていきます。最適化とはそれらの情報で要らない情報は削除して、必要なデータを整理したりすることをさしているんだと思います。それによって検索が早くなったり、ディスクスペースも少なくすんだりします。うーん、うまく説明できたでしょうか?　＞皆さん
8868	最適化（１）デフラグとは	佐田　守弘	2000/12/12-01:09
記事番号8863へのコメント小方博美さん最適化とは、おそらくディスク装置のデフラグメンテーション（デフラグ）の事を言っているのではないかと思います。これはファイルの記録場所を連続化する事によって、読み書き速度を向上させる処理の事です。実は、桐には「最適化」という言葉はありません。またWindowsOSにもなかったと思います。おそらくこの言葉の由来は、MS-DOS時代のファイル管理ユーティリティだと思います。ノートンユーティリティも、この処理を最適化と呼んでいます。最適化で何が行われるかを理解するためには、ファイル管理の仕組みから知っておく事が必要です。 ●ファイル管理の仕組みここで説明するのはWindows9xで使われているFAT方式のファイル管理の仕組みです。この方式ではディレクトリとFATの２つを使って、ファイルの管理（ディスク上のどこにファイルを記録するかの管理）を行います。ディスクにファイルを記録する時に、記録の最小単位があり、これをクラスタと言います。分かりやすい話で、倉庫に荷物を預ける話に喩えてみます。倉庫には同じ大きさのロッカー（箱）が並んでいます。そして、仮に小さな荷物を預ける場合でも、１つのロッカーを専有します。このロッカーがディスクのクラスタに相当します。さてロッカーを借りる際に、倉庫番に名前を伝えると、「５番のロッカーから入れて下さい」と言われます。倉庫番は、預けた人の名前と収納する最初のロッカー番号だけを控えます。なぜ最初のロッカー番号だけかと言うと、倉庫番の帳簿にはロッカー番号を控える場所が１つしかないからなのです。この預けた人の名前（ファイル名）と最初のロッカー番号（先頭クラスタ）を書き込む場所がディレクトリです。収納する荷物はロッカー１つに収まらない時には、複数の箱を利用する事になります。この時、次に空いているロッカーに荷物を入れます。そして、最初の５番のロッカーの扉に、次に使うロッカーの番号、仮にこれが隣の６番だったとしたら６と表示します。次の６番のロッカーには、また次に使うロッカーの番号を表示します。そして最後のロッカーには「終」と書きます。このロッカーの扉をみると、荷物の入っているロッカーの扉には、次のロッカーの番号または「終」と書かれ、空の扉には「空」と表示されています。この次に入れる場所を書いた表が、FAT（File Allocation Table）です。 ●使うロッカーは飛び飛びになるさて、この方法でロッカーを使って行くと、必ずしも隣り合ったロッカーを使えるとは限らない事が分かると思います。丁度空いたロッカーが３つだけだったら、３つはそこに入れ、残り２つは離れた場所に入れる事になります。もちろんそうであっても、次に入れてあるロッカーの番号が書いてありますから、間違える事はありません。しかし、使うロッカーが連続している時に比べて、飛び飛びでは出し入れが面倒になります。実は、ディスク装置上でのファイルの記録も同様で、書き込みと消去を繰り返しているうちに、書き込むクラスタが飛び飛びになります。この状態をフラグメンテーション（分断化）と呼びます。フラグメンテーションが起きると、ファイルの読み書きの際にヘッドの移動が大きくなるので、読み書き時間がかかる様になります。 ●デフラグとは同じ荷主のロッカーは隣り合っていた方が良いので、倉庫番がロッカーの入れ場所の入れ替えをし、順序良く並ぶように並べ替えをします。これがデフラグです。ディスク装置上に飛び飛びに書かれているファイルの記録場所を移動し、またあちこちに空いている使われていないクラスタ埋めて、ファイルの記録場所を並べ替える処理が行われます。また、最適化と言う場合、単にデフラグを行うだけではなく、良く使われるファイルは読み書きしやすい場所に記録する様にする処理も含みます。読み書きしやすい場所とは、ディスク装置のディレクトリとFATの近くの場所の事で、倉庫に喩えれば、入り口近くのロッカーという事になります。佐田守弘(KS-00119)
8869	最適化（２）表はデフラグで速くなるのか？	佐田　守弘	2000/12/12-01:09
記事番号8863へのコメント ■桐の表はデフラグで本当に速くなるのか？フラグメンテーションが起きたディスク装置は、デフラグを行う事によって、読み書き速度が上がります。ですが、これが（デフラグだけで）本当に桐の表の読み書きに効果があるのかは、私自身も良く分かりません。それを理解するために、桐の表ファイルの仕組みを説明します。 ●ページの概念桐の表ファイルは、その中が8KB単位のページで管理されています。データファイルをページで扱うのは、桐の専売特許ではなく、ほとんどのアプリのデータファイルがそうなっています。そうでないとデータの途中での追加挿入ができないからです。分かりやすい例として、ワープロで途中に文章を付け加える（挿入する）事を考えてみます。もし紙に手書きで書く場合だとどうなるでしょうか。１文字挿入するたびに、それ以降を消しゴムで消して、１文字分のスペースを開けなければなりませんね。とても大変な作業になります。実はワープロも同じなのです。１文字挿入するには、それ以降を全て１文字ずつずらさなければなりません。ただし、全文章に渡ってその様な事を行うと大変です。そこで、この処理をページの中だけで行います。そして、そのページが一杯になったら、１ページを２ページに分けて、ページ内の空きを増やします。桐の表でも同じ事を行います。途中に行挿入を行ったり、あるいは行に書き込む文字列が増えて、１ページが一杯になったらページ分割をします。 ●ページは順序良くは並んでいないさて、ページ分割で新しく作られたページは、どこにできるのでしょうか。「その場所に新しいページを入れるのでは？」はありません。なぜなら入れる場所がないから分割するのですから。新しく作られるページは、最後に付け加えられます。今、１，２，３と３ページ並んでいる時、２ページ目を分割したとします。この場合、新しく４ページが作られ、前の２ページの半分がこちらに振り分けられます。つまり、ページの順序は、１，２，４，３になります。この様にページ分割が進むと、データの記録場所の順序は、物理的なページの順序ではなくなります。この場合にも、丁度FATの様に、「どのページからどのページに続く」といったページチェイン情報によって、正しいデータの順で読む事ができます。しかしながら、飛び飛びどころか、順不同になっているページを行ったり来たりしながらデータを読んでいる訳です。つまり、デフラグによって表ファイルの記録場所を連続化したとしても、表ファイルの中では、ヘッドがあちこちに移動しながら読まなければならないのです。 ●ページを順序よく並べるのは表整理表整理を行うと、データの順でページが並び替えられます。表整理を行った後で、ディスクのデフラグを掛ければ、その直後はレコードの順がディスク上の記録場所の順になります。逆にデフラグの後で表整理を行うと、表整理で新しく表を書き出し直すので、フラグメンテーションが起きます。 ●データベースの表は記録順序に意味を持たないワープロの文書であれば、通常は始めから終の方向に読みます。しかし、データベースの表は、必ずしも先頭から終端に読むとは限りません。その代表的な例が整列索引を掛けて、並べ替えを行っている場合です。仮に、表整理とデフラグを行って、データが物理的な記録場所に順序良く記録されているとしても、並べ替え状態で表示するには、表ファイルの中を順不同で読まなければなりません。つまり、ページの順序が順不同であり、フラグメンテーションが起きている状態と余り変わりないのです。 ●本当にデフラグに意味が有るか更に付け加えます。表をバックアップ有りで記録すると、表を保存するたびに新しい場所に表が書き直されます。これはワープロで上書き保存する場合も同じです。データファイルを別の場所に記録し、前のファイル（正しくは前のバックアップファイル）を削除するので、フラグメンテーションが起きます。 ●デフラグは必要な処理ではあるけど... デフラグによって、データの読み書き速度が速くなる。一般論としてはその通りです。でも、上記の理由で、データベースのファイルの読み書きが本当に速くなるのかどうかは、私も良く分かりません。佐田守弘(KS-00119)
8870	最適化（３）大規模システムでデフラグは可能か	佐田　守弘	2000/12/12-01:13
記事番号8863へのコメント大規模システムで２４時間フル稼働のサーバの場合、デフラグが可能かどうかは、やや疑問です。通常のスタンドアローンパソコンの場合には、ディスク装置にデータの書き込みなどがあると、デフラグがやり直しになります。２４時間フル稼働のサーバで常にアクセスされる可能性がある場合、デフラグはできないのではないかと思うのですが。このあたりは詳しい方のフォローをお願いしたいと思います。佐田守弘(KS-00119)
8875	Re:最適化について	宮城	2000/12/12-10:11
記事番号8863へのコメント小方さんのおっしゃる「最適化」は Access等のそれだととりましたが。そうするとぷぷりさんのコメントのほうがあたっていると思います。 Accessだとうちに来ているプログラマさんは、毎日最適化することを推奨しています。佐田さんおっしゃるとおり、桐には「最適化」なる処理はありません。ファイルのまとまりとしての DBという概念がなく、もっぱら単体ファイルがいきなりあるだけだからでしょう。デフラグに関しては補足することはありません。ただ、よくある話として、行削除しながら表整理をかけなかったがため、表のサイズが肥大化したままだったということはあります。
8876	Re:最適化（桐では「表整理」）	Ogo	2000/12/12-10:13
記事番号8863へのコメント >桐を使用してデータベースを構築したいと考えますが、噂では大規模な >データベースを構築する場合には、最適化を定期的に実行した方が良い >と聞いておりますが。データベースで「最適化」と言えば、桐で言えば「表整理」です。 MS-ACCESS 等ではそのものずばりの「最適化」という操作がメニューの中にありますが、桐の場合は「表整理」という用語です（ Paradox は「再構築」だったかな）。で、削除レコードの除去（データを削除しても、実は「削除された」というマークが付けられてデータ処理から除外されるだけで、本当に削除されるわけではないので、運用を続けるとどんどん重たくなって行く）やインデックス（索引）の再構築（データベースで目的のデータに速やかにアクセスするために、事前に索引を定義するのが通常）、カウンタ項目の初期値の見直し、作業領域の事前確保などが「最適化」の中身だと思います。で、そもそもなのですが、「大規模なデータベース」というのが非常に問題があるような気がするのですが。桐でもアクセスでも、デスクトップデータベースで「大規模」は実用的とは言えないと思いますよ。 Win 9x,Me なんかだったら尚更です。どうも、質問の内容からしてデータベースの概念がよく判っていないと思われるのですが、「大規模なデータベース」なら専用サーバーを用意して、その上でクライアントサーバー型のデータベースサービスを常時稼働する―― 各クライアントはそのサーバーに対して、別マシンで端末処理ソフトを使って部分処理（端末処理）をする――というのが正しい発想だと思いますが。

戻る