スポンサーサイト
2013.07.04 Thursday
一定期間更新がないため広告を表示しています
はじめてのRuby on Rails、トラブル記録
データ容量を気にしてmigrateファイルを作ってみる
2009.10.22 Thursday
Ruby on Railsに手をつける前から思ってたけど、 Webのプログラムって大部分がデータベースなんだよね。 素朴な疑問。 データベースをいくつも使ったようなサービスを公開するとして、 ユーザーが増えるごとに、たとえばブログとかみたいに投稿されたものとかが増えるごとに データベース容量が大きくなってくよね。 まあ、必要になればスケールアウトっていうの?データが入りきるように容量大きくするなりするんだろうけど、 使わなくなった不要なデータ(ログ的なものとか)処分したりとか、 データベースの最適化したりとかってしてるのかなあ。一般的に。 Web業界に身を置いたことないのでその辺の運用とかってよくわからないなー。 せめてなるべくデータ容量食わないようにmigrateファイルの設定の段階でもう少し気をつけてみるかと少し調べてみた。 とりあえず、limitを設定してやればその分だけいらない容量確保しなくてすむし、これはやった方がいいだろう。 (今まではろくに設定してなかった) それで気づいたけど、 そもそもlimitは何のlimitなんだ?バイト数?桁数・文字数? 調べてみたところ、stringは文字数、integerは桁数らしい。バイト数ではなかった。 MySQLではstringはvarchar(n)となって、limitに設定したのがn=文字数になる模様。 integerの方はちょっと複雑で、limitに設定した数値によってMySQLで宣言される型が変わるみたい。 こちらが参考になりました↓ migrateでのintegerの扱い 必要バイト数と合わせてまとめると、以下のような感じ。
重要な点は、 ・0だとTINYINTじゃなくて、INTになってる! ・5..8だとなんかBIGINTになってる…!! ・実際にはINT(n)とか桁数が入るけれど、桁数は必要バイト数とは無関係。 ということ。 結論:必要バイト数はカラム型で決まるので、そこ気にしてlimitかけよう じゃ、そーゆーことで。 参考: migrateでのintegerの扱い MySQLリファレンスマニュアル 6.2.6. 各カラム型に必要な記憶容量 コメント
コメントする
この記事のトラックバックURL
トラックバック機能は終了しました。
トラックバック
|
Rails3レシピブック 190の技
ついにRails3対応版が出ました!!
WEB+DB PRESS Vol.58
Rails2系から3への移行時に知りたいことがひとまとまりになっててよかった!色々ググるよりこれを読む方が早い。
Rubyレシピブック 第3版 303の技
Rubyやるならこのリファレンスは必要。
Search this site
|