はじめてのRuby on Rails、トラブル記録
<< RailsでAmazonAPIを使ってみる(ruby-aaws)(2) | TOP | Rails2.x 新しくプロジェクト作るときの手順 >>
スポンサーサイト

一定期間更新がないため広告を表示しています

posted by スポンサードリンク | | - | - | - |はてなブックマーク - スポンサーサイト
データ容量を気にしてmigrateファイルを作ってみる
Ruby on Railsに手をつける前から思ってたけど、
Webのプログラムって大部分がデータベースなんだよね。

素朴な疑問。
データベースをいくつも使ったようなサービスを公開するとして、
ユーザーが増えるごとに、たとえばブログとかみたいに投稿されたものとかが増えるごとに
データベース容量が大きくなってくよね。

まあ、必要になればスケールアウトっていうの?データが入りきるように容量大きくするなりするんだろうけど、
使わなくなった不要なデータ(ログ的なものとか)処分したりとか、
データベースの最適化したりとかってしてるのかなあ。一般的に。
Web業界に身を置いたことないのでその辺の運用とかってよくわからないなー。

せめてなるべくデータ容量食わないようにmigrateファイルの設定の段階でもう少し気をつけてみるかと少し調べてみた。
とりあえず、limitを設定してやればその分だけいらない容量確保しなくてすむし、これはやった方がいいだろう。
(今まではろくに設定してなかった汗

それで気づいたけど、
そもそもlimitは何のlimitなんだ?バイト数?桁数・文字数?

調べてみたところ、stringは文字数、integerは桁数らしい。バイト数ではなかった。
MySQLではstringはvarchar(n)となって、limitに設定したのがn=文字数になる模様。
integerの方はちょっと複雑で、limitに設定した数値によってMySQLで宣言される型が変わるみたい。

こちらが参考になりました↓
migrateでのintegerの扱い

必要バイト数と合わせてまとめると、以下のような感じ。
migrateのlimitMySQLのカラム型必要バイト数
0INTまたはINTEGER4
1TINYINT1
2SMALLINT2
3MEDIUMINT3
4..6INTまたはINTEGER4
5..8BIGINT8
9..21INTまたはINTEGER4


重要な点は、
・0だとTINYINTじゃなくて、INTになってる!
・5..8だとなんかBIGINTになってる…!!
・実際にはINT(n)とか桁数が入るけれど、桁数は必要バイト数とは無関係
ということ。

結論:必要バイト数はカラム型で決まるので、そこ気にしてlimitかけよう

じゃ、そーゆーことで。



参考:
migrateでのintegerの扱い
MySQLリファレンスマニュアル 6.2.6. 各カラム型に必要な記憶容量
posted by トモト | 16:01 | Rails小ネタ | comments(0) | trackbacks(0) |はてなブックマーク - データ容量を気にしてmigrateファイルを作ってみる
スポンサーサイト
posted by スポンサードリンク | 16:01 | - | - | - |はてなブックマーク - スポンサーサイト
コメント
コメントする










この記事のトラックバックURL
トラックバック機能は終了しました。
トラックバック
Rails3レシピブック 190の技
Rails3レシピブック 190の技
ついにRails3対応版が出ました!!
WEB+DB PRESS Vol.58
WEB+DB PRESS Vol.58
Rails2系から3への移行時に知りたいことがひとまとまりになっててよかった!色々ググるよりこれを読む方が早い。
Rubyレシピブック 第3版 303の技
Rubyレシピブック 第3版 303の技
Rubyやるならこのリファレンスは必要。
Search this site