前回は計算フィールドを使用することによる、パフォーマンスの低下例を紹介した。

便利な機能だが、使い方を誤ると大幅な性能低下をひきおこす計算フィールド。このほかに使い方を気をつけなければならないフィールドにもうひとつ「集計フィールド」がある。今回はこの集計フィールドに焦点をあて、集計フィールドを使うにあたり注意するべき要点を紹介しよう。

集計フィールドとは

集計フィールドは、FileMaker独自の色が強いフィールドタイプのひとつ。フィールド作成時に集計区分(合計, 平均値, カウント, 最小値, 最大値, 標準僅差, 合計に対する比)と集計対象のフィールド・そのほかのオプションを選択するだけで、簡単に集計結果を得ることができる。

わずかな操作でさまざまな切り口の集計ができるので、一覧画面の合計値や帳票の作成時にお世話になっているデベロッパも多いことだろう。

集計フィールドのオプション画面。わずかな操作でさまざまな切り口の集計値を算出できる

さて、この集計フィールド。計算フィールドと同様、Webアプリケーションにおいては使う際に注意が必要だ。

集計フィールドは索引を作らない計算フィールドと同じく、表示する場面で計算がおこなわれる。レコード数がすくないテーブルでは体感差がないが、数万や数十万の規模になってくると目に見えて性能が低下してくることがわかる。

集計中の表示ダイアログ。計算フィールドと同様、ある程度の規模のFileMakerアプリではこのダイアログメッセージを目にした方も多いことだろう

集計フィールドの表示には、FileMaker Pro上でもそこそこの処理時間がかかる。レコード数が多いと集計数値を出すだけで数秒待たされることも。さらにリスト表示といった、一度に複数レコードを表示する画面で集計フィールドが使われていた場合には表示完了までに数分待たされることもある。Web公開で利用する場合も同じで、「レコード数が多い」「配置されている集計フィールドの数が多い」とパフォーマンスに甚大な影響がでる。

ためしに集計フィールドを配置することによる性能低下の例を紹介してみよう。レコード数は1,000件と10,000件。異なる集計法のフィールドをそれぞれ組み合わせてレイアウトに配置し、処理時間を計測する。

データベース情報は次のとおり。

テーブル情報

  • summary_test_1000: レコード1,000件を登録
  • summary_test_10000: レコード10,000件を登録
  • summary_test_100000: レコード100,000件を登録

フィールド情報(3テーブル共通)

  • st_num_1, st_num_2, st_num_3: 数字フィールド。全レコードに「Random * 100」の結果を格納
  • st_num_1_summary, st_num_2_summary, st_num_3_summary: 集計フィールド。3つの数字フィールドの合計を計算する

レイアウト情報

  • 集計フィールドのみを配置したものを、1テーブルに3レイアウトずつ用意

作成したフィールド情報。3テーブルにまったく同じフィールドを追加している

各数字フィールドにはフィールドの「入力値の自動化」機能をもちいて、Random*100の結果がレコード作成時に格納されるように設定

作成した全9レイアウト。各テーブルにおいて、集計フィールドを1～3つずつ配置している

作成した全9レイアウトにたいして、これまでと同様Apache Bench(ab)を実行し、その結果を比較する。

% ab -n 10 -c 1 -A admin:admin "http://localhost/fmi/xml/FMPXMLRESULT.xml?-db=fm_tune.fp7&-lay=(レイアウト名)&-max=1&-find"

コマンドの結果より、Time per requestを表にまとめた。

  配置した集計フィールドの数
1 2 3
1,000レコード 87.517 [ms] 95.445 [ms] 111.996 [ms]
10,000レコード 616.121 [ms] 736.982 [ms] 866.044 [ms]
100,000レコード 6117.105 [ms] 7369.087 [ms] 8597.461 [ms]

レコード数が多ければ多いほど、集計フィールドをたった数個レイアウトに配置するだけで性能低下が起こることがおわかりいただけただろうか。とくに100,000件のレコードを登録している場合、たったひとつの集計フィールドの値を取得するだけで6秒も待たされることになる。同時1アクセスでこの結果なので、大量のレコードが登録されるアプリケーションにおいて、集計フィールドを実際の運用で使える場面は限られてきてしまう。

限られたレコード数で集計フィールドを使う分には影響が小さいが、可能な限りパフォーマンスは妥協せず高めたいところ。必要のない画面では、レスポンスレイアウトを指定し、かならず集計フィールドを置いていないレイアウトを使用するように注意しよう。

Webアプリで集計をおこないたい場合

どうしてもWebアプリ上で大量のレコードを対象とした集計をおこなたい場合は、集計・計算フィールドを使う以外の実装を検討してみよう。

  1. PHP側で集計を実装する
  2. あらかじめ集計のパターンを予測し、FileMaker側で集計数値を数字フィールドで事前に格納しておく

1案で実装をする場合は、FX.phpで-maxを限界値にセットし、foundCountや取得した結果をarray_sum()などの関数で集計をおこなう。PHPの各種関数が使えるという点で柔軟な集計をおこなうこともできるが、こちらもレコード数が増えると処理時間と負荷がかかる。ここでは2案の方法を推奨したい。次回は、この2案の「中間テーブルを用いた集計の実装」を取りあげて紹介しよう。