みんなに優しく、解りやすくをモットーに開設しています。 以下のルールを守りみんなで助け合いましょう。
1.ファイルメーカーで解らない事があればここで質問して下さい。 何方でも、ご質問・ご回答お願いします。 （優しく回答しましょう）
You are not logged in.
Pages: 1
いつも参考にさせてもらっています。
Win７ ＋ FMA11の環境です。
FMサーバー上で動作しているレコード数が約25万件程のファイルがあります。
検索に関しては、索引が出来てしまえば、全くストレス無く動作しますが、
全データを対象に集計を行おうとすると、ハングアップしたような状況となり、使い物になりません。
集計は、定番（？）のGetSummary関数とソートで行っていますが、ソートが時間を要す元凶です。
ソートを使わずに、快適に動作させるような別の方法があるのではないかと探しましたが、見つかりませんでした。
皆さん、どのようになさっているのでしょうか？
ご教授いただけませんでしょうか？
以上、よろしくお願いします。
ソートは、複合条件でしょうか。単独条件でしたら、そのフィールドに索引ができていれば検索と同等の時間で可能です。
また、集計の定番は、集計フィールドとソートです。GetSummary() 関数は、非常に多くの評価が必要ですので、通常は使わないほうがいいですよ。（定番では無く、集計地を取り出すための例外的な使用です）
それ以外での集計ですと、リレーションを張って、対象レコードの合計などの計算で集計します。
Offline
Shin様
アドバイス有難うございます。
リレーションを張って、対象レコードの合計などの計算で集計すれば、大量レコードでも快適に動作するという事でしょうか？
ちなみにソート条件は複合ではありません。
では、何の目的で GetSummary() を使っていらっしゃいますか。
もうすこし、集計の内容を具体的に書いてください。
20万件ほどの複合条件の集計をよく行なっていますが、だいたい1分ほどで終わっています。
Offline
Shin様
その後、再度フィールド定義等を確認しました。
私、全く勘違いしてました。
実際のファイルは、おっしゃる通り「集計」を使用しており
GetSummary関数は使っていませんでした。
申し訳ありません、
改めて、実際のファイル状況を単純化して記載します。
●元データ（各行が１レコード、場所と状態はフィールド名）
場所 状態
東京 OK
大阪
東京
大阪
東京 OK
大阪 OK
名古屋
大阪
名古屋 OK
・・・・・
このようなデータが大量（約２５万程）
●やりたい事（場所の数と場所毎のOKの数、割合の表示）
以下のような表示です。
場所数 OK数 割合
東京 3 2 67％
大阪 4 1 25%
名古屋 2 1 50%
■ファイルの状態
・場所数、OK数とも定義は「集計」でカウントです。
・場所で自己リレーション
・レイアウトで、場所の小計パートを作成し、場所数 OK数 割合の各フィールドを配置
（割合のフィールドは 場所でリレーションした「割合」を配置）
■操作
・場所でソートし、上記のレイアウト表示
上記の通りですが、動作を快適にする方法をアドバイスください。
以上、よろしくお願いします。
「割合」を配置しなければ速くなりますか？
何でここだけリレーション？
tim様
コメント有難うございました。
「割合」を配置しないレイアウトを作りましたが、差はありません。
ここだけリレーションの件ですが、こうしないとすべての場所が同じ値（4/9）になるためです。
改めて実験をしてみました。
ファイルをオープンして、最初のスクリプト（全レコード表示・レイアウト指定・ソート）実行時は5分から8分かかります。
ただし、一度ソートを解除してから同じスクリプトを実行すると30秒程度で終わります。
同じファイルを別のアカウント（別PC）で実行しても同様で、
1回目は時間がかかりますが、2回目以降はかなりスムーズになります。
ただし、いったんクライアント側でファイルをクローズしてから再起動させると（サーバーは開いたまま）
1回目は時間がかかります。
新たな情報は以上ですが、スムーズな動作に向けたアドバイスをお願いします。
検証したファイルでは、2万レコードでも10秒弱でした。
内部の構造に問題あるのでしょうね。リレーション部分に時間がかかっているのでしょうか。
https://dl.dropboxusercontent.com/u/926 … 42.fp7.zip
Last edited by Shin (2014-05-14 15:19:30)
Offline
ソートするフィールドが非保存になっている？
Offline
索引が作られていても、クライアントでソートする際にその索引ファイルをダウンロードするのにある程度の時間がかかります。2回目に早いのは、この時間が無いためです。
FM13以降ですと、このソートをサーバーで行なっておいて、結果だけを表示させることができそうなのですが。
Offline
FM12ですが、36万レコードのファイルで、１回ソートしてソート済みのままもう1回同じソートをしても10秒ぐらいかかりました。
索引があってもソートが遅いのは、昔から変わらないと思いますが...
一旦閉じたら138秒かかった。
ソートは全データをクライアントに転送するので最初は特に遅いのでしょう。
FM13なら、サーバスクリプトで集計して結果だけ取得するようにすれば早そうですが。
11なら場所の値一覧から集計用テーブルにレコードを作ってリレーションでカウントかなあ。これなら索引が使える。
Shin様
サンプルファイル作成頂き有難うございました。
とても参考になります。
sorter様
集計用テーブルにレコードを作ってリレーションでカウントとの事ですが、ソートを使わないようなので大変気になります。
お手数ですが、もう少し具体的に教えていただけませんでしょうか
よろしくお願い致します。
集計用テーブル::場所＝元データ::場所
でリレーション
場所 ユニークに制限
場所数 Count(元データ::場所)
OK数 Count(元データ::状態)
割合 OK数/場所数
値一覧でなく、とりあえず最初に1回元データを全部インポートすれば、例でいうと3レコードが作成される。以後は開くだけで集計完了。
後は場所が増えた場合にどうするか別途考える。
OK数は状態を使った別のリレーションにした方が速くなるかも？
場所が都道府県なら、
検索して
Get ( 対象レコード数 )で数えて
47回、Loop処理しても速いですよ。
全国郵便番号データを3倍にして37万件にして、
各都道府県のレコード件数を取得してみました。
索引の言語設定をUnicodeにすれば、1秒ほどで数えることができます。
場所の種類がとんでもなく多くある場合は、時間がかかるとおもいますが.....。
Offline
sorter様
外出のためご連絡が遅くなりました。
自宅のテストではソート無しの方法で動作確認出来ました。
明日、サーバー環境で試してみたいと思います。
qb_dp様
データの種類は４７以下です。
アドバイス頂いた方法も試してみたいと思います。
有難うございました。
Pages: 1
[ Generated in 0.009 seconds, 9 queries executed - Memory usage: 593.37 KiB (Peak: 610.27 KiB) ]