田口さん
RDBと違って、数万件の処理は苦労しますね。
▼質問１
・kintone 的対策
処理内容は、たぶん何らかの集計だと思われます。一度に数万件の処理は、kintonに向いていません。
対策としては処理内容によりますが、集計処理をトランザクションレコードの追加・更新・削除処理内で行います。
あらかじめ集計用アプリに集計データを作成すると、集計キーが月ならば、集計レコードは数十分の１になります。
・APIのパラレル処理
APIをパラレル処理すること、および必要な項目のみに絞ることで、処理時間の短縮が可能だと思われます。
レコード取得APIのパラレル処理
レコード取得APIの fields 指定の効果
取得条件にルックアップコピー項目や関連レコードの項目を指定して、必要なレコードを絞り込む工夫も有用だと思います。
・外部にRDBでレコードの複製を作成
パフォーマンス優先で考えると、RDBを使うのが手っ取り早いと思われます。
kintoneアプリのレコードの追加・更新・削除イベント処理で、外部RDBも同時に更新します。
▼質問２
処理時間については、データ件数とデータサイズ以外にいろいろ要因がありますので、試してみなければ分かりません。
・レコード取得APIのパラレル処理で、ログに処理時間を記録していますので、同様に試してみてください。
ただ、構造的に無茶なつくりになりますので、やめた方がいいのではないでしょうか。
kintone のメリットがまったく無くなります。
▼質問３
取得時のデータ量を減らすのは、前述のように fields 指定で可能です。
kintone アプリは、RDBの正規化されていないテーブルのようなものだと考えられます。
あまり細かく正規化すると、やはりkintoneアプリの使いやすさが損なわれます。
しくみとしては、ルックアップや関連レコード機能で、アプリ間のリレーションを持っています。
どれも利便性とパフォーマンス、開発コストといろいろ課題があります。
何を優先するかで、対応方法をご検討されてはいかがでしょうか？