performance - データベースを専用サーバーに置くとパフォーマンスが低下しますか?

Question

システムを拡張する 1 つの方法は、Web サーバー、データベース サーバーに異なるマシンを使用し、サーバーの種類ごとに複数のインスタンスを使用することだと聞きました。

これにより、すべてに 1 つのサーバーを使用するモデルよりもパフォーマンスがどのように向上するのでしょうか? それらのサーバー間の接続にボトルネックはありませんか? さらに、別の Web サーバーからデータベース サーバーにアクセスするときは、同期に注意する必要があります。

Answer 1

多数のサーバーを持つことは魅力的な解決策のように見えるかもしれません。頻繁に発生する問題の1つは、サーバー間の通信から発生する遅延です。ファイバー相互接続を使用しても、同じサーバー上にある場合よりも遅くなります。もちろん、単一のサーバーソリューションでは、1つのサーバーアプリケーションが多くの作業を行うと、DBアプリケーションで必要なCPUリソースが不足する可能性があります。

発生する可能性のあるもう1つの問題は、SANの問題です。SANの支持者は、ローカルに接続されたストレージと同じくらい高速であると言うでしょう。SANの目的は、ストレージのコストを削減することです。SANがローカルソリューションと同じ高性能ディスクを使用する場合（コスト削減を一掃する場合）でも、接続が遅くなり、SANで競合する同時ユーザーが増えます。

従来の知識では、DBは正規化されたデータを使用してSQLベースである必要があります。お互いに長所と短所（はい、SQLには短所があります）を比較検討するのに時間を費やす価値があります。

「太古の昔」（少なくとも過去20年間）以来、無関心なプログラマーはサーバーに過負荷をかけ、クライアントに実装するには怠惰すぎます。無関心な（または無知な）建築家は、この慣習を継続することを許可します。最終結果：ほとんど役に立たないc/sの実装が遅くなります。サーバーパークを3倍にすることは、必死の「配信前の1週間」の測定であり、せいぜい、わずかなパフォーマンスの向上につながります。多くの場合、代わりにパフォーマンスが低下します。

DBは、複数のテーブルを含む複雑な要求に悩まされるべきではありません。クライアントによってフィルタリングされた単純なリクエストがその方法です。

フレームワーク/SOAP処理を1つのサーバーに配置し、バイナリ応答で応答するDBサーバーにバイナリ要求を送信させることもできます（SOAP要求を理解しようとすると、CPUに非常に負荷がかかり、実行しません。とにかく多かれ少なかれ窒息するDBアプリケーションに任せたくない）。このようにして、SOAPは環境の一部（ユーザー/他のフレームワークユーザーへのインターフェース）のみをスロットリングし、残りのインターフェースは可能な限り効率的になります（バイナリ）。

もう1つのことは、アプリケーションで許可されている場合、DBアプリケーションにキャッシュフロントエンドを配置することです。このキャッシュの目的は、DB自体を関与させることなく、可能な限り多くの反復処理を実行することです。このようにして、DBは、すべてを実行するのではなく、より少ないが（おそらく）より複雑な要求を処理することになります。

ああ、クライアントにSQLステートメントをDBに直接送信させないでください。あなたはDBが戦わなければならないがらくたに驚かれることでしょう。

Answer 2

インフラストラクチャが十分に小さい場合は、そうです。1 台のサーバーですべてを処理するのが (おそらく) 最善の方法ですが、サイズによって複数のサーバーを使用する必要が生じ始めると、単一のボックスのサイズをスケーリングすると、さらに多くのことができます。高価な場合は、安価なサーバーを複数持つ必要があります。これはまた、より多くの耐障害性を持つことができることを意味します (1 つのサーバーがダウンした場合、他のサーバーが引き継ぐことができます)。データの同期に関しては、データベース側では通常クラスタリングやレプリケーションを使用して実現されますが、アプリケーション側では memcached やドライブへの保存などで実現でき、Web サーバー自体は実際に同期する必要はありません。 . ローカル ネットワーク上のネットワーク ボトルネック (サーバーが互いに接続されている場合など) は無視できます。