最大3.5TBのデータを保存し、約1K /秒24時間365日挿入し、指定されていないレートでクエリを実行することもSQL Serverで可能ですが、さらに質問があります：
- これにはどのような可用性要件がありますか？ 99.999％の稼働時間、または95％で十分ですか？
- どのような信頼性要件がありますか？インサートがない場合、100万ドルの費用がかかりますか？
- どのような回復可能性の要件がありますか？ある日のデータを失った場合、それは重要ですか？
- どのような一貫性の要件がありますか？書き込みは、次の読み取りで表示されることが保証される必要がありますか？
私が強調したこれらすべての要件が必要な場合、提案する負荷は、どのようなギミック（シャーディング、パーティショニングなど）を試しても、リレーショナルシステム、任意のシステムでハードウェアとライセンスに数百万のコストがかかります。 nosqlシステムは、その定義上、すべてを満たすことはできません。 これらの要件。
したがって、明らかに、これらの要件のいくつかはすでに緩和されています。 Visual Guide to NoSQL Systemsには、「3つのうち2つを選択」パラダイムに基づいたnosql製品を比較する優れたビジュアルガイドがあります。
OPコメントの更新後
SQL Serverを使用すると、これは簡単な実装になります。
- 単一のテーブルクラスター（GUID、時間）キー。はい、断片化されますが、断片化は先読みに影響し、先読みは重要な範囲のスキャンにのみ必要です。特定のGUIDと日付範囲のみをクエリするため、断片化はそれほど重要ではありません。はい、は幅の広いキーであるため、リーフ以外のページではキー密度が低くなります。はい、フィルファクターが低下します。はい、ページ分割が発生する可能性があります。これらの問題にもかかわらず、要件を考えると、依然として最良のクラスター化されたキーの選択です。
- テーブルを時間で分割して、自動スライディングウィンドウを介して期限切れのレコードの効率的な削除を実装できるようにします。先月のオンラインインデックスパーティションの再構築でこれを強化し、GUIDクラスタリングによって導入された不十分なフィルファクターと断片化を排除します。
- ページ圧縮を有効にします。最初にGUIDによってクラスター化されたキーがグループ化されるため、GUIDのすべてのレコードが隣り合って、ページ圧縮に辞書圧縮を展開する良い機会が与えられます。
- ログファイル用の高速IOパスが必要です。ログが1K挿入/秒に追いつくための低レイテンシではなく、高スループットに関心があるため、ストリッピングは必須です。
パーティショニングとページ圧縮にはそれぞれEnterpriseEditionSQL Serverが必要であり、Standard Editionでは機能せず、どちらも要件を満たすために非常に重要です。
ちなみに、レコードがフロントエンドWebサーバーファームからのものである場合は、各WebサーバーにExpressを配置し、バックエンドにINSERTを使用する代わりに、SENDを実行します。 Webサーバーと同じ場所にあるExpressのローカル接続/トランザクションを使用したバックエンドへの情報。これにより、ソリューションの可用性に関するストーリーが大幅に向上します。
これがSQLServerでのやり方です。良いニュースは、直面する問題がよく理解されており、解決策がわかっていることです。これは、Cassandra、BigTable、Dynamoで達成できるものよりも優れているとは限りません。私は、SQLに似ていないことについてもっと知識のある人に、彼らの主張を議論させます。
プログラミングモデル、.Netサポートなどについては触れなかったことに注意してください。正直なところ、大規模な展開では無関係だと思います。それらは開発プロセスに大きな違いをもたらしますが、一度展開されると、ORMオーバーヘッドがパフォーマンスを低下させる場合、開発がどれほど速くてもかまいません:)