過去の桐井戸端ＢＢＳ　（桐ver.８）
11141 併合検索のスピードに影響する要因は何ですか？ 山田 2001/05/11-19:24
私が桐で扱うデータ数は最大10万件ですが、検索スピードは一瞬で満足しています。
ところで、100万件の場合はどうでしょう。
この質問を受けました。
同じ検索スピードなら桐ユーザが約**名殖えるのですが。

11143 Re:併合検索のスピードは 島尾 2001/05/11-23:46
記事番号11141へのコメント
索引定義がされている項目、（さらに重複禁止）で索引を利用できる形態（専有・参照）ならほぼ一瞬といっていいかも。
11148 併合のスピードに影響する要因 佐田　守弘 2001/05/12-01:33
記事番号11143へのコメント
山田さん
併合の処理速度に適切な索引が設定されている事が大きく影響する事は、
#11143で島尾さんが書かれている通りです。

ここでは、併合速度に影響する要因について補足しておきます。
既に過去ログの
#3619：「桐で扱えるデータ量」（1999/12/5-22:58）
#7371：「Re:併合処理が遅いのですが…」（2000/08/29-02:36）
に書いた事と多少重複しますが、ポイントを繰り返します。

■ 併合操作と索引
●併合先表と併合元表
併合では、併合先の表を上から順に見て行きながら、参照項目を併合元表から検索し、併合項目の処理を行います。
これが分かれば、索引が処理速度にどの様に影響するかが自と分かります。
①併合先表：全てを解除した状態で行うのが最も早くなります。併合先表は、単に上から下に見て行くだけのためです。
②併合元表：参照項目についての索引がある事で、格段に速くなります。
もし重複禁止の索引であれば、索引で唯一にレコードを選べますから、更にスピードアップします。
どの位速くなるかは状況によってかなり変わりますが、数倍の差ではなく、数桁速くなる事も稀ではありません。

●適切な索引とは
過去に、「索引を設定してあるが、併合速度に影響しない」との質問もありました。
そのような場合には原因は２つ考えられます。
①索引が適切でない
単に索引があればよいのではなく、参照項目を検索できる索引です。
複数項目で参照するなら、それらの項目をその順序で組み合わせた索引が必要になります。
単独項目の索引があっても組み合わせては使ってくれません。
②索引が使えない状況である
表が共有状態であると、索引は無効になります。なぜなら、索引を読み込んでも、
他のユーザーによってレコードが書き替えられている可能性があるからです。

■レコード数の影響
さて、最初の質問である「10万件の時は一瞬でも100万件の場合はどうであるか」ですが、状況によって変わります。
●表を開く時の索引の扱われ方
桐は表を開いた時に、まずその表の中の指定された索引のページを読み込みます。
レコードのページは、表示するレコードのみを読むだけで、全レコードを読む訳ではありません。
これで分かる通り、索引が全てメモリに読み込めるかどうかが大きなポイントになります。
もし索引がメモリに読み込み切れれば、レコード数に関係無く、文字どおり一瞬で検索ができます。
しかし、索引が全て読み込めず、索引の読み込み直しを繰り返すと、一瞬と言う訳には行かなくなります。
この場合には、索引がない時程ではありませんが、劇的に遅くなります。
●索引サイズに影響する要因
まずは直感的に理解できる事ですが、同じ表であればレコード数が増える程、
索引も大きくなります。これは、概ねレコード数に比例すると考えてもよいでしょう。
大切なのは、どの様な項目で索引を作るかです。
索引とは、指定した索引項目の項目値を、特殊なツリー構造(B-tree)に並べ替えたものです。
索引項目が長ければ、索引は大きくなります。
桐は、長い文字列項目や、複数の項目をつなげて、１レコード当たり最大2KBまでの索引を作れます。
しかしそのような冗長な索引では、本来の索引の機能を果せない事が御理解頂けると思います。
もちろん、長い索引項目では、索引そのものを検索するにも時間がかかります。
索引は、簡潔な項目で作るのがベストです。
レコードを特定する項目には、カウンタ型や整数型などを使いましょう。
カウンタ型であれば4バイトで済みます。
仮に100万レコードでも、約4MBのサイズですから、おそらくメモリに読み込めるサイズに収まります。
しかし、住所(仮に20文字)氏名(5文字)を組み合わせた索引を作ったとしたら、50MBの索引になりますから、多分メモリには読み込めないでしょう。
●マシン環境
多分これも無視できないはずです。
メモリが不足していてせっかく読み込んだ索引情報がスワップさたら、劇的に遅くなります。
充分なメモリがあれば、多分、5MB～10MB程度の索引情報は、メモリに読み込んで処理できるはずだと思います。

佐田守弘(KS-00119)
11151 併合の仕様についての質問 toshi-chan 2001/05/12-10:56
記事番号11148へのコメント
佐田さん、こんにちは。
佐田さんの説明は、併合先と併合元が入れ替わっていませんか。
私の勘違いだったら申し訳ないのですが。

私のこれまでの認識は、
「併合元表から１行を取り出し、併合先の照合項目を検索する。一致するデータがあれば、
その行に対して演算を行う。併合元表のすべての行についてこれを行う。」
でした。桐のマニュアルには
「併合先の照合項目に索引を設定すると処理が速くなる。」
と書いてあるので前記のように思っていました。
ただ、
「どの表からどの表へ向けて検索を行うのか」
はどこにも書かれていませんね。
11159 Re:併合の仕様についての質問 佐田　守弘 2001/05/13-00:48
記事番号11151へのコメント
toshi-chanさん

そう思っていたのですが、もし間違っているといけないので、確認して報告します。

佐田守弘(KS-00119)
11160 併合の仕様について 佐田　守弘 2001/05/13-01:19
記事番号11151へのコメント
toshi-chanさん
まず、桐ver.8のリファレンスには、併合の索引設定の記載が見つけられなかったので、桐ver.5のリファレンスで調べた結果です。
おそらく、桐ver.5も8も併合の仕様は変わってないはずです。

桐ver.5のリファレンス１の877頁によると、
=====================================================================
併合を実行するときは、表を次の様な状態にしておいた方が高速になります。
　・併合元の表は、参照項目の順序で整列し、選択状態にはしない
　・併合先の表は、基本状態にしておく
=====================================================================
と書かれています。

従って、併合先表を上から順に見ながら、参照項目について併合元表から検索すると理解していた訳です。

しかしこの検索方法だと、置換はできても挿入ができないですね。
また、選択や削除もできませんね。

やはり管理工学にきちんと確認してからもう一度報告する事にします。

佐田守弘(KS-00119)
11161 併合の仕様について（訂正） 佐田　守弘 2001/05/13-01:38
記事番号11160へのコメント
toshi-chanさん
文字の読み間違いでした。

桐ver.5のリファレンス１の877頁は、
=====================================================================
併合を実行するときは、表を次の様な状態にしておいた方が高速になります。
　・併合先の表は、参照項目の順序で整列し、選択状態にはしない
　・併合元の表は、基本状態にしておく
=====================================================================
と書かれていました。
結論として、toshi-chanさんが指摘された通り、
併合元表を上から順に見ながら参照項目を併合先表から検索し、置換や挿入その他の操作を行います。
従いまして、#11148の書き込みは、併合元と併合先を入れ違いになっています。

佐田守弘(KS-00119)

11162 併合のスピードに影響する要因（訂正版） 佐田　守弘 2001/05/13-01:46
記事番号11141へのコメント
山田さん
併合の処理速度に適切な索引が設定されている事が大きく影響する事は、
#11143で島尾さんが書かれている通りです。

ここでは、併合速度に影響する要因について補足しておきます。
既に過去ログの
#3619：「桐で扱えるデータ量」（1999/12/5-22:58）
#7371：「Re:併合処理が遅いのですが…」（2000/08/29-02:36）
に書いた事と多少重複しますが、ポイントを繰り返します。

■ 併合操作と索引
●併合先表と併合元表
併合では、併合元の表を上から順に見て行きながら、参照項目を併合先表から検索し、
併合項目の処理を行います。
①併合元表：全てを解除した状態で行うのが最も早くなります。併合元表は、単に上から下に見て行くだけのためです。
②併合先表：参照項目についての索引がある事で、格段に速くなります。
もし重複禁止の索引であれば、索引で唯一にレコードを選べますから、更にスピードアップします。
どの位速くなるかは状況によってかなり変わりますが、数倍の差ではなく、数桁速くなる事も稀ではありません。

●適切な索引とは
過去に、「索引を設定してあるが、併合速度に影響しない」との質問もありました。
そのような場合には原因は２つ考えられます。
①索引が適切でない
単に索引があればよいのではなく、参照項目を検索できる索引です。
複数項目で参照するなら、それらの項目をその順序で組み合わせた索引が必要になります。
単独項目の索引があっても組み合わせては使ってくれません。
②索引が使えない状況である
表が共有状態であると、索引は無効になります。なぜなら、索引を読み込んでも、
他のユーザーによってレコードが書き替えられている可能性があるからです。

■レコード数の影響
さて、最初の質問である「10万件の時は一瞬でも100万件の場合はどうであるか」ですが、状況によって変わります。
●表を開く時の索引の扱われ方
桐は表を開いた時に、まずその表の中の指定された索引のページを読み込みます。
レコードのページは、表示するレコードのみを読むだけで、全レコードを読む訳ではありません。
これで分かる通り、索引が全てメモリに読み込めるかどうかが大きなポイントになります。
もし索引がメモリに読み込み切れれば、レコード数に関係無く、文字どおり一瞬で検索ができます。
しかし、索引が全て読み込めず、索引の読み込み直しを繰り返すと、一瞬と言う訳には行かなくなります。
この場合には、索引がない時程ではありませんが、劇的に遅くなります。
●索引サイズに影響する要因
まずは直感的に理解できる事ですが、同じ表であればレコード数が増える程、索引も大きくなります。
これは、概ねレコード数に比例すると考えてもよいでしょう。
大切なのは、どの様な項目で索引を作るかです。
索引とは、指定した索引項目の項目値を、特殊なツリー構造(B-tree)に並べ替えたものです。
索引項目が長ければ、索引は大きくなります。
桐は、長い文字列項目や、複数の項目をつなげて、１レコード当たり最大2KBまでの索引を作れます。
しかしそのような冗長な索引では、本来の索引の機能を果せない事が御理解頂けると思います。
もちろん、長い索引項目では、索引そのものを検索するにも時間がかかります。
索引は、簡潔な項目で作るのがベストです。
レコードを特定する項目には、カウンタ型や整数型などを使いましょう。
カウンタ型であれば4バイトで済みます。
仮に100万レコードでも、約4MBのサイズですから、おそらくメモリに読み込めるサイズに収まります。
しかし、住所(仮に20文字)氏名(5文字)を組み合わせた索引を作ったとしたら、
50MBの索引になりますから、多分メモリには読み込めないでしょう。
●マシン環境
多分これも無視できないはずです。メモリが不足していてせっかく読み込んだ索引情報がスワップさたら、劇的に遅くなります。
充分なメモリがあれば、多分、5MB～10MB程度の索引情報は、メモリに読み込んで処理できるはずだと思います。

佐田守弘(KS-00119)
11163 Re:併合の仕様について（訂正） toshi-chan 2001/05/13-02:06
記事番号11161へのコメント
ありがとうございました。
リファレンスでの記載箇所は、桐ver７では表編集の３７３ページ、ver８では表編集の３６９ページです。
11171 Re:併合検索のスピードは ONnoji 2001/05/14-11:47
記事番号11141へのコメント
>私が桐で扱うデータ数は最大10万件ですが、検索スピードは一瞬で満足していま
>す。
>ところで、100万件の場合はどうでしょう。
>この質問を受けました。
>同じ検索スピードなら桐ユーザが約**名殖えるのですが。

山田さん、こんにちは。ONnojiです。

以前併合のパフォーマンスを調べたことがありました。
以下は併合に関しての私的メモですが、だいたい合っていると思います。
間違っていたらごめんなさい。

＜索引があれば高速になる＞
併合：置換／挿入／置換挿入／削除では、
併合先（to）の表に併合条件の照合項目のいずれか１つの項目を主整列項目とする索引が必要。
相手の表（from）に索引は無くてよい。

反対に併合：選択では、
併合元（from）の表に併合条件の照合項目のいずれか１つの項目を主整列項目とする索引が必要。
相手の表（to）に索引は無くてよい。

＜索引の使われかた＞
例えば併合の照合項目が［Ａ］と［Ｂ］の場合の例

a.［Ｃ］主整列索引と［Ｂ］主整列索引の２つがある時には［Ｂ］主整列索引が使われる。

b.［Ｃ］主整列索引と［Ａ］主整列索引と［Ｂ］主整列索引の３つがある時には、
　［Ａ］主整列索引と［Ｂ］主整列索引が候補になるが、
　より最後に定義されている索引が使用される。
＊ＤＯＳ桐ではより最初に定義されている索引が使用される。

c.［Ａ］＋［Ｂ］索引と［Ａ］主整列索引と［Ｂ］主整列索引の３つがある時には、
　マルチキー索引よりシングルキー索引が候補になる。
　より最後に定義されているシングルキー索引が使用される。

d.シングルキー索引がない場合にはマルチキー索引が候補になる。
　［Ａ］＋［？］＋［？］索引が使われるとき［Ａ］キーだけでインデックスサーチして
　［？］はインデックスサーチに使われない。

e.重複禁止の索引は優先候補になる。
候補になる重複禁止の索引が複数ある場合にはより最後に定義されている索引が使用されると思われる。
　＊ＤＯＳ桐ではより最初に定義されている重複禁止索引が使用されると思われる。

f.専有で索引状態のとき、
　現在使用中の索引の主整列が併合条件の照合項目のいずれかの場合には、最優先される。

g.索引に項目計算式の項目が１つでも含まれている場合にはその索引は使われない。

蛇足：
ACCESSと桐v8で比べた時、条件にもよりますが大差無い結果だったと聞いたことがあります。
むしろ桐V8のほうが速かった場合もあったと聞きました。
11174 Re:併合検索のスピードはの御礼 山田 2001/05/14-16:18
記事番号11141へのコメント
みなさん　多くの書き込みありがとうございました。
おかげさまで、併合処理について再認識する機会ともなりました。

ありがとうございました。


11179 Re:併合検索のスピードは ONnoji 2001/05/14-18:36
記事番号11171へのコメント
ONnojiさんは No.11171「Re:併合検索のスピードは」で書きました。
の追加です。

h.絞り込み状態では索引は使われない。
　DOS桐では選択状態では索引は使われない。

が抜けていました。

間違っていたらごめんなさい。

戻る