アカウント毎にパーティションするという発想は有効ですか？
解決済
回答 1
投稿
- 評価
- クリップ 0
- VIEW 2,258
こんばんは。
MySQLのパーティショニング機能ですが、以下のケースで有効に働くかどうか分かりません。
・全てのテーブルを、ユーザーアカウント単位でHASH パーティショニングする
たとえばWeb上でゲームや交換日記ができるシステム開発を行い、以下のようなテーブルを設計します。
-- 得点テーブル
CREATE TABLE score (
score_id INT NOT NULL,
user_id INT NOT NULL,
battle_score INT NOT NULL,
bonus_score INT NOT NULL,
get_medals INT NOT NULL,
created_at DATETIME NOT NULL,
PRIMARY KEY(id)
)
PARTITION BY HASH(score_id)
PARTITIONS 300;
-- 日記テーブル
CREATE TABLE diary (
diary_id INT NOT NULL,
user_id INT NOT NULL,
diary_title VARCHAR(100) NOT NULL,
diary_detail TEXT NOT NULL,
created_at DATETIME NOT NULL,
PRIMARY KEY(diary_id)
)
PARTITION BY HASH(user_id)
PARTITIONS 300;パーティション数は仮に300で区切って、ユーザーテーブル(アカウント数)は300レコードしか投入できないようにします。
-- ユーザーテーブル 300人までしか登録できない
CREATE TABLE user (
user_id INT AUTO_INCREMENT NOT NULL,
mail_add VARCHAR(255) NOT NULL,
twitter_id VARCHAR(255) NOT NULL,
facebook_id VARCHAR(255) NOT NULL,
PRIMARY KEY(id)
)ユーザーは300に達するまで徐々に増えていき、各テーブルにもuser_idが1から300までを持つデータが徐々に増えていきます。
テーブルのレコード数は、少ないものは合計で数千レコード、多いものは合計で数十億レコードぐらいまで増加します。ただし、ユーザーの活動状況によって、どのテーブルにどのuser_idのレコードが多いかは、まちまちです。たとえば、pointテーブルでは、user_id=7のデータは700万レコードあり、user_id=45のデータは400レコードしかないという感じです。
テーブル数は100～200ぐらいあります。
すべてのテーブルをパーティションすることで、あるユーザーのでデータが大量に増えても、ほかのユーザーの影響がないようにするために、上記の設計を考えましたが、この発想は有効でしょうか？
長文すみませんが、ご確認をお願いします。
-
気になる質問をクリップする
クリップした質問は、後からいつでもマイページで確認できます。
またクリップした質問に回答があった際、通知やメールを受け取ることができます。
クリップを取り消します
-
良い質問の評価を上げる
以下のような質問は評価を上げましょう
- 質問内容が明確
- 自分も答えを知りたい
- 質問者以外のユーザにも役立つ
評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。
質問の評価を上げたことを取り消します
-
評価を下げられる数の上限に達しました
評価を下げることができません
- 1日5回まで評価を下げられます
- 1日に1ユーザに対して2回まで評価を下げられます
質問の評価を下げる
teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。
- プログラミングに関係のない質問
- やってほしいことだけを記載した丸投げの質問
- 問題・課題が含まれていない質問
- 意図的に内容が抹消された質問
- 過去に投稿した質問と同じ内容の質問
- 広告と受け取られるような投稿
評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。
質問の評価を下げたことを取り消します
この機能は開放されていません
評価を下げる条件を満たしてません
質問の評価を下げる機能の利用条件
この機能を利用するためには、以下の事項を行う必要があります。
- 質問回答など一定の行動
-
メールアドレスの認証
メールアドレスの認証
-
質問評価に関するヘルプページの閲覧
質問評価に関するヘルプページの閲覧
checkベストアンサー
+1
まずPARTITIONSの理解を間違われているかと。。。 PARTITIONS 300ならパーティションが300個作られるだけで、ユーザーテーブルは300件を超えて登録可能です。(HASHの場合は、分割の方式がMOD(HASHに設定した値, パーティション数)の値によって対象のパーティションに格納されます）
もしも300件しか登録しないのであればidなりにprimaryキーをつけて、300件迄しか登録できない処理は別途アプリケーション側等で制御した方が良いかと思います。
追記
もし、ユーザー情報が300件までしか登録されないことが確約されているとすれば以下が良いかなと感じました。
userテーブルはidをprimaryにして管理する。
scoreテーブルとかはPARTITION BY KEY(user_id)のように指定しておけばユーザーidでパーティションが切られることになるので良いと思います。
また、ユーザーによって件数の振れ幅が大きいということもあるので、サブパーティションを切っておくと良いかもですね。
投稿
-
回答の評価を上げる
以下のような回答は評価を上げましょう
- 正しい回答
- わかりやすい回答
- ためになる回答
評価が高い回答ほどページの上位に表示されます。
-
回答の評価を下げる
下記のような回答は推奨されていません。
- 間違っている回答
- 質問の回答になっていない投稿
- スパムや攻撃的な表現を用いた投稿
評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。
15分調べてもわからないことは、teratailで質問しよう！
- ただいまの回答率 88.19%
- 質問をまとめることで、思考を整理して素早く解決
- テンプレート機能で、簡単に質問をまとめられる
2016/03/19 17:01
はい、ユーザーテーブルに300行を超えるデータを入れられることは認識しています。運用で、300行入った段階でそれ以上データを入れないようにする予定でした。分かりづらくてすみません。
お話を伺ったところ、有効という感じでしょうか。サブパーティションについても調べてみます。有難うございました。
2016/03/19 17:49
2016/03/20 08:03