Sota Tech Blog.

データ取得について考えてみる投稿日: 2023年 3月11日

一括取得か分割取得か

ここ最近、ブログの改修をしていく上でかなり悩んでいるテーマになっている。
現在は分割取得にしているが、改めて自分なりに調べたり考えたりした際に一括取得にすることもかなりありだと思ってきている。
その理由は自分の知見を改めて整理していこうと思う。
※繰り返しますが個人の経験上の知見です。間違いや参考文献などがあればアドバイスください🙇‍♂️

一括取得

メリット

  1. 取得したデータを一度に処理することができるため、途中でのデータ加工の煩わしさを軽減することができる。
  2. 処理したデータを容易に変更することができたりするので落とし所によってはどのようにデータをいじるかどうかという点ですごくコード的にも書きやすい
  3. 当然だが分割に比べてデータ取得回数が相対的に少なくなるため、ネットワークやAPIサーバーの負荷を減らすことにつながる。
  4. データの取得という観点でだけで考えた場合にオフラインでの取得だった場合は一度に全てのデータを取得することができるため、アクセスの幅に大きく影響する。(ファイルをまとめたZIPフォルダをダウンロードしたりするのがいい例になっているかもしれない)

デメリット

  1. 取得するデータの量によっては、ネットワークやAPIサーバーに負荷を大幅に増加させてしまうことにつながることがあり結果的に処理時間が長くなってしまうことがある。
  2. 利用しているメモリの使用量が増加してしまうことによって、システム全体のパフォーマンスにも影響してしまう場合がある。長期的な目線で考えたときにかなりのメモリ大幅増加になりかねない。
  3. 頻繁なデータ更新を行うことになった要件な場合は、取得した時点でのデータが最新のものではない可能性になっていることがある。

分割取得

メリット

  1. 一度にデータを取得するわけではないので、いくらデータ取得が膨大であろうと関係なしに分割してくれるのでメモリ消費量をおさせることができる
  2. これも当然だが頻繁にデータ更新される場合でも、最新のデータを取得できる
  3. ネットワークやAPIサーバーに負荷がかからないことが考えることができるようになり、結果的にシステム全体のパフォーマンスに影響を与えにくい。
  4. APIサーバー側で、一度に大量のデータを処理するためのリソースやメモリなどが必要とならなくなるため、スケーラビリティに優れる。

デメリット

  1. データ量によっては複数のリクエストを送ることになるため処理時間が増加する可能性がある
  2. データの処理や取得が複雑になりがち
  3. 分割取得時の差異により、正確なデータを取得することができない可能性がある。(滅多になるとは思うが)

使いどころ

一括取得 .... データの更新が少なく、データ量が膨大ではない場合に適している。逆に条件に当てはまらない場合は取得データやシステム全体の負荷など大きくパフォーマンスの低下につながる可能性あり。
分割取得 .... データ更新が頻繁で、データ量は関係なし。ただしオーバースペックになりがちであり不必要にパフォーマンスを低下に繋げる。
結局はプロジェクトのスケーラビリティによるところが大きい。
おおよその必要な取得データ量を把握することができていればむしろ一括取得が優れているかもしれないが、下手にlimitで大量取得するぐらいなら分割取得することが無難であると思う。

// デフォルト値...10 - limitパラメータがある場合はそれを利用なければデフォルト値
------------------------------
// 取得するデータ件数 ... 10
GET /api/data?limit=10 ... OK
GET /api/hoge ... デフォルト値が10のため - OK
GET /api/hoge?limit=100 ... 必要なデータ数は10でいいのに無駄に90件分の処理をしてしまう
------------------------------
// 取得するデータ件数 ... 100
GET /api/data?limit=10 ... 100の10件のみとなってしまうため分割取得
GET /api/hoge ... 上記と同じ理由
GET /api/hoge?limit=100 ... OK

迷っている理由

一括取得は使いどころの条件を満たせばとても強力となりうる武器になっており、自分が開発しているブログなどの小規模かつ頻繁に更新頻度が高くないような要件ではぴったりな方法だと考えている。
また、一括取得に変更することで全てのページの最初のルートページのデータ取得時に関連のデータをすべて取得することができるので一覧ページが必要ではないことや現在のオブジェクトの総数を計算することができるといった様々なメリットや単純にコード的にも論理的に考えてとても開発しやすいものになるということは間違いない。
それを知った上での現在の開発についてはoffsetとlimitを利用した分割取得となっている。
もちろんページごとのデータ取得を行うことになるので一括取得に比べてデータの取得回数が増えることや一覧ページを作成しなければいけないことや関連テーブルのデータも一括取得することができないなどのデメリットはあるが、今後のスケーラビリティを考えると現在の規模では一括取得でも余裕でデータ量を持て余すぐらいだと思っている。
やがてこのブログが発展してデータ量が莫大になりパフォーマンスの低下の可能性を踏まえると最初から分割取得にしておき、少しでも現状以上のパフォーマンス低下を防ぎたいと考えている。
何度も言うが、もちろん現在の規模ではパフォーマンスがむしろ低下していることはわかるが長期的な目線で見れば分割取得の方へ変更すると思うので論理的に考えるなら現状のままでいいと思っている。

感想

取得時のメモリ使用量がパフォーマンスの低下につながるようだったら自動で分割取得に切り替えるみたいなことができればいいのだが、取得自体のタイミングを考えると絶対に無理。
現在は今後の発展も踏まえて分割取得を選択してページ数なども増やしてしまっているが、開発のフェーズに応じてまた見直す機会を作ることができればと思う。

匿名でコメント