RDBMSでコネクションプールが必要な理由、わからない。

あとで読むためまとめとく。勝手にメンテしてくれると嬉しい。
プログラミング
65
Kota Uenishi (๑•̀ㅂ•́)و✧ @kuenishi
コネクションプーリング、サイエンスになるほどの理論はなかなかないけど定番のノウハウはあって教科書にはないので難しくはないけどツラい。
Inada Naoki @methane
@voluntas AZの設計にもよるかも。RDS の話も Multi-AZ なので。
MURAOKA Taro @kaoriya
@methane その使い分け、なんかピンと来ないな。
Inada Naoki @methane
@kaoriya あー。普通は1トランザクション=1処理なんですが、Web系ではどうしてもHTTPの1リクエストが基準になるので。
ハイパーむとう @masa_edw
@voluntas あちこちに飛び火してしまいましたが、いろいろな要因があるんですね
Yoshi Yamaguchi 🇯🇵 @ymotongpoo
みんながコネクションプールの話してるから、水泳したくなってきた
MURAOKA Taro @kaoriya
@methane それはわかるんですが、コネクションプールに対して「永続化」と「シェア」という語を割り当ててどんなユースケースを定義しようとしているのかがピンとこないんです。どちらもDBとその格納データに対して使うならわかるんですが。
V @voluntas
@masa_edw いい飛び火だと思います:-)
ハイパーむとう @masa_edw
僕の最初の理解では、TCP/IPのセッションを張るのが遅いから必要というのは眉唾(単体でみれば、大量につなぎに行くのも待つのも、十分安いコストで可能)。サーバ側の何かしらの処理で重くなる要因があるはず。というものだったんだけど、
Yutaka Matsubara @mopemope
コネクションプール都市伝説の話とか知らないのかあ
ハイパーむとう @masa_edw
割と(RDBの性質上)クライアント側の都合があるらしい。また経路によってはネットワーク的な都合でレイテンシが悪くなったり接続数を減らしたくなることがある(RDSの話がでてるけどAzureでも同様に問題になる)。
ハイパーむとう @masa_edw
サーバー側の都合はよくわからない
ハイパーむとう @masa_edw
あとRDBMSの場合、処理の最初に繋ぎ行って最後に返す、という使い方が一般的でないという実装上の都合があるようにみえる。その方がアプリを書きやすいし、裏側で頑張ってコネクション使いまわして最適化できるからいいんだろうけど、これは必要な理由というより現状そうであるという話に見える
Ryosuke IWANAGA 🇨🇦 @riywo
非同期なアプリで1リクエスト1接続にしちゃうと、接続一杯受け付けちゃって同じ数RDBMSにも接続張られちゃうから、プールを使ったって話は聞いたことある。
shirou - しろう @r_rudi
あ、さっきのコネクションプールの話、「RDBMSで」だったんだ。そういう制限が付いてるとぼくのつぶやきは全然違うかも。
Kazuho Oku @kazuho
多くのRDBMSのプロトコル設計が、接続時や切断時にリクエスト/レスポンスを投げるようになってるので、都度接続だと無駄が多いってのもあるな / “RDBMSでコネクションプールが必要な理由、わからない。 - Togetter” http://t.co/HFUj7MnQ1j
Kazuho Oku @kazuho
C/S型のRDBMSは、元々小数のクライアントとステートフルな通信を行うために設計されてきた(ことが多い)ので、HTTPのように多数のクライアントと接続切断を繰り返しながらやる方式とはインピーダンスミスマッチがあるんだよねー
ハイパーむとう @masa_edw
僕の理解ではネットワーク経路に問題がなくてリクエスト処理数にも余裕があるようなRESTサービスではコネクションプールを使わなくても良い(処理時間とアクセス数を元に最大コネクション数の見積もりは必要だけど)。
V @voluntas
@kazuho の RDBS 視点からの解説が素敵
Takayoshi Kimura @nekop
DBのコネクションプール話乗り遅れたけど接続プロトコル知ってる人既に何人か参加してるみたいだからコーヒー飲みながら鼻クソほじってて良さそう
ハイパーむとう @masa_edw
@kazuho さんの発言が一番エッセンスが詰まってて、まとめとしてはこれだけ読んでおけばいいのではというレベル。
大沢和宏 @Yappo
用途とRDBMSのプロダクトを明言してないから議論が発散してて参考にならない / RDBMSでコネクションプールが必要な理由、わからない。 - Togetter - http://t.co/5v09GyTVMm
大沢和宏 @Yappo
Webアプリ MySQL に限って言えば、プロセスでコネクション張りっぱなしだとピークタイム以外の時にリソース使いすぎてて衛生的じゃ無いのと、接続コストが無視出来るレベルなのでリクエスト単位でコネクションしてる。
大沢和宏 @Yappo
コネクション繋ぎっぱの実装だと、うっかりバグ入れこんで障害起こす問題を多々聞くので、安全なアプリケーションを作りたいなら永続性接続で作らないし、ミドルウェアでプーリングするのもシステム複雑化するだけなので手段として選択しない
大沢和宏 @Yappo
負荷を問題にする前に適切にリソース監視をして、適切に増強していけばいいだけなので、それは理由にならない。ただし限られた予算の中でやりくりする時に必要になってくるのかなという感じですね。
大沢和宏 @Yappo
全て、最近の WebアプリとMySQLの話なので昔話は勝手にやってください!!!ちな pgpool いれた事あるけどうんこ~!だった
V @voluntas
あとは「障害時の自動切り替え」とかを考えると個人的にはりっぱいやだーなーと思う人だったり。まぁ富豪最高ってのが結論なのかもしれない。富豪が出来ない場合は本気出す方向で。
大沢和宏 @Yappo
特に mysql connection にバランサ使って無いけど、瞬間ピークすごい geo service は全部のアプリケーションサーバの中に DB slave たててるから一般世界の煩悩とは無縁の世界だった
shirou - しろう @r_rudi
コネクションプールは「状態」なわけで、管理がめんどくなるんだよね。都度接続で問題ないならそれが一番。
V @voluntas
@r_rudi ステートフルは悪ですからねぇ、基本。
大沢和宏 @Yappo
mixi では認証機能まで外して新規接続コストを下げてるので影響有りませんでした的な事を同僚が昔どっかの公演で言ってたけど、うっかり有るから認証したい派
V @voluntas
たしかにサーバ側からみたらサーバそれぞれに色々言いたいことあるだろうから、微妙だろうな。個人的にはコネクションプールが必要な一般論として書いてみた感じ。KVS や RDBS あんまり関係ない。
Naoya Ito @naoya_ito
今年もコネクションプールで盛り上がる季節がきたようだし一言何かもの申してやるか! と鼻息を荒くしたけどだいたい全部忘れてた
takabow @takabow
RDBMSだと、プロセス生成とDBの認証まわりだけで、普通に無視できないレベルで重い処理だよね。同時に数百コネクションを同時に繋いだり切ったりして、DB側の負荷を見ると普通に跳ねる。
やましろ @yamashiro
コネクションプールを手動で管理するのが流行ってTLに書いてあった
std::めるぽん @melponn
コネクションプールが必要な理由が分からないと言った人をバカにしたあげく何のアドバイスもしなかった技術者各位…
V @voluntas
@melponn どの辺が馬鹿にしたように見えました?
std::めるぽん @melponn
@voluntas 各位っていうかまあmopemopeさんの発言を読んで思わず書いてしまったのですが、今はこんなこと書くべきじゃなかったかなーと思ってます
V @voluntas
@melponn もぺもぺはネタなので … 。ただ言いたいことはなんとなくわかります。
Takayuki Shimizukawa @shimizukawa
コネクションプール都市伝説ってWEB+DB PRESS vol.33 (2006) の記事だったか
Yutaka Matsubara @mopemope
WEB+DB PRESS vol.33 ですね。コネクションプール都市伝説の話。mysqlならなくてもまあいいかって話はあると思いますが
Yutaka Matsubara @mopemope
まああとこのシリーズも読むといいのかな http://t.co/CfguRUHgvF
Yutaka Matsubara @mopemope
ステートレスとステートフルなプロトコルとではやっぱ違うのでその辺も考慮すべきだろうけど。レイテンシーとかもあるでしょうし

コメント

SH2 @sh2nd 2013年9月4日
Oracle Databaseで新規接続に0.7秒かかる環境を見たことがあります。通信待ちなどではなくCPUを0.7秒使います。MySQLだけ見ているといらないと思うかもしれませんが、コネクションプールなしで大量のOLTPをこなせるRDBMSは少数派です。IBM DB2もMicrosoft SQL ServerもPostgreSQLもダメです。
eternalwind @juns76 2013年9月4日
そういうプログラムを書いて、こってり絞られてる新卒を見たことがある。 まあ、その時に怒ってる指導側も「そんなのは当たり前だろ」「DB側は重い」ぐらいの説明しかできてなかったし、なんとなくそういうものだと思い込んでいってるだけなのが一目瞭然だった。この業界、現場にいる人は理論までちゃんと理解して使ってるわけじゃないし 疑問に思ったことを口に出しただけで、きつい口調で叩くツイッター界隈の人の偏狭ぶりも笑える
𝑬𝒍𝒓𝒐𝒚 𝑴𝒄𝒈𝒊𝒓𝒆 @condotti 2013年9月4日
コネクション張る先がOracleかMySQLかでかなり違いそうですね。夏休みの自由研究ネタだな。
trycatch777 @trycatch777 2013年9月4日
いつ設計したシステムか?に依存するに1票。10数年前の、(アベレージな)サーバーの能力が高くなかった頃は、コネクションのオーバーヘッドやコネクションを保持しておくコストをケチるという目的が多かったと思うけど、何でもかんでもコネクションプールを使う実装が多かった記憶があります。
TANAKA Takakiyo @takakiyo 2013年9月4日
Java EEサーバーだと,一度作成したPreparedStatementを使い回せる,というのも大きい。コンテナの提供するコネクションプールが,Connectionごとに使用したPreparedStatementをキャッシュして自動的に再使用してくれる。
ぎゃばん@か51 技術書典6 @ledsun 2013年9月4日
SQLServer2005 を相手に ASP.NET のコネクションプール(デフォルトで有効)を切ったら目に見えて遅くなったなぁ。なお、どれくらいの負荷を掛けたかは覚えていない。
Peculiar News JP @digdagzigzagu 2013年9月4日
岡崎市立中央図書館事件/librahack事件とかあったしな。コネクションプール以前に解放してなかったらしいが、三菱電機インフォメーションシステムズ (MDIS) は土下座して良いと思う。
uNagi @unagix 2013年9月4日
なんとなく高木先生渾身のアニメを貼っておこう http://takagi-hiromitsu.jp/diary/20100829.html#p01
乳牛 @NewGyu 2013年9月4日
@kazuho 本筋と関係ないところで恐縮ですがこの文脈で「インピーダンスミスマッチ」は関係ないのでは? 
Inetgate Writer @Inetgate 2013年9月5日
ざっとまとめを見て、CICSとかTuxedoっていうOLTP系のツールはあまり使われなくなったのかなあと。
たるたる @heporap 2013年9月5日
サーバー構築は門外漢ですが、Webサービスの場合、訪問者(多)-ウェブ鯖(1)-DB鯖(1)という構成なので、「DB鯖にとってのクライアント」はウェブ鯖の1つだけ。DB鯖から見れば実質1対1で何度も接続してるようなものだから、コネクションは繋ぎっぱなしの方が都合がいい。ということではないですかね。
Tsuyoshi CHO @tsuyoshi_cho 2013年9月5日
heporap 規模大きくなってくると多(大)-多-多な気がしますが、そこらへんも関係するかな。
ログインして広告を非表示にする
ログインして広告を非表示にする