FireBird DBMS を使う
[ Prev 5. クライアント・サーバシステムを考える ] [ Top 目次 ] [ Next 7. HTML と標準 ]

6. このプログラムの詳細

6.1. データベースの初期化

6.2. プログラム

解説とか…

下手にコードの説明を書くと、同期を取り続ける自信がありません。
ソース中のコメントをボチボチ充実させていく方針です。

6.3. 運用ツール

はっきりいって、滅多にデータが更新されない今回のシステムでは全く不要なのですが、『エンジニアのたしなみ』として定型のツールを作ります。

6.3.1. バックアップ

まず、バックアップツールです。

gbak ユーティリティを使って、データベースの退避・復元のスクリプトです。

バックアップファイル名には、日付時間を付けますが、ネットワーク透過なシステムでは原理的に世界中のどこからでも管理することが可能(やるかどうかは別にして)なので、GMT (世界標準時) を使うかタイムゾーンを付けます。
こうしておかないと、朝、東陽町でバックアップを取り、夕方に San Jose のマシンにログインしてまたバックアップを取ったときに、困りますね。

「あり得ねぇ!」なんて言わないでください。 開発拠点や運用センターが中国やインドにあるなんて普通になってきました。 日頃からタイムゾーンを意識しましょう。

6.3.2. インデックス再編成

大量のデータの追加と削除を繰り返すようなシステムでは、インデックスが次第に偏りを生じ速度低下を招くことがあります。
ランダムなキー値の場合は問題になりませんが、連続するキー値の場合は要注意です。
例えば、一連の伝票番号を持つデータを毎日追加し、3ヶ月経過したものは順次削除するといった処理です。
そういう処理を繰り返すと、ツリー状のインデックスの片側の枝のみが成長し、線形リストに近い状態になっていきます。

具体例でいうと、毎日3万件ほどのデータを追加・削除し続けたシステムでは、半年に 1度程度の頻度で INDEX の再構成が必要になりました。

インデックスのみ再編

6.1. の「インデックス作成」スクリプトに -r オプションを付けて

CreateIndex.sh -r

だけで、基本的に大丈夫です。

全体の再編

しかし、それでもデータベースファイルのサイズが大きくなり効率が下がることがあります。

その時は、DROP INDEX、BACKUP、RESTORE、CREATE INDEX、の順で再構築すると性能を維持できます。

[ Prev 5. クライアント・サーバシステムを考える ] [ Top 目次 ] [ Next 7. HTML と標準 ]
written by © 2009,OOSATO,Kazzrou : kazz_atmark_kk.iij4u.or.jp

この HTML を検査する。 ( XHTML 1.0 Strict で書かれています )
Another HTML Lint Gateway ( Mirrored by htmllint.oosato.org )