カテゴリー内の他の記事

kintoneレコード一括取得の速度とレコードデータサイズの関係性

フォローする

はじめに

kintoneは、レコードに保存されているデータサイズが大きくなるほど、レコード一括取得(レコード一括取得REST API)の実行時間が長くなる特性があります。

この記事では、kintoneの内部処理の説明を交えつつ、レコード中のデータサイズとレコード一括取得の実行時間の関係について説明します。
また最後に、レコード一括取得で速いレスポンスが必要なアプリを作る方法について説明しますので、kintoneアプリを作る際の参考にしていただければと思います。

レコード一括取得時のkintoneの処理概要

まずは、レコード一括取得APIを実行した時に、kintoneの内部でどのように処理されるのかを見てみましょう。

システム構成

以下は、kintoneのシステム構成を簡単に表した図(※)です。
図にあるとおりkintoneは、APサーバ(アプリケーションサーバ)とDBサーバ(データベースサーバ)と呼ばれる2種類のサーバによって、サービスを提供しています。

※ cybozu.com及びkintone共に、実際はもっと多くの役割を持ったサーバがいますが、本記事の内容とは関係ないため省略しています。

 

処理の流れ

クライアントからkintoneのレコード一括取得が実行時された場合、次の図のように処理が実行されます。

kintoneでは、レコードに含まれるデータのサイズが大きくなると、上記の(3)DBサーバからのレコードデータ取得~(5)クライアントへの応答、
で時間がかかるようになるため、レコード一括取得の実行時間が長くなる傾向があります。

なお、『取得するフィールドを指定することで、kintoneのレコード一括取得の時間を短縮する』で、
フィールドを指定するとレコード一括取得の処理時間が短縮できることを説明しました。
確かに、フィールドを指定するとAPサーバから返されるデータ量が減るため、(4)APサーバからの応答~(5)クライアントへの応答、での通信時間を削減することができます。

しかしフィールドを指定した場合でも、kintone内部では(3)DBサーバからのレコードデータ取得で、一度レコード中の全フィールドのデータを取得します(※)。
そのためkintoneでは、レコードサイズが大きくなると、レコード一括取得の処理時間が長くなってしまうのです。

※ 細かなアクセス権の評価や、動的なフィールド構成変更を実現するために、一度、全フィールドのデータを取得する必要があります!

測定

それでは実際に、レコードに含まれるデータサイズと、レコード一括取得APIの処理時間の関係を測定してみましょう。

アプリ

今回は、以下のようなアプリを用意しました。

文字列(複数行)フィールド×10個を持ったアプリを用意し、各フィールドに半角英数1万文字の文字列(レコード中の文字数の合計は10万文字)を
保存したレコードを登録しておきます。
そして、レコードの取得件数を1件~10件と変化させて、レコード一括取得の実行時間を調べてみました。

また、全フィールドを取得した場合と、レコード番号だけを取得した場合の違いも調べてみます。

測定結果

結果は以下のとおりです。

青が全フィールドを取得した場合、オレンジがレコード番号だけを取得した場合のグラフになります。
測定結果から、どちらもレコード中のデータサイズに比例して実行時間が長くなることがわかりました。

また、全フィールドを取得した場合(青)と、レコード番号だけを取得した場合(オレンジ)を比較すると、フィールドを指定して取得するデータサイズを減らすことで、
リクエストの実行時間をある程度削減できることがわかります。

それでも、レコード中のデータサイズが[MB]の単位になると、人が体感できるほど実行時間が長くなってしまうことがわかりました。

使い方の提案

測定結果から、レコード中のデータサイズに比例するように、レコード一括取得APIの実行時間が長くなる傾向があることがわかりました。
逆に考えると、レコード一括取得で速いレスポンスが求められるアプリについては、レコード中のデータサイズは小さくした方がよい、ということが分かります。

例えば、ユーザの操作をきっかけにして、レコード一括取得によりkintoneアプリからデータを取得し、取得したデータを画面に表示する、
といったS/Wを作成する場合には、なるべく速いレスポンスが求められると思います。
そういった場合は、アプリに保存するレコードのデータサイズについても、確認いただければと思います。

その上で、速いレスポンスが求められるアプリに対して大きなデータを関連付けたい、となった場合は、以下のような方法が考えられます。

方法(1): 長い文字列を添付ファイルにする

1つ目の方法は、長い文字列を添付ファイルにすることです。

レコードに添付ファイルを保存する場合、ファイル本体はレコードとは別に管理されます。
レコード中には、添付ファイルを識別するためのファイルキー(※)が保存されるため、レコード中のデータを小さくすることができます。
そのため、特定の文字列(複数行)フィールドに長い文字列が保存されるようなアプリの場合、
その文字列を添付ファイルにすることで、レコード一括取得の実行時間を短縮できる可能性があります。

※ "c15b3870-7505-4ab6-9d8d-b9bdbc74f5d6"のような、cybozu.com内でアップロードされファイルを識別するための文字列。

ただし、添付ファイルとした場合は、以下のように閲覧や変更時の手間が増えるといった、デメリットが考えられます。

  • 添付ファイルの内容を閲覧する場合、添付ファイルダウンロードが必要になる。
  • 添付ファイルの内容を変更する場合、添付ファイルの差替えが必要になる。

添付ファイルにした場合の注意点

なお、添付ファイルにした場合でも、アプリの変更履歴を有効にしていると、 添付ファイルの変更履歴も残すことができます。
ただし、変更履歴を有効にした状態で添付ファイルの差替えを繰り返すと、ディスク使用量が急増する可能性があるので注意が必要です。

上の図は、添付ファイルを差換えた時の変更履歴ですが、赤線で示した箇所から、変更前後のファイルをダウンロードすることができます。

このように、変更履歴を有効にしている場合、kintoneでは変更前後の添付ファイルが保存されます。
そのため、添付ファイルを更新するたびに、ディスク使用量が増加していきますので、ご注意ください。
(上記の場合は、変更前のファイル(10[MB])、変更後のファイル(10[MB])の計20[MB]のデータが保存されたままになります。)

なお、ディスク容量についての注意は、以下のQ&Aに記載がありますのでご一読ください。

また、ファイルのバージョン管理が必要な場合は、サイボウズOfficeGaroonのファイル管理機能を利用する方法もありますので、そちらもご検討ください。

方法(2): 複数のアプリを関連レコード一覧で関連付ける

もう1つの方法として、アプリを複数用意して、関連レコード一覧の機能で関連付ける、といった方法も考えられます。

例えば、以下の図のように、レコード一括取得用と大きなデータ用の2つのアプリを用意し、関連レコード一覧の機能で関連付けます。

上記のようにした場合、レコード一括取得用アプリには、参照先のレコードのレコード番号と小さなデータだけが保存されるため、
レコードのデータサイズを小さくして、レコード一括取得の実行時間を短くすることができます。

ただし、関連レコード一覧を使用した場合も、以下のように更新の手間が増えてしまうといったデメリットがあります。

  • レコードの作成や変更をする場合、複数のアプリのレコードに不整合がでないように更新する必要がある。
  • REST APIでレコードのデータを取得する場合、複数のアプリからそれぞれデータを取得する必要がある。

方法(1)、方法(2)共に、レコード作成や変更の手間が増えてしまいますが、レコード一括取得の実行時間短縮に効果がありますので、ご検討ください。

おわりに

この記事では、kintoneアプリのレコードに保存されているデータサイズが大きくなるほど、レコード一括取得APIの実行時間が長くなることを説明しました。
速いレスポンスが求められるアプリを作成する場合は、レコードに保存するデータサイズについても注意いただければと思います。

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

記事に関するフィードバック

直接的に記事と関連がないご質問はcybozu developer コミュニティをご活用ください。

ログインしてコメントを残してください。