[pgsql-jp: 30570] レンタルBBS テーブル構成

[Tetsuo SAKATA]

こんにちは．坂田@横須賀です．

#識者じゃありませんが，興味があるので出てきました．
#机上検討だけで，実際に試したわけじゃありません．

斎見 浩平さん wrote:
> ２．同時に多数の更新アクセスが集中した場合、更新時の内部ロックや、
> MVCCのことなんか考えると、1テーブルに集中するより、それぞれ別のテー
> ブルにアクセスされたほうが、処理が早いと思われますが、PostgreSQLは例
> えばMySQLなどのまともにマルチスレッド化されているDBと比較して、「1テー
> ブルに同時更新要求」と「独立したテーブルに同時更新要求」の処理時間の
> 差は小さいと見込まれるのでしょうか？

BBSですから，リクエストは次の2種類になるかと思います．

(R1) 掲示板の表示要求
(R2) 掲示板への書きこみ要求

(その他，削除要求やexpire処理，新しいスレッド(掲示板)を立てる処理
　などもあるはずですが，ここでは除外します)

書きこみの総件数が数万件〜数十万件，1つの掲示板の書きこみが数百件，
掲示板の数が数百程度を想定します．

(R1)では，書きこみの入った表を検索して，1つの掲示板に含まれる書きこみを
答えます．

この時，複数の掲示板を1つの表にまとめるか(S1)，個々の掲示板を
1つずつの表に分割するか(S2)かが問題となっていますね．

(R1)に対して，(S1)のアプローチを取ると，数万件の書きこみから
1つの掲示板に含まれる数百程度の書きこみを取り出すことになります．
これは，恐らくインデクスを経由することでしょうが，実質的には
書きこみ件数分の(＝数百回の)ランダムアクセスになるのではないかと思います．

他方，(R1)に対して(S2)のアプローチを取ると，指定された
表を全部取り出す操作になるので，インデクスを経由せず，
数百件分をシーケンシャルに取り出すことになると思われます．
(少なくとも，1つのブロックに数件以上の該当する書きこみが
含まれるでしょうから，完全なランダムアクセスに近い(S1)の
ケースよりはマシだと思います)

よって，リクエスト(R1)では，(S2)の方が(かなり)有利ではないかと思います．

次に，書きこみリクエスト(R2)について検討します．

ボトルネックになりそうなのは，まずロックの競合です．
PostgreSQLの場合，MVCC+レコードロックを使用するので，
(repeatable readを指定する=デフォルト=限り)
ロックの競合による待機がスループットに及ぼす影響は両者で
差がないと考えられます．
次に，実際のストレージでのボトルネックが考えられますが，
これについては，リクエストの件数とバイト数で決まってくる
と思われるので，これも両者で差がないと考えられます．

よって，リクエスト(R2)では，(S1)でも(S2)でも大差はないでしょう．

ここまでの検討では，単純な性能上は「1つの掲示板を1つの表に」
という方針(S1)が有利であろうと思います．

なお，MySQLの場合であれは，ロックは表単位のみで行うため，
掲示板への書きこみは必ず他の処理を待たせることになります．[1]
この問題については，内部の処理方式がマルチスレッドであっても
回避(軽減)できません．

[1]
http://www.mysql.gr.jp/jpdoc/4.0/manual.ja_MySQL_Optimization.html#Locking_Issues

以上，ご参考まで．
#dbt-2 のmakeでハマッてます．

-- 
	NTT サイバースペース研究所	sakata.tetsuo ＠ lab.ntt.co.jp
	坂田　哲夫			Tel: 046-859-2765
					Fax: 046-859-2768
Tetsuo SAKATA, Yokosuka JAPAN.