ルックアップフィールドの設置有無による、レコード一括更新パフォーマンス比較 – cybozu developer network

（著者：サイボウズ性能検証担当）

Index

はじめに
検証実施
検証結果
考察
まとめ

はじめに

ルックアップフィールド（以下、ルックアップ）の値を更新すると、ルックアップ参照元アプリから

データをコピーする処理が発生するので、他のフィールドよりもレコード更新に時間がかかります。

このため、kintone REST API を利用したレコードを一括更新する処理が遅延する場合があります。

そこで、本記事では、ルックアップが設置されているアプリとルックアップが設置されていないアプリで、

レコード更新時間にどのような違いがあるのか、検証を実施してみました。

検証実施

今回は、以下の条件で検証を行いました。

検証環境

2021年 7月版
cybozu.com 検証環境

検証端末

CPU：Intel(R) Core(TM) i5-7300U CPU @ 2.60GHz 2.71 GHz
メモリ：8.00 GB
OS：Windows 10 Enterprise

検証条件

アプリストアで公開されている「営業支援パック」に含まれるアプリを利用し、以下3つのアプリを用意しました。

案件管理アプリ（ルックアップを設置するアプリ）
- レコード数：100,000件
- ルックアップ設置数：1個
- ルックアップ参照元アプリからデータをコピーしてくるフィールド数：3個
- アクセス権：設定なし
顧客管理アプリ（ルックアップ参照元アプリ）
- レコード数：100,000件
- アクセス権：設定なし

案件管理アプリ（ルックアップを設置しないアプリ）
- レコード数：100,000件
- ルックアップ設置数：0個（ルックアップの代わりに、文字列フィールドを利用）
- アクセス権：設定なし

検証内容

kintone REST API のレコードの更新（PUT）を実行し、処理にかかった時間を測定します。

以下3つの検証パターンを実施します。

パターン1：ルックアップを設置しないアプリにて、日付フィールドを対象にレコード一括更新を行う
パターン2：ルックアップを設置するアプリにて、日付フィールドを対象にレコード一括更新を行う
パターン3：ルックアップを設置するアプリにて、日付フィールドとルックアップを対象にレコード一括更新を行う

各パターンで一括更新するレコード数は、1件、50件、100件（※）としました。

※ 一度に更新できるレコードは100件までであるため

計測方法

curl コマンドの「-w」オプションで指定できる「time_total」（全体の処理時間）の値を利用し、測定しました。

例）パターン3でレコード100件更新

$ curl -w "\n%{time_total}\n" -X PUT https://{subdomain}.cybozu.com/k/v1/records.json \
  -H 'X-Cybozu-API-Token: {API-Token-1},{API-Token-2}' -H 'Content-Type: application/json' \
  -d @{json_file_name}

（curl バージョン：7.55.1）

※ 更新内容（アプリID、レコードID、フィールドコード、値など）は、JSONファイルにまとめて記しています

※ APIトークンを利用してルックアップの値を更新する場合、ルックアップ設置アプリとルックアップ参照元アプリの両方のAPIトークンを指定する必要があります

▼cybozu developer network：複数APIトークンを使ってできること

https://developer.cybozu.io/hc/ja/articles/360035992312

検証パターン1～3を3回実施し、その平均値を計測結果としました。

curl コマンドの使い方については、以下リンクもご参照ください。

▼cybozu developer network：curl コマンドで kintone REST API を実行してみよう

https://developer.cybozu.io/hc/ja/articles/360023068751

検証結果

3つの検証パターンの計測結果は、以下のグラフの通りです。

更新レコード件数が増加するにつれ、更新時間も比例して増加するのはどの検証パターンも同じですが、

やはりルックアップを対象にレコード一括更新を行う（パターン3）と、ルックアップ以外のフィールドを対象に

レコード一括更新を行う（パターン1やパターン2）よりも、更新時間の増加率が高くなりました。

さらに興味深いのは、パターン2です。日付フィールドを更新しただけなのに、アプリにルックアップが設置されているだけで

ルックアップが設置されていないアプリのレコード一括更新（パターン1）よりも

更新時間が増加する結果となりました。

考察

パターン3が、パターン1やパターン2よりも、更新時間がかかり、増加率が高くなったのは、

ルックアップを更新することで、別アプリからデータをコピーする挙動が影響しているためです。

また、パターン1とパターン2の相違点は、アプリにルックアップが設置されているかどうかです。

パターン1よりもパターン2の方が更新時間が増加する結果となったことから、

アプリにルックアップが設置されていると、ルックアップを更新しなくても、

ルックアップが設置されていないアプリよりも更新処理に時間がかかることがわかりました。

今回の検証結果では、各パターンの更新時間の差異が1秒未満で、そこまで大きな差が出ているわけではありませんが、

以下のような条件を加えることで、レコード更新時の処理が多くなり、

レコード更新に時間がかかることが想定されます。

レコードのアクセス権を設定する
アプリの登録レコード件数を増やす
ルックアップ設置数を増やす
ルックアップ参照元アプリからデータをコピーしてくるフィールド数を増やす

まとめ

レコード一括更新に時間がかかっていて困っている方は、一度ルックアップを利用しているか等

アプリの構成を確認してみましょう。

また、以下を見直すことで、パフォーマンスが改善される可能性があります。

アプリのレコード件数を減らす（不要なレコードを削除する、アプリを分割する）
レコード一括更新の対象レコードを減らす（全レコード一括更新ではなく、条件を絞る）
アクセス権の設定を減らす（条件をまとめる等）

「レコード更新に時間がかかっていて、バッチ処理が想定時間内に終わらないんだよな・・」など

レコード更新時の処理時間にお困りの方に、この記事が参考になれば幸いです。

このTipsは、2021年7月版 kintoneで確認したものになります。