2017-06-07 28 views
1

Person(id, country_id, name)のデータを保存しているとします。ユーザーがidとcountry_idを送信した後、名前を送り返したとします。httpリクエストごとのダイレクトdb接続と接続プーリング - 違いは

私は1つのdbと2つのウェブサーバを持っており、各ウェブサーバは20の接続の接続プール(たとえばc3p0)を保持しています。

つまり、dbは40の接続を維持し、各Webサーバーは20の接続を維持しています。

人が「DB接続を作成することは高価である」と言うので、これは全てのセンスを作る


は、今の私はcountry_id上の表データをシャード言わせ

を我々は、接続プールを使用していることがわかります上記のシステムを分析しますので、現在200のデータベースがあるかもしれません。私たちのアプリが現在普及していると仮定し、Webサーバーを50台持つ必要があります。
上記の接続プールの戦略は、各Webサーバーが各データベースのプールに20の接続を保持しているかのように失敗します。
これは、各Webサーバーが20 * 200db = 4000接続を持つことを意味します。
であり、各dbは50のWebサーバー* 20 = 1000接続を持ちます。

これは良いとは言えないので、なぜWeb接続ごとに1つの接続を作成するオーバーヘッドが接続プールを使用するのかという疑問があります。

私は、DriverManager.getConnection()がローカルホストで平均20ミリ秒かかるというテストを実行しました。要求ごとの余分な

20ミリ秒のゲームキラー

Question1ではありません: Webリクエストごとに1つの接続を使用して、任意の他の欠点はありますか?

質問2:インターネット上の人は "db connection is expensive"と言っています。異なる経費は何ですか?


PS:私も同じhttps://medium.com/@Pinterest_Engineering/sharding-pinterest-how-we-scaled-our-mysql-fleet-3f341e96ca6f

+0

プールを強化するテクノロジ(つまり、同じサーバー上のJavaサーブレットコンテキストで接続プールを共有できます)とシャーディング(つまり、['pgpool'](http://www.pgpool.net/mediawiki/index。 php/Main_Page)) – pozs

+1

フロントエンドで毎秒10000ページのインプレッションに対処する必要がある場合にかかる時間をテストしましたか?すなわち、ネットワーク接続を介して1秒間に 'getConnection()'を10000回呼び出しますか? –

答えて

2

をやっPinterestの参照あなたが忙しいのウェブサイトを持っている場合は、データベースへのすべての要求は、接続を開閉し、あなたが水の中に死んでいます。

あなたが測定した20msはlocalhost接続のものです。私はあなたの50台のWebサーバーがすべてlocalhostになるとは思わない...

データベース接続の確立とクローズにかかる時間とは別に、データベースサーバー上のリソースも使用します。これは主にCPUですが、カーネルのデータ構造にも競合が存在する可能性があります。

また、数千の接続を許可すると、すべての接続が同時にビジー状態になることはありません。その場合、数千のコアがないとデータベースサーバーが過負荷になり応答しなくなりますロック競合によって制限されます)。

解決策は、pgBouncerのような外部接続プールです。

2

接続の作成以外の場合接続のクローズサイクルが時間がかかる作業(コストがかかる)であるため、データベースへの同時オープン接続の数を制御するためにプーリングも行われます。 dbサーバーが処理できます。リクエストごとに1つの接続を行うと、そのコントロールが失われ、アプリケーションはピーク時に常にクラッシュする危険性があります。

第2に、Webサーバーの容量をデータベースの容量と不必要に結びつけ、ターゲットはdb接続管理を開発者の関心ではなくインフラストラクチャ上の問題として扱うことです。彼/彼女のコードに従って、プロダクションアプリケーションのデータベース接続を開発者に開くように制御したいですか?

Weblogic、JBoss、WebSphereなどの従来のモノリシックアプリケーションサーバーでは、sysadminはdb sererの容量ごとに接続プールを作成し、JNDI名を使用して開発者に渡します。開発者の仕事は、そのJNDI

次に、データベースがさまざまな独立したアプリケーション間で共有されている場合、プーリングによって、どのアプリケーションに何を配っているかを知ることができます。いくつかのアプリはデータ集約的であり、あるものはそれほど集中的でないかもしれない。

リソースリークの伝統的な問題です。つまり、開発者が接続をきれいに閉じることを忘れると、プーリングで処理されます。

総合的な考え方は、開発者が接続の使用についてのみ関心を持ち、自分の仕事を行い、開いたり閉じたりする心配がないようにすることです。接続がX分間使用されていない場合は、構成ごとにプールに戻されます。

+0

したがって、最大接続を維持すると、最大接続後に要求がキューに入れられます。Plusフレームワークは接続の作成を処理します。 – Bhuvan

+0

既存のツールで提供されているプーリングと異なる点はありますか? –

+0

私たちは仕事が終わるとすぐに接続を閉じる接続を維持していません....各Webサーバーから200 db * 20接続= 4000のライブを維持することは望ましくありません "...思考? – Bhuvan

関連する問題