サーバー上のすべてのユーザー アクティビティの履歴を保持する必要があります。アクティビティには、ユーザーによるデータの送信または 1 つのプロセスが含まれます。アプリケーションは、約 5 万人の同時ユーザー向けに設計する必要があります。
そうするための最良の方法は何でしょう。新しい履歴テーブルを作成すると、最悪のシナリオを考慮して膨大な数の行が入力されませんか?
そうするための最良の方法は何ですか？
類推のために。5 万人の同時ユーザーがいる図書館を考えてみましょう。各ユーザーの書籍のチェックイン、チェックアウトの履歴を保持する必要があります。ユーザー数を考えると手が出ないのではないでしょうか？
詳細が不足していると思いますが、このデータをどうするつもりですか? インデックスなしで保持できますか？または、古いデータをアーカイブできますか (古いデータは 1 時間前でもかまいません)。
SQLDB の書き込みは非常に高速ですが、50K の同時ユーザー アクティビティを設計する場合は、ユーザー アクティビティに対してインメモリ バケットを実行し、X アクティビティで 1 回データベースにフラッシュすることをお勧めします。
最もパフォーマンスが高く、最も安全な方法は、ソース テーブルにトリガーを使用して履歴テーブルを実装することです。これは、セキュリティと実際のビジネス ルールの両方を 1 つのカプセル化されたオブジェクト (テーブル) に実装するための最良の方法です。ただし、サーバー側のルーチンをコーディングするための現在のプラクティスがない場合、またはコードを生成するデータ ディクショナリ システムがない場合は、単一の機能をサーバー側に移行することは現実的ではない可能性があります。
履歴テーブルをコードで実装すると、最も使い慣れた言語と習慣を維持できるという通常の利点がありますが、アプリケーションを介した場合を除き、データベースへのアクセスを許可できないことを意味します。もちろん、ここで一般的なルールを決めることはできません。この決定は、目前の状況と予想される将来のニーズに基づいて設計チームが行うのが最善です。