巨大なテーブルについて

質問

例えば「2ちゃんねる」の全スレッドを、一つのテーブルで管理するといったことは可能でしょうか？
（レコード数は仮に40万件程度として、常時読み書きが行われるとします）

ざっくり調べた感じでは、レコード数が100万程度でも、インデックスさえ適切なら
パフォーマンスを保ちつつ運用できそうな感じでしたが、どうなんでしょう。

もし問題があるとしたら、その問題点についても教えて頂けるとあり難いです。

回答No.4

nora1962 · ベストアンサー

> うーん。2ch規模のI/Oを捌こうと思ったら
> DBの分割が必要そうですかね

というか、スレッドを1レコードにするとレスがつくたびにレコード更新が起こります。2chのように頻繁にレスの追加がされるものだと、1スレッドにつき数秒間に1回はレコード全体（数メガバイト単位）をDISKに上書き更新する必要が出てくるのです（チェックポイント）。
全部で数百の単位のスレッドがあると通常のストレージではI/Oが捌き切れません。

お礼

>>（数メガバイト単位）
一レスの最大文字数が1024文字として、一文字2バイトなら
最大2048バイト*1000レスになります。
これだと2M弱になりますが
2ｃｈの書き込みを見る限り
概ねこの10分の1以下で済みそうです。

それなら200ｋ程のサイズになるので
大した事ないかなと考えていたのですが、
DBではまた事情が変わってくるのでしょうか。

ところで、
>>通常のストレージではI/Oが捌き切れません

こういった場合、メモリの増設やCPUの高速化では
対応できないものなのでしょうか？

度々済みません。有難うございます。

回答No.3

nora1962

> スレ一つを一つのレコードで管理する事を想定しました。
そうですね、スレッドのID、タイトルやレスの件数など1レコードで管理して、レスのデータはフラットファイルに追加書き込みするのが適切かもしれません。すでに書き込まれたレスについての変更・削除がないなら、これでいけると思います。
データ本体をRDBに取り込むとI/Oがボトルネック（既存レコードの変更が馬鹿にならない）になると思うので、あまり現実的ではないと思います。

お礼

うーん。2ch規模のI/Oを捌こうと思ったら
DBの分割が必要そうですかね

有難うございます

回答No.2

nora1962

> 例えば「2ちゃんねる」の全スレッドを、一つのテーブルで管理するといったことは可能でしょうか？
> （レコード数は仮に40万件程度として、常時読み書きが行われるとします）
「2ちゃんねる」の全スレッドのレスが40万件程度とは思えないのですが。
レスの上限１万件では40スレッドしか管理できません。
後、「dat落ち」の際のスレッドの全件移動→削除処理を考えると「一つのテーブルで管理する」ということは、あまり妥当ではないように思われます。
スレッドごとにテーブルかパーティションを分けたほうがいいのではないでしょうか。

お礼

スレ一つを一つのレコードで管理する事を想定しました。
スレの本文はlongTextで一つのカラムに保存します。
ちなみに、レスの上限は1000を仮定しました。

で、一つの板につき500スレッドとして板数が800程度だから、
仮にスレッド数＝レコード数＝40万となりました。
(かなり多めな見積りです)

dat落ちの際の移動処理も、レコード一つで済むので
たいした負荷にはならないかなと思ったのですが、
どうなんでしょう。

有難うございます。

回答No.1

yambejp

まずはテーブルの管理とは何かを定義する必要があるでしょう

いわゆるファイルI/Oと同等にSQLにデータを書いていくなら
（たとえば、○○板の××スレの△△番にアクセスしたいってだけなら）
何百万でも大して負荷はないと思います
しかしそんなものSQLを使わず単にスレッドをファイルとしてもいい気がします

ＩＤ××の最近の書き込み10個とか、ｎ月ｍ日にアクセスのあった
上位10スレとか、そういう集計が必要になると、100万単位のデータがあると
パフォーマンスがだいぶ落ちます

ましてや「□□」というキーワードの出現頻度とか特殊な集計になると
戻ってくるのに数十秒～数分単位かかってもおかしくありません。

お礼

数百万件のレコードでも問題ないというのは凄いですね。
mysqlを少し見くびっていました。

単純とはいえソートさせたいとしたら
(スレごとの書き込み件数順とか)
DBで管理するのが適切かと思いました。
しかし、あまり複雑な検索などはさせない方が良さそうですね

ありがとうございます。