ピティナ開発者ブログ

全日本ピアノ指導者協会のIT担当者が気まぐれにつづる技術系中心のブログです


FileMakerのフィールド定義「索引>デフォルト言語」設定による検索速度の差異比較検証

はじめに

FileMakerのフィールド定義「索引」「デフォルト言語」設定による検索速度検証以前に以下の記事を書いたのがもう半年前なんですね(遠い目)

ptna.hateblo.jp

この時に用意したファイルを応用して、引き続き、FileMaker(以下:FM)での「少しでもパフォーマンスを改善するにはどうしたらいいか?」を考えていきましょう。

今回は、データベース管理 > フィールド定義 > データの格納 > 索引における、「デフォルト言語」によって、検索速度にどう違いがでるのか、というのがテーマです。

われわれは日本人なので、日本語にローカライズされたFMProを使っていますから、フィールド作成時のデフォルト言語の設定は、「日本語」になっています。
ここの設定を変更することができますが、日本語が取り扱えるものとして、他の選択肢としては「Unicode」に限られますね。
なので、「日本語」と「Unicode」のどちらの設定にするかでパフォーマンスの差異を比較してみます。

なお、検証環境は、 FileMaker Pro Advanced 15.02 になります。

準備

まずは前回同様に、一つのテーブルに、二つのテキストフィールド a b を作成します。
それぞれ、フィールド定義で、索引のデフォルト言語を「日本語」「Unicode」に設定します。

f:id:ptna_it:20161014140702p:plain f:id:ptna_it:20161014140704p:plain

a : 「日本語」 / b:「Unicode」 にしました。
また、 a b それぞれに、『方丈記』の「行く川のながれは絶えずして~」を格納してあります、9,394字です。

f:id:ptna_it:20161014141104p:plain

実行条件

この、 a b それぞれのテキストフィールドに対して以下のスクリプトを実行します。

  • 検索文字列は「行く川のながれは絶えずして、しかも本の水にあらず。」
  • 1,000回繰り返す
  • 開始時刻と終了時刻との差分をミリ秒で取得する

実行結果

さて、どうなることでしょう。
こうなりました。

a:「日本語」

f:id:ptna_it:20161014141436g:plain

23秒程度。

b:「Unicode

f:id:ptna_it:20161014141450g:plain

11秒程度。

何と、その差は2倍差!
これは、複数回実行しても縮まらなかったので、その瞬間の検証機の状態いかんには関係なしでした。

考察

索引のデフォルト言語が「Unicode」だと、「前方一致」検索になります。
つまりは、文の途中の文字列は、検索できなくなります。
「日本語」であれば「部分一致」になるので、文の途中の文字列は検索可能です。

例えば、「Unicode」だと「こさかいかずき」に対して「さかい」で検索してもヒットしません、が、「日本語」だとヒットします。
逆に言うと、それはヒットしなくていいよ、という場面もありますね。
(そういう場合、前方一致検索にするよう検索記号を入れつつ……という工夫をしますね)

この「前方一致」か「部分一致」かの差は大きいのかと考えられました。
日本語ローカライズされているFileMakerの内部文字コードSJISのはずですから、索引の「日本語」がSJISだと仮定しても、一般にバイト数はSJISの方がUNICODEより小さいですし。

ただ、「日本語」における検証スクリプト内に検索記号を入れてみつつの実行でも、やはり「日本語」だと22秒以上はかかっていました。
なので、どうしてこれだけの速度差が生じるのかまでは、確定的なことは言えません。

結論

使い分けが大事ですね(汎用性ある結論)
例えば、「姓」や「名」だとか「都道府県名」みたいに、「これは絶対に前方一致であって欲しい」というものであれば、「Unicode」に設定してしまった方が、パフォーマンスが向上します。
逆に、文章のような「部分一致じゃないと話にならない」ものは「日本語」設定必須です。

パフォーマンスを追い求める場合は、ここまでやり尽くしてみると良いでしょう。

(著: Hiroyuki Noguchi)
この記事は現在0人が閲覧中