ユーザー単位のデータ蓄積方法について

質問

ユーザーごとのデータを蓄積する際に、可能な限り更新系処理(特にinsert)の負荷が低くしたいと思い、その手法について効率的な方法を教えていただきたいと思っています。

○実施内容
ユーザーID,1,データ
ユーザーID,2,データ
ユーザーID,3,データ
・・・
(※↑ユーザーIDは、もちろんながらint系の値です。)
というようなスキーマで、ユーザーＩＤ、ユーザーごとのデータが共に非常に多くなることを前提とします。

○前提条件
・ユーザーIDはSQL発行の際必ず指定し、あくまで特定のユーザーデータの出し入れだけを行うことを前提とします。(ユーザーIDやデータでソートしたりなどはしません。)
→ソートや検索を行うとしても、必ず特定のユーザーID内だけで行います。

・InnoDBを利用。

○今までの自身の考え
・一番最初に直感でパーティショニングの使用を思いつきましたが、色々なパーティショニングのタイプを見たうえで、念のため実際に試しましたが、かえってパフォーマンスが落ちました。
(今回は、あくまでHDDは一つで、MySQLの設計ベースの話だけとさせて下さい。)

・他の方法として、テーブル自体をなんらかのユーザーID単位のルールで分割してしまう方法も考えていますが、可能な限り避けたいと思っています。

一番の理想としては、パーティショニングでインデックスまで完全に分割して、一つのテーブルに見えるものの、動きとしては複数のテーブルの集合のような状態ができるのが理想です。

回答No.2

nora1962

primary keyはなんでしょうか。
ユーザーID+連番だとすると、INSERTするタイミングでページ分割が発生し更新負荷が高くなる可能性があります。
AUTO_INCREMENTのprimary key（人工キー）を採用してユーザーID単位のインデックスを採用するほうが負荷が少なくなるかもしれません。

お礼

ありがとうございます。サロゲートキー利用の件、確かに負荷がある程度下がると自分も思いました。primary keyは可能な限り、ユーザーID,連番を採用したいと思っていましたが、この点は考え直した方がいいかもしれないとも思っています。

回答No.1

lupin-333333

＞今回は、あくまでHDDは一つで、MySQLの設計ベースの話だけとさせて下さい。)

そもそも、そこが間違えている。分散の意味って分かっています？

いい例は、HDDのRaid構成です。０、５，６以上がストライピングを含むパフォーマンスアップのシステムです。なぜ、そうなのでしょうか？　よく仕組みを勉強してみましょう。

分散を含まないのなら、DBエンジンのチューニングです。これは、パラメーターですね。メモリーの使い方や、バッファーや、一括処理の、設定ですね。

単にテーブルだけですませるなら、DBエンジンの問題なので、エンジンの改良するしかありません。例えば、限りなくマルチスレッドにする。なんて仕組みをDBエンジンに組み込む必要があります。

単純なところだと、Win7で標準で付属している、robocopy.exeと言うコマンドがあるが、そのオプションにMTなんて物が在る。これは、指定した数だけスレッドが増える。つまり、可能な限り、並列処理をすることになる。これはHDD一個に対しては、そんなに効果が上がらない。頭打ちになる。当然でしょう。RAIDやSSDを使うと、効果が発揮される。

補足

"今回は、あくまでHDDは一つで、MySQLの設計ベースの話だけとさせて下さい。)"は、パーティショニングなどの設定で、ハードウェアのボトルネックの解消の努力はしないという前提条件の話です。今回はMySQLの設計レベルだけの話とさせて下さい。(話が焦点がぶれるため。)