ここ最近、ブログの改修をしていく上でかなり悩んでいるテーマになっている。
現在は分割取得にしているが、改めて自分なりに調べたり考えたりした際に一括取得にすることもかなりありだと思ってきている。
その理由は自分の知見を改めて整理していこうと思う。
※繰り返しますが個人の経験上の知見です。間違いや参考文献などがあればアドバイスください🙇♂️
一括取得 .... データの更新が少なく、データ量が膨大ではない場合に適している。逆に条件に当てはまらない場合は取得データやシステム全体の負荷など大きくパフォーマンスの低下につながる可能性あり。
分割取得 .... データ更新が頻繁で、データ量は関係なし。ただしオーバースペックになりがちであり不必要にパフォーマンスを低下に繋げる。
結局はプロジェクトのスケーラビリティによるところが大きい。
おおよその必要な取得データ量を把握することができていればむしろ一括取得が優れているかもしれないが、下手に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を利用した分割取得となっている。
もちろんページごとのデータ取得を行うことになるので一括取得に比べてデータの取得回数が増えることや一覧ページを作成しなければいけないことや関連テーブルのデータも一括取得することができないなどのデメリットはあるが、今後のスケーラビリティを考えると現在の規模では一括取得でも余裕でデータ量を持て余すぐらいだと思っている。
やがてこのブログが発展してデータ量が莫大になりパフォーマンスの低下の可能性を踏まえると最初から分割取得にしておき、少しでも現状以上のパフォーマンス低下を防ぎたいと考えている。
何度も言うが、もちろん現在の規模ではパフォーマンスがむしろ低下していることはわかるが長期的な目線で見れば分割取得の方へ変更すると思うので論理的に考えるなら現状のままでいいと思っている。
取得時のメモリ使用量がパフォーマンスの低下につながるようだったら自動で分割取得に切り替えるみたいなことができればいいのだが、取得自体のタイミングを考えると絶対に無理。
現在は今後の発展も踏まえて分割取得を選択してページ数なども増やしてしまっているが、開発のフェーズに応じてまた見直す機会を作ることができればと思う。