私は、1 つのデバイスが毎年約 200 万個の GPS ポイントをプッシュできるライブ追跡システムを扱っています (つまり、5 秒ごとに 1 ポイント、365 日にわたって 8 時間動作します)。これが世界規模で数千のデバイスで動作する場合、これは年間数十億のレコードになります。
SQL Server で処理できることはわかっています。しかし、同時書き込みを実行する何千ものデバイスでライブ トラッキングを実行できる必要があります。いくつかのデバイスでは問題なく動作しますが、多くの追跡サイトを開くと、CPU を集中的に使用することがわかります。
私はしようと計画しています：
代替案はありますか？
投稿した情報を考えると、アーキテクチャに問題はありません。しかし、悪魔は細部に宿ります。1つは、DBがどれだけうまく設計されているかに大きく依存します。それは、クエリ、データベース インデックス、トリガーなどがどれだけ適切に作成されているかに依存します...
また、これがあらゆる種類のモバイル デバイスである場合は、従来のソケット ベースのコネクタを使用しないでください。リモート サーバーへの安定した tcp 接続に依存することはできません。REST などのステートレス アーキテクチャを使用して、データを公開/書き込みする必要があります。REST は .NET で非常に簡単に実装できます。これにより、スケールの難しさがデータベースから Web サーバーに移動するはずです。
最後に、サーバーで行われる作業を最小限に抑えるために、何らかのキャッシングまたはバッファー プール システムを実装して、読み取り用の各デバイス上のデータを維持し、データを中央サーバーに送信するための書き込みキャッシュを作成します。サーバーからのトランザクション管理で安定した tcp 接続に依存できないことを考えると、書き込みキャッシュは非常に重要です。書き込まれるデータのキャッシュ、つまり (キュー) を維持し、サーバーから書き込まれたデータを受信したという確認が得られたら、キューをポップする必要があります。データとデータ接続があるときはいつでも、キューをポップする必要があります。ただし、確かな情報を提供したり詳細を説明したりする前に、お客様の要件について詳しく知る必要があります。