みんなに優しく、解りやすくをモットーに開設しています。 以下のルールを守りみんなで助け合いましょう。
1.ファイルメーカーで解らない事があればここで質問して下さい。 何方でも、ご質問・ご回答お願いします。 （優しく回答しましょう）
You are not logged in.
Pages: 1
検索や表示が遅くなるというのはどの程度のレコード数からなんですか？
気になったところでは以下のようなところです
・普通のフィールドが10個、索引なし非保存の計算フィールドが10個程度あったときでは何レコードくらいから動作が重くなるか
・FMのバージョンは関係あるか
・リレーションの数やレコード数の関係(ポータル表示やID取得などの速度)
・フィールド内容を値一覧に指定しているときは、そのレコード数によって遅くなるか(値一覧を呼び出すたびに対象の全レコードを読んでいるのか)
数千程度のレコードしかあつかったことがないのでみなさまの経験上の感覚から
なんとなくでもよいので教えてください
ちなみにPCのスペック的には
CPU Core i5 4世代以降
メモリ 8から16G
SSDもしくはHDD
程度を想定しています
Offline
遅くなる、という抽象的な判断は難しいでしょうが。
非保存の計算フィールドは検索対象にしない、という事でしたら、数千万レコード程度でも検索はごく早いでしょうね。表示は、計算式の作り方とどちらかというとネットワークとグラフィックの性能に依存しそうです。
Offline
例えば、1万レコードと1000万レコードのテーブルがあったとして
計算フィールドで検索しない限り、レイアウトの表示やポータルでの抽出に
目立った差はないということでしょうか？
レイアウトを開くたびに再計算されるのでやはりレコード数が多くなると
なかなか表示されない、ということがあるでしょうか？
対象レコードに計算フィールドが含まれている場合もだめなんですかね？
Offline
ファイルの構造によって、結果は大きく変わると思います。経験豊かな人が作ると、それなりに早くなるでしょうね。
抽出そのものの時間差は、理論的に1000倍以上の差が出ます。１万レコード程度では数ms以下でしょう。それが１秒程度になって業務に支障があるか、という事になります。それよりも、レイアウトの表示については、その1画面で表示されるレコード数に比例します。ポータルでの抽出は、対象となるレコード数とソートの早さによると思います。
ただし、非保存計算フィールドがあると、それを表示の度に計算して再表示する事になりますので、それなりに時間がかかるでしょう。
手元に100万件のシリアル値を持たせたファイルがありますが、MacBookpro Core2Duo 2G でシリアル値での1レコードの検索は瞬時です。シリアル値をテキスト処理させての検索で 0 を含むシリアルで検索させても、５秒ほどです。表示は、ほぼ瞬時ですよ。同じファイルで、非保存の数値計算フィールド（シリアル値*2）で検索すると８秒ほどかかります。
通常の業務で使っているサーバー環境での数万件の顧客マスターで、氏名からの抽出もほぼ瞬時です。（前の職場では300万件超えでしたがほぼ瞬時でした）
上の様な事はごく簡単な事ですので、ご自分で実証されてみては如何ですか。
具体的にどのような計算フィールドがあるのかを書いていただけると、具体的にアドバイスできるかもしれません。
Offline
私も経験が浅く現在は数十万件同士のリレーションですが、増える一方で将来的な危惧を捨てきれないためこの話題には興味があります。
運用中のシステムはFMサーバー15がAWSのm4.xlargeで稼働していて、営業時間中はノートやデスクトップ、iPhone合わせて50弱程度の同時接続です。
試行錯誤する中でやはり動作や検索が遅いという苦情も何度かあったので、あくまで未熟な経験則ですが参考までに。
・フィールド内容を値一覧に指定しているときは、そのレコード数によって遅くなるか(値一覧を呼び出すたびに対象の全レコードを読んでいるのか)
少なくとも最初に表示する際に全レコード読みに行っているようですが、少なくともそのレイアウトを表示している間はキャッシュされるようです。
一度実験的に数十万件のレコードから都道府県、市区町村の動的一覧を取る値一覧を使用しましたが、最初の都道府県表示はもちろん、都道府県選択後の市区町村表示も非常に遅かったです。
対策としてエリア情報用の専用テーブルを作成し、定期的に元のテーブルから未登録のエリア情報を専用テーブルに追加する方法を採りました。
専用テーブルも数千件のレコードになりますが、重複データがないだけでも速度は段違いです。
・リレーションの数やレコード数の関係(ポータル表示やID取得などの速度)
表示部分について、総レコード数や対象レコード数に多寡はあまり関係がないように思えます。
あくまで画面内に表示しているフィールドやレコードの数に、リレーションの数や深さを掛けたような表示時間の増え方をしている感じですね。
またレイアウトの表示については実際に表示するPCのグラフィック性能、メモリなどの影響を強く受けます。
そのため、連結キーが入力されていないなどの理由で関連レコードのフィールドを表示する必要がない場合、それらのオブジェクトを隠してしまうことで有意な速度改善が見られました。
通信内容を解析したわけではないので推測に過ぎませんが、仮にフィールドの内容が空白でも画面にフィールドが表示されているならサーバーはクライアントにフィールド内容を送っているのだと思います。
ただ、これらはサーバーが検索や関連レコードの連結処理をしてくれている環境でのことなので、１台のPCで完結している場合は総レコード数や対象レコード数の影響が大きくなるのかもしれません。
計算フィールドで検索しない限り、レイアウトの表示やポータルでの抽出に
目立った差はないということでしょうか？レイアウトを開くたびに再計算されるのでやはりレコード数が多くなると
なかなか表示されない、ということがあるでしょうか？
対象レコードに計算フィールドが含まれている場合もだめなんですかね？
計算フィールドというか、索引が作成されているかどうかですね。
対象レコードに計算フィールドが含まれていても、そのフィールドが画面に表示されるフィールドに関係ないならその計算は実行されない感じです。
ところどころ確信がないので曖昧ですみません。
Offline
対策としてエリア情報用の専用テーブルを作成し、定期的に元のテーブルから未登録のエリア情報を専用テーブルに追加する方法を採りました。
これは適宜手動でコピー、インポートされているのですか？
それにしてもやはり値一覧の対象が多いと遅くなるんですね
対象レコードに計算フィールドが含まれていても、そのフィールドが画面に表示されるフィールドに関係ないならその計算は実行されない感じです。
例えばリレーション、ポータルなどで100あるレコードの中から10を取り出したとします
すると再計算されるのは10だけ、ということでしょうか？
非保存の計算フィールドでフラグ処理やSUMしている場合なども、その10レコードに関係するものだけ再計算されて、
90のレコードは再計算されないということでしょうか？
Offline
再計算は、表示対象となるもの（それに関連するフィールドも含む）のみです。それ以外は再計算されません。
値一覧も、フィールドの値を使用、の対象フィールドに索引が作ってあれば、そんなに時間はかからないはずです。値一覧の項目数が多くなると、ソートに少し時間がかかるかかる可能性はありますね。
Offline
IDや日付などでリレーション先から該当するレコードを取得するとき、
一度全レコードを読むことになると思うのですが
計算はされずに、該当するレコードが抽出された時点で再計算されるのですか？
また、
ポータルでも、ポータルに呼び出されたあとに再計算されるのでしょうか？
Offline
全レコードは読み出されません。推測ですが、索引テーブルのみが読み込まれているようです。
読み込まれるのは、表示するフィールドです。その時点で計算が必要なものについて、再計算されます。
ポータルでは、索引を読み込みソートされています。それ以外は同じです。
Offline
対策としてエリア情報用の専用テーブルを作成し、定期的に元のテーブルから未登録のエリア情報を専用テーブルに追加する方法を採りました。
これは適宜手動でコピー、インポートされているのですか？
データテーブルに新しいレコードが入力またはインポートされた後に実行するスクリプトの形で実装しています。
テーブル：D （データテーブル）
┣都道府県
┗市区町村
テーブル：A （エリア情報テーブル）
┣シリアル
┣都道府県
┗市区町村
リレーション
D::都道府県＝A::都道府県
and D::市区町村＝A::市区町村
上記構成でDにデータを入力後、Dに対して
レコードを対象外に
フィールド設定[A::シリアル;"*"]
で検索すると、まだAに登録されていないものだけ抽出できます。
後は都道府県・市区町村でソートして上から順に前回と違う場合だけ
フィールド設定[A::都道府県；D::都道府県]
フィールド設定[A::市区町村；D::市区町村]
としてDからAにコピーするだけですね。
新しいデータが何万件もあると全てシークする分それなりに時間は掛かりますが、さほど頻度が高いわけでもないので妥協できる範囲でした。
検索時点で同値内連番の1だけ抽出などの工夫をすればもう少し効率いいかもしれません。
再計算関係の話についてはShinさんの回答に付け加える点はありません。
ちょっとした中間計算用のフィールドが欲しいときなどでも、メンテナンスや索引化によるサイズの問題はともかくパフォーマンスの点からフィールドの追加を躊躇う必要はないと思います。
Offline
郵便番号のデータを使えば、もっと管理がらくだと思いますが。
それと、大きなファイルは、たまに最適化保存でメンテナンスしてあげる事をお勧めします。アクセス速度が格段に変わりますよ。
Last edited by Shin (2017-07-24 16:25:57)
Offline
横から失礼します。
FMSの速度向上には、PCスペックでは何を重視すれば良いのでしょうか？
当然、i3よりi7、4GBより16GB、HDDよりSSDと総合的にあげていけば効果は出るかと思いますが、まずはココをという部分はありますでしょうか？
現在、i5、メモリ8GB、HDD500GBでFMS16が動作しているのですが、同時接続数が増えていくとやはり重くなっていきます。40台ほど
しかし、PCの負荷をみると、CPUやHDDは十数％の動作、メモリも半分ほど余裕のある状況です。
ネットワークも1Gbpsで実測0.8Mbpsほど出せるのは確認しました。普段、数十Mbpsでアクセスしています。
スペック的にはかなり余裕がありそうなのですが、何故でしょうか？
ソフトの作り方と言われればそれまでなのですが・・・
もし、お分かりになればお返事いただける幸いです。
Offline
郵便番号のデータを使えば、もっと管理がらくだと思いますが。
いえ、簡略化のために市区町村としただけで、実際には違うものなんです。
postデータは住所情報のために利用していますが便利ですね。
それと、大きなファイルは、たまに最適化保存でメンテナンスしてあげる事をお勧めします。アクセス速度が格段に変わりますよ。
最適化はファイル修復時などに使うものだとばかり思っていました。
早速今週末にでも試してみようと思います。
i5、メモリ8GB、HDD500GBでFMS16が動作
HDDの読み書きがボトルネックになっている気がします。
まずはHDDをSDDに変えるのが一番効果あるのではないでしょうか。
Offline
micさん、ありがとうございます。
ストレージですか。
HDDと言えど、十数％の稼働率なら大丈夫かと思っていましたが、そうでは無いのですね。
今のサーバは、まだ保守期間なのでさわれませんが、それが切れるか次を買う時にはSSDにしてみます。
最適化保存しますと、はじめてだと2割ほど容量節約できるかもしれません。（画像が入ってると、率はそこまで良くありませんでしたが）
その後、速くなりましたね。
1~2年に1度のペースで私はやってます。
Offline
HDDの内部のフラグメントの影響が大きいと思いますが。
Offline
Pages: 1
[ Generated in 0.006 seconds, 9 queries executed - Memory usage: 565.92 KiB (Peak: 586.46 KiB) ]