その昔。
私より少し上の世代から聞いた話です。
当時パソコンはフロッピーディスク起動でした。
そのため、動かすソフトウェアは実行モジュール一式を一枚のフロッピーに入れる必要があります。
そのサイズ、約1MB。
時おり、実行モジュール一式がどうしても1MBを超えてしまい、フロッピーディスク一枚に入りきらないというようなことが起こります。
困った先輩たち、一部モジュールをアセンブラで書きなおしてサイズを小さくする、などという涙ぐましい努力を重ねたそうです。
そんな世代から教えを受けた上に、まだハードウェアが今よりずっとショボかった時代に駆け出しだった私たちの世代には、どうも
「データ量には気を付けろ」
という割と強い強迫観念があります。
格納、取得、送信するデータは最小限に。というのがその主旨です。
件数だけではなく、レコード長や項目数も含めて。
データベースもネットワークもプログラムステップも、扱うデータ量が多ければそれだけ資源を使います。
仕様上必要なら仕方ありませんが、不必要なデータや、過剰な余白などの無駄なエリアを持ち込むのはご法度でした。
あれから時代は変わりました。
ハードウェアもネットワークも凄まじく進化した結果、今の若いITエンジニアの皆さんは、私たちの世代ほど「データ量」に神経を使わなくても済むようになりました。
以前も書きましたが、それ自体は技術進歩であり、効率化の観点で良いことです。
でも、それでも起こるのです。
「データ量増加に伴うレスポンス低下」が。
本稼働後数年経過した情報システムにはデータが蓄積されます。
当然、最初からそれを見込んだ設計にしておくことが必要なのですが、アーキテクチャやフレームワークがそもそもあまりシビアな設計を要求しなくなったため、ややもすると「無駄なデータの蓄積や、やり取り」が徐々に増加するような情報システムになってしまうことがあります。
本稼働中に「運用に堪えないようなレスポンス低下」が頻発してしまうと、その対応はとても大変です。設計の一部見直しからやらないと根本解決にならない、などということもあります。
若いITエンジニアの皆さん。
データ量、気を付けてくださいね。