この要件に合わせてデータベースを設計する方法は?
データは単一のテーブルにあります。かなり高いです。私のアプリは多くのスレッドを開始し、そのすべてがデータベースに接続して同じテーブルを更新します。各スレッドは異なる行を更新しようとします...
ただし、デッドロック シナリオに入ったために更新操作が完了しなかったことが観察されました。後で、これはおそらく SQL Server のロック エスカレーション メカニズムが原因であることがわかりました。
つまり、私の要件は、データベースが単一のテーブルに対する膨大な数の更新操作を処理する必要があるということです。それを処理するための戦略は何ですか？
大規模な更新操作も、I/O によるボトルネックを引き起こすと思います。従来のハードディスクには、1 秒あたりの高回転数で回転する磁気ディスクに格納されたデータを検索する単一のヘッドがあるためです。この分野の技術的進歩を認識していませんが、データベース設計者もこれらの問題について心配しているのではないでしょうか? この種の問題を処理するにはどうすればよいですか？
誰かが私に索引付けが役立つと言いました...しかし、私は信じがたいです...
巨大で大量に数値を提供するといいでしょう。行と更新の合計の比率が大きく、更新がすべてのインデックスに対してかなり均等に分散されている限り、競合はほとんど発生しません。
索引付けが役立つ理由は、他のすべてをロックすることなく、更新する必要がある正確な行を見つけることができるからです。したがって、何千もの同時更新のそれぞれが、1 つの排他ロック、いくつかの排他的インテント、および多数の共有ロックを取得します。インデックス作成が役立つもう 1 つの理由は、各クエリに費やされる時間がわずかであるため、アクティブなトランザクションの数とデッドロックの可能性が減少することです。
更新は単一の行のみを更新するため、完全なインデックスがある場合、それらをデッドロックさせるのは実際には困難です。クラスター化されたキーを除いてすべてを更新し、テーブルにクラスター化されたインデックスのみを持つようにします。複数のインデックスがある場合、更新によって異なるインデックスの一部が取得され、相互にロックアウトされる可能性があります。
本当にディスクに問題がある場合は、RAM を増やす必要があります。負荷が一時的な局所性を持たずに完全にランダムでない限り、ほとんどの更新は RAM から提供され、必要な唯一のディスク アクセスはトランザクション ログを書き込むことです。これは追加のみのログであり、ディスクをシークする必要はありません。無作為に。
したがって、これを最適に行うための一般的な戦略について話している場合は、代理クラスター キーを用意し、更新がこのキーのみをシークし、このキーを更新せず、他のクエリを持たず、このインデックスのみをテーブル。その場合、すべての更新には排他的な行ロックが 1 つだけあり、ページ/エクステント ロックはありません。デッドロックになることはありません。