ログインあたり3.85KBのオーダーで、既存のデータベースレコードに追加のログイン情報を追加します。
これには2つの懸念があります。
1）ログインごとに追加されるオンザワイヤデータが多すぎませんか？
2）これは、ログインごとにデータベースに保存する余分なデータが多すぎますか？
今日のテクノロジーを考えると、これらの有効な懸念はありますか？
バックグラウンド：
具体的な使用量はありませんが、月平均約5,000回のログインがあります。ただし、1秒あたり1000ではなく、1か月あたり1000の数十で、より大規模な顧客に拡大したいと考えています。
米国（私たちの市場）では、ブロードバンドは60％の市場で採用されています。
1か月あたり最大80,000のログインがあるとすると、データベーステーブルに1年あたり最大3.75GBを追加することになります。
MySQL、PostgreSQL、SQLServer、OracleなどのまともなRDBMSを使用している場合、これは笑える量のデータとトラフィックです。数年後、あなたはそれのいくつかをアーカイブすることを検討し始めたいと思うかもしれません。しかし、その時までに、アプリケーションがどのようになるか誰が知っていますか？
パフォーマンスのボトルネックに遭遇しないように、このデータをどのようにクエリするかを検討することが常に重要です。それらの詳細がなければ、私はその側面について非常に有益にコメントすることはできません。
しかし、あなたの懸念に答えるために、心配しないでください。常に先を考え続けてください。
何人のユーザーがいますか？どのくらいの頻度でログインする必要がありますか？彼らは速い接続、または湿った紐の断片にある可能性がありますか？誰かがログインするたびに、またはユーザーアカウントごとに、実際に3.85Kを追加しているということですか？データをどのくらいの期間保存する必要がありますか？それはあなたにどのような利益をもたらしますか？すでに保存しているデータの量とどのように比較しますか？（つまり、データの大部分はこの新しい部分によるものですか、それとも海に落ちるのでしょうか？）
要するに-これは非常に文脈に敏感な質問です:)
最近のストレージとハードウェアが非常に安いことを考えると（もちろん比較的言えば）、これは問題にはならないはずです。明らかに、データが必要な場合は、データが必要です。複数の場所へのレプリケーションを使用して、追加されたデータがネットワークを介して遠くまで移動する必要がないようにすることができます（西海岸や東海岸のサーバーなど）。データを状態ごとに分けてテーブルのサイズを最小化することでデータを管理できます（銀行が行うのと同様に、ログインプロセスの一部として状態を選択して、適切なデータストアを参照するようにします）。水平分割を使用して、テーブルごとの数またはレコードを最小限に抑え、クエリを高速に保つことができます。大規模なデータを最適化する方法はたくさんあります。このデータに対して多くの読み取りを行う予定がある場合は、Luceneにもチェックインしてください。
今日の平均的なサーバーテクノロジーに関しては、問題はありません。サーバーテクノロジに関しては、問題になる可能性があります。あなたはより多くの情報を提供する必要があります。
ストレージに関しては、これはピーナッツですが、最終的には古いデータをアーカイブまたは破棄する必要があります。
ネットワーク（？）トラフィックに関しては、これはサーバー側ではそれほど多くありませんが、Webサイトがロードされ、大部分の顧客にとって機能しているように見える速度に影響します。多くの人がブロードバンドを利用していますが、誰かがエッジやモデムで試してみるか、ビットトレントを多用しているときに、サイトが遅く見えたり、完全に誤動作したりして、Web全体で大きな苦情が寄せられます。それは重要ですか？あなたのユーザーが本当にあなたのサービスを必要としているなら、彼らはきっと待つことができます、あなたが新しいツイッターを開発しているなら、ページの読み込み時間の増加はほとんど受け入れられません。