5

私は現在、レプリケーション、ログ配布、ミラーリングなどの SQL Server スケールアウト テクノロジのジャングルを横断しています...選択には次の制約があります。

  • 読み取り専用の負荷をプライマリ サーバーとセカンダリ (ミラー、サブスクライバー) サーバーに分散させたい
    • 書き込み負荷をプライマリ サーバーに直接送信可能
    • このソリューションは、ほぼメンテナンス不要です。スキーマの変更はセカンダリ サーバーにレプリケートする必要があります (注意: レプリケーションにはいくつかの深刻な制約があるようです)
    • 書き込まれたデータは、セカンダリ サーバーで非常に迅速にアクセスできる必要があります (1 秒未満で、より良いのは瞬時に)。
    • サーバーに障害が発生した場合、最大 1 時間のデータ損失を簡単に許容できます。私は簡単なスケーラビリティにもっと関心があります

ここに私が選ぶことができるいくつかのオプションがあります: http://msdn.microsoft.com/en-us/library/bb510414.aspx . 共有できる経験はありますか？

4

1 に答える 1

5

これらはすべて高可用性ソリューションであり、スケールアウトではありません。SQL Serverには、簡単なスケールアウトソリューションはなく、他の（リレーショナル）データベースもありません。マスター/スレーブレプリケーションの使用は、マスター書き込みスケールアップの可能性によって許可される限りのスケールアップを行います。マスターマスターレプリケーションを使用すると、書き込みが多重化され、整合性の問題が発生します。レプリケーションベースのソリューションを試みたほとんどすべての大規模な展開では、それを放棄する必要がありました。

代替案の1つは、 MySpaceがスケールアウトする方法である、メッセージングによって通信する独立したデータ領域の観点からアプリケーションを再考することです。

もう1つの方法は、いくつかの制約（書き込みの整合性、読み取りの整合性、回復可能性、型指定されたスキーマ、参照整合性）を破棄し、これらの制約が解放されると自由にスケールアウトできるnosqlエンジン（Cassandra、HBase、MongoDB）を選択することです。

最終的にスケールアウトは非常に基本的な要件であるため、ソリューションを中心にアプリケーションを設計し、スケールアウトによって課せられるすべての（厳しい）制限を受け入れる必要があります。ただし、すべてのリレーショナルエンジンは長い道のりでスケールアップでき、データベースのスケールアップを超えてスケ​​ールアウトする必要のある世界中の展開数を数えることができます。

于 2010-06-03T15:39:27.100 に答える