データの同時実行.NETソリューションの大量
データの同時実行.NETソリューションの大量
同時大規模なデータ要求の大規模な量は、典型的には、いくつかの条件：
- システムの同時多数のユーザーが
不同功能页面いました查找、更新操作- システム上の同時ユーザーの数が多い
同一个页面，同一个表ことにする大量のデータ查询操作- システムの同時多数のユーザーが
同一个页面，同一个表いました更新操作
最初のカテゴリ：システムの同時多数のユーザーが 不同功能页面 いました 查找、更新操作
サーバーレベルのまず、処理
1.調整手段7アプリケーションプールキューの長さをIIS
1000は元のデフォルトの65535から変更されました。
IISマネージャ> ApplicationPools> [詳細設定]
キューの長さ：65535
2. IIS 7の調整 appConcurrentRequestLimit 設定を
デフォルトでは、元100,000〜5000に変更されました。
c:\windows\system32\inetsrv\appcmd.exe set config /section:serverRuntime /appConcurrentRequestLimit:100000
では%systemroot%\System32\inetsrv\config\applicationHost.config中央のあなたは、この設定を表示できます。<serverRuntime appConcurrentRequestLimit="100000" />
3.付属のmachine.configのprocessModel> requestQueueLimitに調整します
デフォルトでは、元100,000〜5000に変更されました。
-
<configuration> -
<system.web> -
<processModel requestQueueLimit="100000"/>
4. IIS 7のサポート同時接続TCPIPを調整するために、レジストリを変更します。
デフォルトでは、元100,000〜5000に変更されました。
reg add HKLM\System\CurrentControlSet\Services\HTTP\Parameteris /v MaxConnections /t REG_DWORD /d 100000
4は、上記の基本的なサポート10万同時要求を提供しました。
10万人以上への訪問は、あなたが考えることができる場合 程序 と、 数据库 機能モジュールで割った、アクセス圧力を共有する複数のサーバーに展開。
また、それは考えることができます 软硬件负载均衡 。
- ハードウェア負荷分散を直接することができ
智能交换机、処理能力を実現し、システムとは何の関係もありませんが、高価に設定することは困難で、システムは状態の練習とアプリケーションを区別することはできません。だから、ハードウェア・ロード・バランシングがに適用されます一大堆设备，大访问量，简单应用。 - ロードバランシングは、システムソフトウェアおよびアプリケーションに基づいており、より良い状態のシステムやアプリケーションに応じて負荷を分散生きることができるよう。費用対効果。PCLの負荷分散ソフトウェア、LinuxでLVSソフトウェア。
データベースレベルの第二に、プロセス
- 2人のユーザーが同時にページにアクセスすると、ユーザーは他のユーザーが削除されたレコードを持って更新することがあります。
- ユーザとの間の時間にページをロードし、このレコードの内容を変更するために彼の他のユーザーの[削除]ボタンをクリックしてください。
だから、考慮する必要がある数据库锁問題を。
可能な同時実行制御戦略の次の三つがあります。
- 何もしない - 同時ユーザーが同じレコードを変更した場合、最終的な結果が発効（デフォルト動作）によって提出されたように。
- オプティミスティック同時実行（楽観同時実行は） - 同時実行の競合がたまにしか発生し、ほとんどの時間が表示されないことを想定しています。そして、競合が発生したときに、単にユーザーに知らせる、彼は他のユーザーための変更は、保存することはできません作ら私たちは、同じレコードを変更しました。
- ペシミスティック並行（ペシミスティック並行は） - 同時実行の競合が頻繁に発生していることを前提とし、ユーザーはその変更が他の同時動作に起因して保存することはできません言われて容認することはできません。ユーザーがレコードの編集を開始すると、その後、レコードロックは、他のユーザーを防ぐために彼が終了し、変更を提出するまで、レコードを編集したり削除します。
あなたは、同時にデータを変更しようとすると、制御メカニズムを確立する必要が同時に行われ、オペレーティング他のユーザーに、ユーザーの変更を修正するために悪影響を防ぐために。このような状況でのシステムの契約は、「同時実行制御」と呼ばれています。
同時実行制御の種類
一般的には、管理データベースの同時実行性は、3つの一般的な方法があります。
- ペシミスティック並行性制御 - データベースの更新から取得した記録までのこの時間の間、行はユーザに利用できません。
- オプティミスティック並行性制御 - た場合にのみ、実際のデータの更新、線は、他のユーザの魚に使用できません。更新はラインをチェックして、データベースの変更かどうかを判断します。あなたが変更したレコードを更新しようとした場合、それは同時実行の競合が発生します。
- 実際の更新データは、銀行の魚が他のユーザーに利用できない場合にのみ、 - 最後の更新を有効にします。しかし、初期の記録と比較されません更新、レコードを書き換えるかもしれませんが、唯一の書かれたレコードは、他のユーザーが実行した最後のリフレッシュ以降に変更しました。
1.悲観的同時実行
ペシミスティック同時実行は一般的に2つの目的のために使用します。
まず、いくつかのケースでは、同じ競合を持つレコードの数が多いです。データ上に置かれ 锁 、コストは、手数料はより少ない 发生并发冲突时回滚更改 費用がかかります。
事务过程 変更の場合、記録、すべきではない保守式并发 だけでなく、非常に便利。Inventoryアプリケーションは、良い例です。
会社の代表と仮定すると株価をチェックするための潜在的な顧客です。
あなたは、通常、これは通常、「注文」状態としてマークされ、利用可能在庫から削除されますことを、これまでの受注を生成するまで、レコードをロックします。
注文が生成されていない場合は、ユーザーが他の利用可能な正確な在庫数の在庫を確認するように、ロックが解除されます。
しかし、断开構造が悲観的同時実行制御することはできません。连接打开データや更新データを読み込み、そのためにするだけの十分な時間不能长时间地保持锁。加えて、长时间保留锁的应用程序将无法进行伸缩 。
2.楽観的同時実行
オプティミスティック同時実行で、のみ访问数据库のみ设置并保持锁。
これらのロックは、同時にレコードを更新するから、他のユーザーを防ぐことができます。この正確な瞬間を更新することに加えて、データは常に利用可能です。
詳細については、以下を参照してください开放式并发。
しようとすると
更新時間を、行の最初のバージョンは、既存の行のデータベースと比較される変更。
彼らが異なっている場合、更新は失敗し、同時実行エラーが発生します。
この時点で、あなたはビジネス・ロジックを使用してこれらの2行を調整するために作成されます。
3.最後の更新を有効にします
とき「を有効にする最後の更新は、」それはないだろう初始数据チェックすることが、ちょうど更新データベースに書き込ま。
明らかに、次のことが発生する可能性があります。
ユーザーは、データベースからレコードを取得します。
ユーザBは、データベースから同じレコードを取得し、それを修正し、再びデータベースに更新されたレコードを書き込むことができます。
ユーザAは、「古い」のレコードを変更し、それをデータベースに再度書き込みます。
上記の場合、ユーザAは、ユーザBの行った変更を見ることはありません。あなたは同時実行制御の「最後の発効更新」メソッドを使用する予定の場合、この状況は許容可能であることを確認してください。
三、ADO.NET、およびVisual Studio .NETの同時実行制御
データ構造に基づいているので断开、データ、 ADO.NET及び Visual Studio .NET 使用开放式并发。
そのため、あなたは楽観的同時実行の問題を使用するためにビジネスロジックを追加する必要があります。
あなたが使用することを選択した場合开放式并发、それは変更が従来の2つの方法で発生しているかどうかを確認することができます版本号方法（実際のバージョン番号や日付のタイムスタンプ）と保存所有值方法。
1.メソッドのバージョン番号
プロセスバージョンでは、レコードを更新するには、バージョン番号やタイムスタンプを持つ日付列が含まれている必要があります。
基準日のタイムスタンプまたはバージョン番号を読み出すとき、クライアントに保存されます。
その後、部分更新の値。
同時実行を処理する方法は、唯一され WHEREた値が記録句の値と一致する場合、更新します。
この方法のSQL表現は、次のとおりです。
-
UPDATE Table1 SET Column1 = @newvalue1, Column2 = @newvalue2 -
WHERE DateTimeStamp = @origDateTimeStamp
また、あなたは比較のために、バージョン番号を使用することができます。
-
UPDATE Table1 SET Column1 = @newvalue1, Column2 = @newvalue2 -
WHERE RowVersion = @origRowVersionValue
日付やタイムスタンプ、バージョン番号が一致した場合、レコードはデータ格納領域が変更されていないことを示し、かつ安全に更新するレコードをデータセット内の新しい値を使用することができ、
あなたが一致しない場合、エラーが返されます。
あなたは、Visual Studio .NETで同時実行チェックのこのフォームを達成するためにコードを書くことができます。あなたはまた、任意の更新の競合に対応するためにコードを記述する必要があります。
日付のタイムスタンプまたはバージョン番号の正確さを確保するために、あなたがする必要が表セットに触发器変更はバージョン番号を更新するために、ライン上で、日付またはタイムスタンプに発生したときに、。
2.保存し、すべての値の方法
代替またはバージョン番号を使用して日付スタンプが読み出し時に記録されています获取所有字段的副本。
各変更されたレコードの2つのバージョンを維持するために、ADO.NETのDataSetオブジェクト。
初始版本（版は、最初のデータソースから読み取る）、および修改版本（ユーザ更新ことを示します）。
あなたが戻ってデータソースにレコードを書き込むしようとすると、データ列の初期値は、データソース内のレコードと比較されます。
それらが一致した場合、それは彼らが読み込まれた後、データベースのレコードが変更されていないことを示しています。
この場合、データセットの値が正常に変更されたデータベースに書き込まれます。
データアダプタの4つのコマンド（のためにDELETE、INSERT、SELECT 和 UPDATE）、それは、各コマンドのパラメータのセットを有します。各コマンドは、パラメータの初期値及び電流値（または変更された値）を有します。
第二のタイプの処理条件：
そうであるので大并发请求、第一ケースの処理方法で使用することができる、
ようさらに、大数据量検索された、考慮する必要がある查询效率質問：
- 検索条件でインデックス化表
- 最適化を照会するには
- キャッシュされたクエリデータを使用することを検討してください
第三幕処理：
処理方法は、第一の場合に採用することができ、
また同じテーブル上にリフレッシュ動作であるため、以下の手法を用いて検討してください。
- 最初のデータは、データが一定量に達すると、キャッシュに格納され、その後、データベースを更新します
- テーブル
索引（分割分表，分区）は、例えば：州によって場合全国の人々の情報を格納するテーブル、このデータ量が大きいが、地域情報によって国の人々は、対応するテーブルに格納されている、複数のテーブルに分割され、次いで、それぞれの州および照会および更新に応じて、並行性および大規模なデータの問題のような大規模な量がはるかに低減されます