マルチリーダーシングルライター方式でSQLServerをスケールアウトした経験のある人はいますか。読めない場合は、読み取り集中型Webアプリケーションの適切な代替案を提案できません。
3 に答える
2
それはおそらく2つのことに依存します:
- 1 回の書き込みのサイズはどれくらいですか?
- 読者はリアルタイムのデータを必要としていますか?
書き込みは書き込み時にリーダーをブロックしますが、各書き込みが小さくて高速であれば、リーダーは気付かないでしょう。
たとえば、1 日の終わりのレポートをオフロードする場合、リーダーはリアルタイム データを必要としないため、負荷を別のサーバーにバッチ処理します。意味あり
プライマリ サーバーへの書き込みは、オフロード セカンダリ サーバーに同期する必要があります... とにかく同期プロセスの一部としてそこでブロックされます + 同期を管理するためにオーバーヘッド負荷を追加します。
とにかく、ほとんどのアプリは常に 95% 以上読まれています。たとえば、更新または削除は、読み取りとそれに続く書き込みです。
私の選択は (おそらく、書き込み量が少なく、それが Web アプリであることに基づいて) スケールアップし、データベースのデータ ファイルとログ ファイル用に別々のディスク パスを使用して、DB サーバーにできるだけ多くの RAM を詰め込むことです。
于 2008-12-17T05:04:33.223 に答える
1
シナリオに合わせてSQLServerをスケールアウトした経験はありません。ただし、読み取り中心のアプリケーションの場合、データベースの負荷を軽減し、 MemcacheやMSVelocityなどを使用してキャッシュ戦略を採用することを検討します。
私が知っている2つのアプローチがあります：
データベース全体をキャッシュにロードし、キャッシュ内のアイテムの追加と更新を管理します。
アイテムは、要求された場合にのみキャッシュに追加し、書き込み操作が実行されたときに削除します。
于 2008-12-16T23:09:04.500 に答える
1
ある種の複製でうまくいくでしょう。
http://msdn.microsoft.com/en-us/library/ms151827.aspx
もちろん、アプリコードを変更する必要があります。
一部の人々はパーティション化されたテーブルを使用し、さまざまな行範囲がさまざまなサーバーに格納されており、ビューと統合されています。これはアプリには表示されません。この実践のための連盟だと思います。
データベース、アプリケーション、およびサーバーの構成（SQLの詳細-データ/ログ/システム/sqlバイナリ/tempdbの場所）を設計することにより、かなり良好な負荷を処理できるはずです。必要がなければ、物事を複雑にしないようにしてください。
于 2008-12-17T03:49:26.637 に答える